World Library  
Flag as Inappropriate
Email this Article

Certificate authority


Certificate authority

In cryptography, a certificate authority or certification authority (CA) is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made by the private key that corresponds to the certified public key. In this model of trust relationships, a CA is a trusted third party – trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. Many public-key infrastructure (PKI) schemes feature CAs.


  • Overview 1
  • Providers 2
  • Validation standards 3
  • Issuing a certificate 4
    • Example 4.1
    • Security 4.2
    • Authority revocation lists 4.3
  • Industry organizations 5
  • CA compromise 6
  • Open source implementations 7
  • See also 8
  • References 9
  • External links 10


Trusted certificates are typically used to make secure connections to a server over the Internet. A certificate is required in order to avoid the case that a malicious party which happens to be on the path to the target server pretends to be the target. Such a scenario is commonly referred to as a man-in-the-middle attack. The client uses the CA certificate to verify the CA signature on the server certificate, as part of the checks before establishing a secure connection. Usually, client software—for example, browsers—include a set of trusted CA certificates. That makes sense in as much as users need to trust their client software: A malicious or compromised client can skip any security check and still fool its users into believing otherwise.

The customers of a CA are server administrators who need a certificate that their servers will present to clients. Commercial CAs charge to issue certificates, and their customers expect the CA's certificate to be included by most web browsers, so that secure connections to the certified server work smoothly out of the box. The number of web browsers and other devices and applications that trust a particular certificate authority is referred to as ubiquity.

  • Certificate Authority Reviews
  • How secure is HTTPS today? How often is it attacked?, Electronic Frontier Foundation (25 October 2011)
  • SSL Certificate Providers

External links

  1. ^ "Mozilla Included CA Certificate List — Mozilla". Retrieved 2014-06-11. 
  2. ^ Zakir Durumeric; James Kasten; Michael Bailey; J. Alex Halderman (12 September 2013). "Analysis of the HTTPS Certificate Ecosystem" (PDF). The Internet Measurement Conference.  
  3. ^ "What is SSL Certificate?". Retrieved 2015-10-16. 
  4. ^ "webtrust". webtrust. Retrieved 2013-03-02. 
  5. ^ Kirk Hall (April 2013). "Standards and Industry Regulations Applicable to Certification Authorities" (PDF). Trend Micro. Retrieved 2014-06-11. 
  6. ^ "Most Trusted Root Certificates". Retrieved 2015-10-16. 
  7. ^ "Let’s Encrypt: Delivering SSL/TLS Everywhere". Let's Encrypt. Retrieved 2014-11-20. 
  8. ^ "About". Let's Encrypt. Retrieved 2015-06-07. 
  9. ^ Counting SSL certificates; netcraft; May 13, 2015.
  10. ^ "Usage of SSL certificate authorities for websites". 2015-05-13. Retrieved 2015-09-29. 
  11. ^ Comodo has become the most widely used SSL certificate authority; w3techs; February 17, 2015.
  12. ^
  13. ^
  14. ^
  15. ^ Zusman, Mike (2009). Criminal charges are not pursued: Hacking PKI (PDF). DEF CON 17. Las Vegas. 
  16. ^
  17. ^ "Responsibilities of Certificate Authority". Retrieved 2015-02-12. 
  18. ^ "Electronic Signatures and Records" (PDF). Retrieved 2014-08-28. 
  19. ^ "Certificate transparency". Retrieved 2013-11-03. 
  20. ^ "Certificate transparency".  
  21. ^ "Multivendor power council formed to address digital certificate issues". Network World. February 14, 2013. 
  22. ^ "Major Certificate Authorities Unite In The Name Of SSL Security". Dark Reading. February 14, 2013. 
  23. ^ "CA/Browser Forum Founder". Retrieved 2014-08-23. 
  24. ^ "CA/Browser Forum". Retrieved 2013-04-23. 
  25. ^ Wilson, Wilson. "CA/Browser Forum History" (PDF). DigiCert. Retrieved 2013-04-23. 
  26. ^ "CA-2001-04". Retrieved 2014-06-11. 
  27. ^ Microsoft, Inc. (2007-02-21). "Microsoft Security Bulletin MS01-017: Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard". Retrieved 2011-11-09. 
  28. ^ Bright, Peter (28 March 2011). "Independent Iranian hacker claims responsibility for Comodo hack". Ars Technica. Retrieved 2011-09-01. 
  29. ^ Bright, Peter (2011-08-30). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica. Retrieved 2011-09-01. 
  30. ^ Leyden, John (2011-09-06). "Inside 'Operation Black Tulip': DigiNotar hack analysed". The Register. 
  31. ^ "Trustwave issued a man-in-the-middle certificate". The H Security. 2012-02-07. Retrieved 2012-03-14. 
  32. ^ "Dogtag Certificate System". Retrieved 2013-03-02. 
  33. ^ "reaperhulk/r509 · GitHub". Retrieved 2013-03-02. 
  34. ^ "". Retrieved 2013-03-02. 
  35. ^ "xipki/xipki · GitHub". Retrieved 2015-04-23. 
  36. ^ "letsencrypt/acme-spec". Retrieved 2014-11-20. 
  37. ^ "letsencrypt/lets-encrypt-preview". Retrieved 2014-11-20. 
  38. ^ "Boulder". Retrieved 2015-06-22. 


See also

  • DogTag[32]
  • gnoMint
  • OpenCA
  • OpenSSL, an SSL/TLS library that comes with tools allowing its use as a simple certificate authority
  • EasyRSA, OpenVPN's command line CA utilities using OpenSSL.
  • r509[33]
  • TinyCA, which is a perl gui on top of some CPAN modules.
  • XCA[34]
  • XiPKI,[35] CA and OCSP responder. OSGi-based, written in Java.
  • Automated Certificate Management Environment[36] (ACME), a protocol for communications between its certificate authority and servers. Let's Encrypt provides reference open source software implementations for ACME: lets-encrypt-preview is a Python-based test implementation of server certificate management software using the ACME protocol,[37] and boulder is a CA implementation, written in the Go programming language.[38]

Some open source implementations are:

There exist several open source implementations of certificate authority software. Common to all is that they provide the necessary services to issue, revoke and manage digital certificates.

Open source implementations

In 2012, it became known that Trustwave issued a subordinate root certificate that was used for transparent traffic management (man-in-the-middle) which effectively permitted an enterprise to sniff SSL internal network traffic using the subordinate certificate.[31]

In 2011 fraudulent certificates were obtained from Comodo and DigiNotar,[28][29] allegedly by Iranian hackers. There is evidence that the fraudulent DigiNotar certificates were used in a man-in-the-middle attack in Iran.[30]

A notable case of CA subversion like this occurred in 2001, when the certificate authority VeriSign issued two certificates to a person claiming to represent Microsoft. The certificates have the name "Microsoft Corporation", so they could be used to spoof someone into believing that updates to Microsoft software came from Microsoft when they actually did not. The fraud was detected in early 2001. Microsoft and VeriSign took steps to limit the impact of the problem.[26][27]

For example, suppose an attacker, Eve, manages to get a CA to issue to her a certificate that claims to represent Alice. That is, the certificate would publicly state that it represents Alice, and might include other information about Alice. Some of the information about Alice, such as her employer name, might be true, increasing the certificate's credibility. Eve, however, would have the all-important private key associated with the certificate. Eve could then use the certificate to send digitally signed email to Bob, tricking Bob into believing that the email was from Alice. Bob might even respond with encrypted email, believing that it could only be read by Alice, when Eve is actually able to decrypt it using the private key.

If the CA can be subverted, then the security of the entire system is lost, potentially subverting all the entities that trust the compromised CA.

CA compromise

  • [25][24]
  • [22][21]

Industry organizations

An authority revocation list (ARL) is a form of CRL containing certificates issued to certificate authorities, contrary to CRLs which contain revoked end-entity certificates.

Authority revocation lists

In large-scale deployments, Alice may not be familiar with Bob's certificate authority (perhaps they each have a different CA server), so Bob's certificate may also include his CA's public key signed by a different CA2, which is presumably recognizable by Alice. This process typically leads to a hierarchy or mesh of CAs and CA certificates.

Despite the security measures undertaken to correctly verify the identities of people and companies, there is a risk of a single CA issuing a bogus certificate to an imposter. It is also possible to register individuals and companies with the same or very similar names, which may lead to confusion. To minimize this hazard, the phishing.[19][20]

  1. a signature, contract or other record relating to such transaction may not be denied legal effect, validity, or enforceability solely because it is in electronic form; and
  2. a contract relating to such transaction may not be denied legal effect, validity or enforceability solely because an electronic signature or electronic record was used in its formation.

The problem of assuring correctness of match between data and entity when the data are presented to the CA (perhaps over an electronic network), and when the credentials of the person/company/program asking for a certificate are likewise presented, is difficult. This is why commercial CAs often use a combination of authentication techniques including leveraging government bureaus, the payment infrastructure, third parties' databases and services, and custom heuristics. In some enterprise systems, local forms of authentication such as Kerberos can be used to obtain a certificate which can in turn be used by external relying parties. Notaries are required in some cases to personally know the party whose signature is being notarized; this is a higher standard than is reached by many CAs. According to the American Bar Association outline on Online Transaction Management the primary points of US Federal and State statutes enacted regarding digital signatures has been to "prevent conflicting and overly burdensome local regulation and to establish that electronic writings satisfy the traditional requirements associated with paper documents." Further the US E-Sign statute and the suggested UETA code [18] help ensure that:


This is what the certificate authority mechanism is intended to prevent. A certificate authority (CA) is an organization that stores public keys and their owners, and every party in a communication trusts this organization (and knows its public key). When the user's web browser receives the public key from it also receives a digital signature of the key (with some more information, in a so-called X.509 certificate). The browser already possesses the public key of the CA and consequently can verify the signature, trust the certificate and the public key in it: since uses a public key that the certification authority certifies, a fake can only use the same public key. Since the fake does not know the corresponding private key, it cannot create the signature needed to verify its authenticity.

This mechanism is only safe if the user can be sure that it is the bank that they see in their web browser. If the user types in, but their communication is hi-jacked and a fake web-site (that pretends to be the bank web-site) sends the page information back to the user's browser, the fake web-page can send a fake public key to the user (for which the fake site owns a matching private key). The user will fill the form with their personal data and will submit the page. The fake web-page will then get access to the user's data.

The rest of the communication then proceeds using the new (disposable) symmetric key, so when the user enters some information to the bank's page and submits the page (sends the information back to the bank) then the data the user has entered to the page will be encrypted by their web browser. Therefore, even if someone can access the (encrypted) data that was communicated from the user to, such eavesdropper cannot read or decipher it.

Public-key cryptography can be used to encrypt data communicated between two parties. This can typically happen when a user logs on to any site that implements the HTTP Secure protocol. In this example let us suppose that the user logs on to their bank's homepage to do online banking. When the user opens homepage, they receive a public key along with all the data that their web-browser displays. The public key could be used to encrypt data from the client to the server but the safe procedure is to use it in a protocol that determines a temporary shared symmetric encryption key; messages in such a key exchange protocol can be enciphered with the bank's public key in such a way that only the bank server has the private key to read them.


If the user trusts the CA and can verify the CA's signature, then (s)he can also assume that a certain public key does indeed belong to whoever is identified in the certificate.

A CA issues [17]

Issuing a certificate

Most Certificate Authorities offer Extended Validation (EV) certificates as a more rigorous alternative to domain validated certificates. One limitation of EV as a solution to the weaknesses of domain validation is that attackers could still obtain a domain validated certificate for the victim domain, and deploy it during an attack; if that occurred, the difference observable to the victim user would be the absence of a green bar with the company name. There is some question as to whether users would be likely to recognise this absence as indicative of an attack being in progress: a test using Internet Explorer 7 in 2009 showed that the absence of IE7's EV warnings were not noticed by users, however Microsoft's current browser, Edge, shows a significantly greater difference between EV and domain validated certificates, with domain validated certificates having a hollow, grey lock.

The same attack vector is still present, but rarely successful due to widely implemented blacklisting by most webmail sites. In a recent case, a Finnish man in January 2015 successfully registered the username "hostmaster" at the Finnish version of Microsoft Live and successfully obtained an domain-validated certificate for[16]

As there was no standard on a list of usernames eligible for domain validation, it has not been clear for webmail systems which usernames are to be blacklisted from signing up. A first formal standard has been created in the first release of the Baseline Requirements Document by CA/Browser Forum in 2011.

Domain validation implementations have also sometimes been a source of security vulnerabilities. In one instance, security researchers showed that attackers could obtain certificates for webmail sites because a CA was willing to use an email address like for, but not all webmail systems had reserved the "ssladmin" username to prevent attackers from registering it.[15]

Domain validation suffers from certain structural security limitations. In particular, it is always vulnerable to attacks that allow an adversary to observe the domain validation emails that CAs send. These can include attacks against the DNS, TCP, or BGP protocols (which lack the cryptographic protections of TLS/SSL), or the compromise of routers. Such attacks are possible either on the network near a CA, or near the victim domain itself.

The commercial CAs that issue the bulk of certificates that clients trust for email servers and public HTTPS servers typically use a technique called "domain validation" to authenticate the recipient of the certificate. Domain validation involves sending an email containing an authentication token or link, to an email address that is known to be administratively responsible for the domain. This could be the technical contact email address listed in the domain's WHOIS entry, or an administrative email like admin@, administrator@, webmaster@, hostmaster@ or postmaster@ the domain.[12][13] Some Certificate Authorities may accept confirmation using root@, info@, or support@ in the domain.[14] The theory behind domain validation is that only the legitimate owner of a domain would be able to read emails sent to these administrative addresses.

Validation standards

Rank Issuer Usage Market share
1 Comodo 6.1% 37.2%
2 Symantec 5% 30.2%
3 GoDaddy 2.2% 13.3%
4 GlobalSign 1.7% 10.4%
5 DigiCert 0.5% 3.1%
6 StartCom 0.4% 2.2%
7 Entrust 0.1% 0.8%
8 Verizon 0.1% 0.7%
9 Trustwave 0.1% 0.6%
10 Secom 0.1% 0.6%
11 Unizeto 0.1% 0.4%
12 QuoVadis < 0.1% 0.1%
13 Deutsche Telekom < 0.1% 0.1%
14 Network Solutions < 0.1% 0.1%
15 SwissSign < 0.1% 0.1%

A W3Techs survey from May 2015 shows:[10][11]

According to NetCraft in May 2015, the industry standard for monitoring Active TLS certificates, states that "Although the global [TLS] ecosystem is competitive, it is dominated by a handful of major CAs — three certificate authorities (Symantec, Comodo, GoDaddy) account for three-quarters of all issued [TLS] certificates on public-facing web servers. The top spot has been held by Symantec (or VeriSign before it was purchased by Symantec) ever since [our] survey began, with it currently accounting for just under a third of all certificates. To illustrate the effect of differing methodologies, amongst the million busiest sites Symantec issued 44% of the valid, trusted certificates in use — significantly more than its overall market share."[9]

On November 18, 2014, a group of companies and nonprofit organizations, including the Electronic Frontier Foundation, Mozilla, Cisco, and Akamai, announced "Let's Encrypt," a new nonprofit certificate authority that plans to provide free TLS certificates, as well as software to enable installation and maintenance of certificates.[7] Let's Encrypt will be operated by the newly formed Internet Security Research Group, a California nonprofit recognized as tax-exempt under Section 501(c)(3).[8]

However, the market for SSL certificates, a kind of certificate used for website security, is largely held by a small number of multinational companies. This market has significant barriers to entry due to the technical requirements.[3]While not legally required, new providers may choose to undergo annual security audits (such as WebTrust[4] for Certification Authorities in North America and ETSI in Europe[5]) to be included in the list of web browser trusted authorities. More than 50 root certificates are trusted in the most popular web browser versions.[6]

Worldwide, the certificate authority business is fragmented, with national or regional providers dominating their home market. This is because many uses of digital certificates, such as for legally binding digital signatures, are linked to local law, regulations, and accreditation schemes for certificate authorities.


A less frequent usage of trusted certificates is for encrypting or signing messages. CAs issue end-user certificates too, which can be used with S/MIME. However, encryption requires the recipient's public key and, since authors and recipients of encrypted messages presumably know one another, the usefulness of a trusted third party remains confined to the signature verification of messages sent to public mailing lists.

Aside from commercial CAs, some providers issue digital certificates to the public at no cost; a noteworthy example is CAcert. Large institutions or government entities may have their own PKIs, each including their own CAs. Formally, any site using self-signed certificates acts as its own CA too. Browsers and other clients typically allow users to add or remove CA certificates at will. While server certificates usually last for a rather short period, CA certificates last much longer,[2] so, for frequently visited servers, it is less error-prone to import and trust the CA that issues their certificates rather than confirm a security exception every time the server's certificate is renewed.

CA certificates with varying validation requirements. intermediate CA certificate may be the base to issue multiple root. A resellers developed similar guidelines for CA trust. A single CA certificate may be shared among multiple CAs or their CA/Browser Forum While Mozilla developed their own policy, the [1]

This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.