Certificate authority
In cryptography, a certificate authority or certification authority is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.
One particularly common use for certificate authorities is to sign certificates used in HTTPS, the secure browsing protocol for the World Wide Web. Another common use is in issuing identity cards by national governments for use in electronically signing documents.
Overview
Trusted certificates can be used to create secure connections to a server via the Internet. A certificate is essential in order to circumvent a malicious party which happens to be on the route to a target server which acts as if it were the target. Such a scenario is commonly referred to as a man-in-the-middle attack. The client uses the CA certificate to authenticate the CA signature on the server certificate, as part of the authorizations before launching a secure connection. Usually, client software—for example, browsers—include a set of trusted CA certificates. This makes sense, as many 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 clients of a CA are server supervisors who call for a certificate that their servers will bestow to users. Commercial CAs charge money to issue certificates, and their customers anticipate the CA's certificate to be contained within the majority of web browsers, so that safe connections to the certified servers work efficiently out-of-the-box. The quantity of web browsers, other devices, and applications which trust a particular certificate authority is referred to as ubiquity. Mozilla, which is a non-profit business, issues several commercial CA certificates with its products. While Mozilla developed their own policy, the CA/Browser Forum developed similar guidelines for CA trust. A single CA certificate may be shared among multiple CAs or their resellers. A root CA certificate may be the base to issue multiple intermediate CA certificates with varying validation requirements.
In addition to commercial CAs, some non-profits issue publicly-trusted digital certificates without charge, for example Let's Encrypt. Some large cloud computing and web hosting companies are also publicly-trusted CAs and issue certificates to services hosted on their infrastructure, for example IBM Cloud, Amazon Web Services, Cloudflare, and Google Cloud Platform.
Large organizations or government bodies may have their own PKIs, each containing their own CAs. Any site using self-signed certificates acts as its own CA.
Commercial banks that issue EMV payment cards are governed by the EMV Certificate Authority, payment schemes that route payment transactions initiated at Point of Sale Terminals to a Card Issuing Bank to transfer the funds from the card holder's bank account to the payment recipient's bank account. Each payment card presents along with its card data also the Card Issuer Certificate to the POS. The Issuer Certificate is signed by EMV CA Certificate. The POS retrieves the public key of EMV CA from its storage, validates the Issuer Certificate and authenticity of the payment card before sending the payment request to the payment scheme.
Browsers and other clients of sorts characteristically allow users to add or do away with CA certificates at will. While server certificates regularly last for a relatively short period, CA certificates are further extended, so, for repeatedly visited servers, it is less error-prone importing and trusting the CA issued, rather than confirm a security exemption each time the server's certificate is renewed.
Less often, trustworthy certificates are used for encrypting or signing messages. CAs dispense end-user certificates too, which can be used with S/MIME. However, encryption entails the receiver's public key and, since authors and receivers of encrypted messages, apparently, know one another, the usefulness of a trusted third party remains confined to the signature verification of messages sent to public mailing lists.
Providers
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.However, the market for globally trusted TLS/SSL server certificates is largely held by a small number of multinational companies. This market has significant barriers to entry due to the technical requirements. While not legally required, new providers may choose to undergo annual security audits to be included as a trusted root by a web browser or operating system.
, 147 root certificates, representing 52 organizations, are trusted in the Mozilla Firefox web browser, 168 root certificates, representing 60 organizations, are trusted by macOS, and 255 root certificates, representing 101 organizations, are trusted by Microsoft Windows. As of Android 4.2, Android currently contains over 100 CAs that are updated with each release.
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 nonprofit certificate authority that provides free domain validated X.509 certificates as well as software to enable installation and maintenance of certificates. Let's Encrypt is operated by the newly formed Internet Security Research Group, a California nonprofit recognized as federally tax-exempt.
According to Netcraft in May 2015, the industry standard for monitoring active TLS certificates, "Although the global ecosystem is competitive, it is dominated by a handful of major CAs — three certificate authorities account for three-quarters of all issued certificates on public-facing web servers. The top spot has been held by Symantec ever since 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."
the survey company W3Techs, which collects statistics on certificate authority usage among the Alexa top 10 million and the Tranco top 1 million websites, lists the five largest authorities by absolute usage share as below.
| Rank | Issuer | Usage | Market Share |
| 1 | Let's Encrypt | 60.6% | 64.1% |
| 2 | GlobalSign | 22.3% | 23.6% |
| 3 | Sectigo | 5.7% | 6.0% |
| 4 | GoDaddy Group | 3.7% | 3.9% |
| 5 | DigiCert Group | 1.8% | 1.9% |
Validation standards
The commercial CAs that issue the bulk of certificates for HTTPS servers typically use a technique called "domain validation" to authenticate the recipient of the certificate. The techniques used for domain validation vary between CAs, but in general domain validation techniques are meant to prove that the certificate applicant controls a given domain name, not any information about the applicant's identity.Many Certificate Authorities also offer Extended Validation certificates as a more rigorous alternative to domain validated certificates. Extended validation is intended to verify not only control of a domain name, but additional identity information to be included in the certificate. Some browsers display this additional identity information in a green box in the URL bar. 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 whether users would be likely to recognize 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 newer browser, Edge Legacy, shows a significantly greater difference between EV and domain validated certificates, with domain validated certificates having a hollow, gray lock.
Validation weaknesses
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 probes that CAs send. These can include attacks against the DNS, TCP, or BGP protocols, or the compromise of routers. Such attacks are possible either on the network near a CA, or near the victim domain itself.One of the most common domain validation techniques involves sending an email containing an authentication token or link to an email address that is likely 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,,, or Postmaster | the domain. Some Certificate Authorities may accept confirmation using, , or in the domain. 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.
Domain validation implementations have 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 domain.com, but not all webmail systems had reserved the "ssladmin" username to prevent attackers from registering it.
Prior to 2011, there was no standard list of email addresses that could be used for domain validation, so it was not clear to email administrators which addresses needed to be reserved. The first version of the CA/Browser Forum Baseline Requirements, adopted November 2011, specified a list of such addresses. This allowed mail hosts to reserve those addresses for administrative use, though such precautions are still not universal. In January 2015, a Finnish man registered the username "hostmaster" at the Finnish version of Microsoft Live and was able to obtain a domain-validated certificate for live.fi, despite not being the owner of the domain name.