What are the different authorities involved in the process of issuing a digital certificate?
|
Alfred W. Loo, in
Advances in Computers, 2010 Digital certificate is an electronic file which can be used to verify the identity of a party on the Internet. We can consider it an “electronic
passport.” Both individuals and corporations can be identified by checking the digital certificate. We trust a passport because we trust that the issuing body (i.e., the government in this case) does a good job in identifying the passport holder. However, there are some governments with corrupted officers or poor efficiency. The strength of identification depends on the trustworthiness of the issuing government. Digital certificate is similar to the
passport case. It is issued by an organization called a certificate authority (CA). However, there are many CAs which can issue the digital certificates. An attacker can also issue a certificate to himself. In addition to checking the digital certificate, users must check the issuing body. Unfortunately users have very limited knowledge on the trustworthiness of CAs. Corporations should protect a list of trusted CAs to their users. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/S0065245810790033 What Is Federated Identity?Derrick Rountree, in Federated Identity Primer, 2013 2.2.1.1.3 User CertificatesDigital certificates can also be used to authenticate users. Digital certificates contain a unique key pair that is associated with the certificate. This is how certificates can be differentiated from one another. There is a certain type of digital certificate called a user certificate that is specifically designed for user authentication. After the certificate is created, the certificate is then mapped back to a user account. This user account is used to determine what access the user should have. When the user attempts to access a resource, a certificate will be requested. Depending on the client device and server configuration, a user certificate may automatically be submitted or the user may have to specify which certificate to submit. The certificate is accepted by the resource and processed. During the processing, the backend authentication system will look up the certificate and find the corresponding user account for that certificate. This information is then submitted to the resource. The resource will then make authorization decisions based on the user account. In order to use certificate-based authentication, the certificate must be somehow stored and transported. There are a few options. One option is to have the operating system on your computer storing the certificate. The problem with this is that the certificate is not portable. You can only use it from that system. Another, more popular alternative is to use a smartcard. A smartcard uses integrated circuits to store the digital certificate. When you attempt to access a resource and the site requests a certificate, you type in your PIN to unlock your smartcard and the certificate is submitted to the resource. Smartcards also have a portability issue. They require specialized hardware (smartcard readers) to be attached to computer systems to enable and allow the systems to retrieve information from the smartcards. The need for this personalized hardware is the reason smartcards haven’t taken off for Internet application authentication, compared to their adoption at the enterprise level. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780124071896000029 Locking Down Your XenApp ServerTariq Bin Azad, in Securing Citrix Presentation Server in the Enterprise, 2008 Understanding the Function of a PKIDigital certificates are becoming more and more common in today's computing environment. These certificates offer a way for individuals to verify the authenticity of e-mail messages, encrypt files, and so on. Several third-party organizations have been providing digital certificates or other key services for a number of years. There can be a number of drawbacks to relying solely on third-party certificate providers to generate and verify user keys. One of the most significant roadblocks is cost. While the per-user cost of issuing a valid certificate has decreased recently, it can still be cost-prohibitive for a large organization to rely solely on external resources for certificate security. Ease of management is another drawback. Again, managing certificates through an external organization can be cumbersome, confusing, and time-consuming, especially for large organizations. With a Windows-based network infrastructure, you have the option of developing and hosting your own PKI within your organization. Microsoft provides a number of tools for creating and managing digital certificates within Active Directory. There are a number of advantages to using an internal PKI structure. First, there is no per-user cost to generate digital certificates. So these certificates can be created for every individual within the organization, no matter how large. Second, certificates can be managed internally. You can monitor use of certificates within the organization and automatically revoke certificates when a user leaves the organization or no longer has the need to use a certificate. One of the drawbacks to using a completely internal PKI is that of trust. If all your certificates are generated and managed internally, you may have difficulty getting external organizations to recognize the validity of the certificates created within your organization. The most complete implementation of a PKI includes certificates generated internally and externally. Acquiring a certificate from a trusted third-party organization lends credence to the validity of certificates used in your organization. Generating and managing internal certificates cuts down on the costs associated with public key security. Ultimately, how you implement your PKI depends largely on the needs you have for public key security within your organization. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B978159749281200007X Domain 3: Security Engineering (Engineering and Management of Security)Eric Conrad, ... Joshua Feldman, in CISSP Study Guide (Third Edition), 2016 Certificate Authorities and Organizational Registration AuthoritiesDigital certificates are issued by Certificate Authorities (CAs). Organizational Registration Authorities (ORAs) authenticate the identity of a certificate holder before issuing a certificate to them. An organization may operate as a CA or ORA (or both). CAs may be private (run internally) or public (such as VeriSign or Thawte). Anyone off the street cannot simply request and receive a certificate for www.ebay.com, for example; they must prove that they have the authority to do so. This authentication is done by the CA, and can include business records research, emails sent to domain contacts, and similar methods. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780128024379000047 VPN Theory and UsageBrad Woodberg, ... Ralph Bonnell, in Configuring Juniper Networks NetScreen & SSG Firewalls, 2007 CertificatesDigital certificates are nothing more than a way to verify your identity through a CA using public key cryptography. NetScreen appliances support the use of digital certificates as a method of validating your identity during VPN negotiations. There are certain steps you must take before you can use a certificate to validate your identity. First, you must generate a certificate request from within the NetScreen appliance. When this is done, the NetScreen appliance generates a public/private key pair. You then send a request with the public key to your CA. A response, which incorporates the public key, will be forwarded to you that will have to be loaded into the NetScreen appliance. This response generally includes three parts: ▪The CA's certificate, which contains the CA's public key. ▪The local certificate identifying your NetScreen device. ▪In some cases a certificate revocation list (CRL). This lists any certificates revoked by the CA. You can load the reply into the NetScreen device either through the WebUI or via TFTP (Thin File Transport Protocol) through the CLI (command line interface), whichever you prefer. Loading the certificate information into NetScreen gives us the following: ▪Your identity can be verified using the local certificate. ▪The CA's certificate can be used to verify the identity of other users. ▪The CRL list can be used to identify invalid certificates. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597491181500137 Domain 3Eric Conrad, ... Joshua Feldman, in Eleventh Hour CISSP® (Third Edition), 2017 Public Key InfrastructurePublic Key Infrastructure (PKI) leverages all three forms of encryption to provide and manage digital certificates. A digital certificate is a public key signed with a digital signature. Digital certificates may be server-based or client-based. If client and server certificates are used together, they provide mutual authentication and encryption. The standard digital certificate format is X.509. Certificate authorities and organizational registration authoritiesDigital certificates are issued by certificate authorities (CAs). Organizational registration authorities (ORAs) authenticate the identity of a certificate holder before issuing a certificate to them. An organization may operate as a CA or ORA (or both). Certificate revocation listsThe CAs maintain certificate revocation lists (CRL), which, as the name implies, is a list of revoked certificates. A certificate may be revoked if the private key has been stolen, an employee is terminated, etc. A CRL is a flat file and does not scale well. The Online Certificate Status Protocol (OCSP) is a replacement for CRLs and uses client-server design that scales better. Key management issuesCAs issue digital certificates and distribute them to certificate holders. The confidentiality and integrity of the holder’s private key must be assured during the distribution process. Public/private key pairs used in PKI should be stored centrally and securely. Users may lose their private key as easily as they may forget their password. A lost private key means that anything encrypted with the matching public key will be lost, short of cryptanalysis, as described previously. Note that key storage is different than key escrow. Key storage means the organization that issued the public/private key pairs retains a copy. Key escrow means a copy is retained by a third-party organization (and sometimes multiple organizations), often for law enforcement purposes. A retired key may not be used for new transactions, but one may be used to decrypt previously encrypted plaintexts. A destroyed key no longer exists and therefore cannot be used for any purpose. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780128112489000036 Defining a VPNIn Firewall Policies and VPN Configurations, 2006 CertificatesDigital certificates are nothing more than a way to verify your identity through a CA using public key cryptography. There are certain steps you must take before you can use a certificate to validate your identity. First, you must generate a certificate request from within the VPN appliance. Then, the VPN appliance generates a public/private key pair. You then send a request with the public key to your CA. A response, which incorporates the public key, will be forwarded to you that will have to be loaded into the VPN appliance. This response generally includes three parts: ■The CA’s certificate, which contains the CA’s public key ■The local certificate identifying your VPN device ■In some cases, a certificate revocation list (CRL), which lists any certificates revoked by the CA You can load the reply into the VPN device either through the Web UI or via TFTP (Thin File Transport Protocol) through the CLI (command line interface), whichever you prefer. Loading the certificate information into the VPN gives the following: ■Your identity can be verified using the local certificate. ■The CA’s certificate can be used to verify the identity of other users. ■The CRL list can be used to identify invalid certificates. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597490887500074 Resistance StrategiesTimothy J. Shimeall, Jonathan M. Spring, in Introduction to Information Security, 2014 Computer IdentificationAn important task in the functioning of the Internet, or any large network, is to verify that the computer the defender is communicating with is the correct one. Early in the development of the Internet, this identification was implicitly asserted with the IP address. Even though there was no formal method protecting the IP address from modification or hijacking in the operation of the IP protocol, in the 1970s the network was a research network shared by a small enough number of people that they all could call one another on the phone. In this environment, it was adequate to know who the operation of an IP address was assigned to in order to trust that the connection was to that computer. This implicit assumption worked its way into several early remote tools, such as rlogin and rcp (remote copy). Implicit computer identification caused several security problems once the Internet grew large enough. The older remote-access programs (rcp and telnet) have been replaced by programs with more robust authentication that replicate the function, such as scp (secure copy). However, at the most basic level, the IP protocol has not been updated. It is too ingrained in the operation of the network to be easily changed. Efforts have been made, namely IPsec, to improve this situation, however, they have not been adopted on a large scale. In this environment, host identification is an important service that needs to be provided independent of the IP protocol. Secure Socket Layer (SSL), the new version of which was renamed Transport Layer Security (TLS), is a common distributed computer identification protocol in use on the Internet. The original SSL protocol was developed privately by web browser pioneer Netscape [30], however, it was later standardized publicly by the IETF (Internet Engineering Task Force) as TLS [31]. When a URL (uniform resource locator) begins with https://, rather than just http://, this means “HTTP over SSL/TLS.” TLS provides a number of security services besides computer identification, and the protocol does not require the parties perform the identification step. However, in practice, most of the services provided by the protocol require at least one computer to identify itself [31, p. 3]. The identification uses asymmetric key cryptography. The crux of the work is done by a network of digital certificates. A discussion of computer identification would be incomplete without an understanding of the digital certificates. In some ways, the digital certificate infrastructure is the keystone of the system, and TLS is just a flexible specification for utilizing the certificates. Digital CertificatesDigital certificates can come in many forms, but the most common is the X.509 certificate. The X.509 format is an ITU (International Telecommunication Union) standard, but the implementation for use on the Internet for identifying computers is standardized by the IETF [32]. This section will focus on the X.509 implementation for any details, but certificates are conceptually rather simple. A certificate links certain information together. The most important fields are a public key for use in asymmetric cryptography, a domain name, and an expiration date. The fields in a certificate are all linked together because they are signed by the private key of some certificate authority (CA), which verifies the certificate as genuine. Anyone can use the CA’s public key to verify the certificate. Anyone with a certificate can use their private key to sign other certificates, which users can verify as long as they can verify the matching public key. Users can do this so long as a chain of certificates leads back to a CA. To ground the system, CA public keys come preinstalled in web browsers. The way Microsoft, Google, or Mozilla determine what CAs are preinstalled involves internal policies idiosyncratic to the browser author, but it usually involves the CA paying a recurring fee. These CAs are then authorized to issue certificates (i.e., sign them with their private key) for other people or organizations. There are no official rules about how these certificates are issued. It is generally done by private companies, and market forces drive the competition among them. Incentive for cost-cutting is not always a good motivator for secure practices. If there is a valid chain of signed certificates back to a CA, a website is considered secured. All this really means is that a person with access to the email address that was used to register the domain name for the website agreed to let someone pay for a certificate to be issued, and the computer who served the website has that certificate. Some companies used to force applicants to show up in person, or receive mail at a physical address. However, this rigor is not required. This is not an awful model, but it has several opportunities for subversion. A useful exercise is to investigate the number of CAs preinstalled in your browser. There are about 100, which is far more than most users need for their daily browsing. This has caused significant trouble in the past. The security of everyone browsing the Internet is the result of the weakest link among these CAs. Weakest-link efforts are dangerous to rest security on, as compared to sum of efforts or best efforts, as discussed in Chapter 5 and Anderson [6, p. 229]. Even if a relatively obscure CA that mostly only provides services to Dutch users has the CA’s private key compromised, browsers in Iran or Washington, DC, can be redirected to a perfect forgery of any website by an adversary. This is precisely what happened when DigiNotar’s private key was compromised in 2011 [33]. The adversary was able to issue his or her own certificates as if they were DigiNotar. Unless the user noticed by a stroke of pure luck that DigiNotar had signed their Google login page instead of Thawte, the valid CA for the site at the time, there was no warning of the forgery. This permitted the adversary to steal credentials from users for a number of sites, since the users did not notice the forgery and input their credentials as if they were logging in to the real site. Forged certificates were issued for over 500 organizations, from Google to the intelligence agencies of the United States, United Kingdom, and Israel. All these organizations possibly had user credentials stolen. Further exacerbating the situation was that DigiNotar certificates could not be universally revoked—the company had legitimately signed several sites used by the Dutch government to deliver critical services to its citizens. Revoking the DigiNotar certificate would invalidate these legitimate certificates at the same time as the forgeries. To give the Dutch enough time to provide alternatives, there was a browser patch issued to try to block the DigiNotar certificates being used on known-forged sites, and eventually the certificates were revoked. The company went bankrupt not long after, but the damage to many unwitting Internet users had been done. Many of the CAs that come preinstalled in browsers will never be used by a user. This is because many of them specialize in business in one geographic area or for speakers of a particular language. One mitigation for attacks on CAs is to remove as many of the defaults as is feasible. However, this only reduces the risk, it does not eliminate the fundamental problem. Security based on a weakest-link architecture such as this gets weaker the more entities are added [6, p. 229], and as the Internet grows more, CAs are inevitable. Transport Layer SecurityTLS makes use of digital certificates in the handshake phase of the protocol. When the handshake is completed, the server should have presented a valid certificate to identify itself. The client computer can also be required to present one, if the server requests it. At the end of the handshake the two computers have also agreed on a symmetric key cipher to use to protect the session, as well as a session key to use. TLS guarantees that only the two computers in the communication know the session key, and the selection of the session key cannot be influenced by a middle-person attack [31]. There are not any glaring problems with TLS itself. It can also be used by any application, not just web traffic, with relatively little modification to the application. This makes it a flexible solution to provide encryption and entity authentication for applications that are otherwise security-agnostic. All of these items—CAs, TLS, certificates—as well as the policies and people that implement them, make up the PKI of the Internet. The technology is sound, but without accurate certificates to identify the endpoints, a secure connection is not of much help in resisting attacks. Namely, an encrypted connection to the adversary instead of the intended target does not help. For this reason, a robust public key infrastructure that adequately ties public keys to real identities is extremely important. The existing PKI has shown weaknesses, not in the technologies themselves, but via attacks on CAs. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597499699000080 Embedded securityJ. Rosenberg, in Rugged Embedded Systems, 2017 Digital certificates are containers for public keysA digital certificate is a data structure that contains identity information along with an individual's public key and is signed by a certificate authority (CA). By signing the certificate the CA is vouching for the identity of the individual described in the certificate. Therefore RPs can trust the public key also contained in the same certificate. Bob, the RP, must be certain that this is really Alice's key. He does this by checking the identity of the CA that signed this certificate (how does he trust them in the first place?) and by verifying both the identity and integrity of the certificate through the CA's attached signature. A validity date included in X.509 certificates helps insure against compromised (or out of date and invalid) keys. The X.509 digital certificate trust model is a very general one. Each identity has a distinct name. The identity must be certified by the CA using some well-defined certification process they must describe and publish in a certification practice statement (CPS). The CA assigns a unique name to each user and issues a signed certificate containing the name and the user's public key. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780128024591000117 Who is the issuing authority of digital certificate?A licensed Certifying Authority (CA) issues the digital signature. Certifying Authority (CA) means a person who has been granted a license to issue a digital signature certificate under Section 24 of the Indian IT-Act 2000.
Who are involved in digital certificate creation?The steps required to create a digital certificate involves three parties first the end user, second the registration authority and third is certificate authority.
What are the types of certificate authority?There are three types of Certificate Authorities in hierarchy: root, intermediate, and issuing Certificate Authority.
How many certificate authorities are there?The Trusted Certificate Authorities:
There are two types of Certificate Authorities, namely regional and global. There are about 50 CAs in the global SSL market but only a handful of these CAs have the real hold on the market.
|
