In cryptography, a certificate authority or certification authority is an entity that
issues digital certificates.
The digital certificate certifies the ownership of a public key by the named subject of the
certificate.
This allows others to rely upon signatures or assertions made by the private key that
corresponds to the public key that is certified.
In this model of trust relationships, a CA is a trusted third party that is trusted by
both the subject of the certificate and the party relying upon the certificate.
CAs are characteristic of many public key infrastructure schemes.
Overview 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.
Mozilla, which is a non-profit organization, distributes 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.
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.
At any rate, decent clients 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, 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.
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.
Domain validation 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 postmaster@ or root@ 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 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, or the compromise of
routers.
Such attacks are possible either on the network near a CA, or near the victim domain itself.
Some Certificate Authorities offer Extended Validation 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 only difference observable to the victim user would be a blue
HTTPS address bar rather than a green one.
Few users would be likely to recognise this difference as indicative of an attack being
in progress.
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 SSLCertificates@domain.com
for domain.com, but not all webmail systems had reserved the "SSLCertificates" username
to prevent attackers from registering it.
Issuing a certificate A CA issues digital certificates that contain
a public key and the identity of the owner.
The matching private key is not made available publicly, but kept secret by the end user
who generated the key pair.
The certificate is also a confirmation or validation by the CA that the public key contained
in the certificate belongs to the person, organization, server or other entity noted
in the certificate.
A CA's obligation in such schemes is to verify an applicant's credentials, so that users
and relying parties can trust the information in the CA's certificates.
CAs use a variety of standards and tests to do so.
In essence, the certificate authority is responsible for saying "yes, this person is who they say
they are, and we, the CA, certify that".
If the user trusts the CA and can verify the CA's signature, thenhe can also assume that
a certain public key does indeed belong to whoever is identified in the certificate.
Example 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 his bank's homepage www.bank.example
to do online banking.
When the user opens www.bank.example homepage, he receives a public key along with all the
data that his 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 shared symmetric encryption key;
messages in such protocol are ciphered with the public key and only the bank server has
the private key to read them.
The rest of the communication proceeds using the new symmetric key, so when the user enters
some information to the bank's page and submits the page then the data the user has entered
to the page will be encrypted by his web browser.
Therefore, even if someone can access the data that was communicated from the user to
www.bank.example, such eavesdropper cannot read or decipher it.
This mechanism is only safe if the user can be sure that it is the bank that he sees in
his web browser.
If the user types in www.bank.example, but his communication is hi-jacked and a fake
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.
The user will fill the form with his personal data and will submit the page.
The fake web-page will get access to the user's data.
A certificate authority is an organization that stores public keys and their owners and
every party in a communication trusts this organization.
When the user's web browser receives the public key from www.bank.example it also receives
a digital signature of the key.
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 www.bank.example uses a public
key that the certification authority certifies, a fake www.bank.example can only use the same
public key.
Since the fake www.bank.example does not know the corresponding private key, it cannot create
the signature needed to verify its authenticity.
Security The problem of assuring correctness of match
between data and entity when the data are presented to the CA, and when the credentials
of the personprogram 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 help ensure that:
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
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.
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 certificate transparency initiative proposes auditing all certificates
in a public unforgeable log, which could help in the prevention of phishing.
In large-scale deployments, Alice may not be familiar with Bob's certificate authority,
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.
Authority revocation lists An authority revocation list is a form of
CRL containing certificates issued to certificate authorities, contrary to CRLs which contain
revoked end-entity certificates.
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 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, while not
legally required new providers may choose to undergo annual security audits 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.
A W3Techs survey from December 2013 shows: Symantec with 38.1% market share
Comodo Group with 29.1% Go Daddy with 13.4%
GlobalSign with 10% Industry organizations
Certificate Authority Security Council - In February 2013, the CASC was founded as an
industry advocacy organization dedicated to addressing industry issues and educating the
public on internet security.
The founding members are the seven largest Certificate Authorities.
Common Computing Security Standards Forum - In 2009 the CCSF was founded to promote
industry standards that protect end users.
Comodo Group CEO Melih Abdulhayoğlu is considered the founder of the CCSF.
CA/Browser Forum - In 2005, a new consortium of Certificate Authorities and web browser
vendors was formed to promote industry standards and baseline requirements for internet security.
Comodo Group CEO Melih Abdulhayoğlu organized the first meeting and is considered the founder
of the CA/Browser Forum.
CA compromise If the CA can be subverted, then the security
of the entire system is lost; even as widely as all the entities that trust the compromised
CA.
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.
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 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.
In 2011 fraudulent certificates were obtained from Comodo and DigiNotar, allegedly by Iranian
hackers.
There is evidence that the fraudulent DigiNotar certificates were used in a man-in-the-middle
attack in Iran.
In 2012, it became known that Trustwave issued a subordinate root certificate that was used
for transparent traffic management which effectively permitted an enterprise to sniff SSL internal
network traffic using the subordinate certificate.
Open source implementations 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.
Some open source implementations are: DogTag
EJBCA 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.
Free Certificate Authority Management App is a tool designed as a tutorial for learning
about PKI, RSA Certificates, and ECC Certificates.
r509 TinyCA, which is a perl gui on top of some
CPAN modules.
XCA See also
CAcert Certificate revocation list
Certificate server Extended Validation Certificate
Intermediate certificate authorities Robot certificate authority
Root Key Ceremony SAFE-BioPharma Association
Self-signed certificate Server gated cryptography
Web of trust X.509
References
External links Certificate authorities at DMOZ
Certificate Authority Reviews Certificate Authorities by Country
How secure is HTTPS today?
How often is it attacked?, Electronic Frontier Foundation