Public key certificate

Diagram of an example usage of digital certificate

In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is an electronic document used to prove ownership of a public key. The certificate includes information about the key, information about its owner's identity, and the digital signature of an entity that has verified the certificate's contents are correct. If the signature is valid, and the person examining the certificate trusts the signer, then they know they can use that key to communicate with its owner.

In a typical public-key infrastructure (PKI) scheme, the signer is a certificate authority (CA), usually a company that charges customers to issue certificates for them. In a web of trust scheme, the signer is either the key's owner (a self-signed certificate) or other users ("endorsements") whom the person examining the certificate might know and trust.

Certificates are an important component of Transport Layer Security (TLS, sometimes called by its older name SSL, Secure Sockets Layer), where they prevent an attacker from impersonating a secure website or other server. They are also used in other important applications, such as email encryption and code signing.

Operating systems

Certificates can be created for Unix-based servers with tools such as OpenSSL's ca command,[1] or SuSE's gensslcert. These may be used to issue unmanaged certificates, certification authority (CA) certificates for managing other certificates, and user or computer certificate requests to be signed by the CA, as well as a number of other certificate related functions.

Similarly, Windows Server contains a CA as part of Certificate Services for the creation of digital certificates. In Windows Server 2008 and later the CA may be installed as part of Active Directory Certificate Services. The CA is used to manage and centrally issue certificates to users or computers. Microsoft also provides a number of different certificate utilities, such as SelfSSL.exe for creating unmanaged certificates, and Certreq.exe for creating and submitting certificate requests to be signed by the CA, and certutil.exe for a number of other certificate related functions.

Mac OS X comes with the Keychain Access program, which is able to perform various certificate-related services.

Contents of a typical digital certificate

Usage in the European Union

The EU Directive 1999/93/EC on "a Community framework for electronic signatures" defines the term qualified certificate as a certificate which meets the requirements of Annex I and is provided by a certification service provider who fulfills the requirements of Annex II.[2]

According to Annex I, qualified certificates must contain:

  1. An indication that the certificate is issued as a qualified certificate
  2. The identification of the certification service provider and the state in which it is established
  3. The name of the signatory or a pseudonym, which shall be identified as such
  4. Provision for a specific attribute of the signatory to be included if relevant, depending on the purpose for which the certificate is intended
  5. Signature verification data which correspond to signature creation data under the control of the signatory
  6. An indication of the beginning and end of the period of validity of the certificate
  7. The identity code of the certificate
  8. The advanced electronic signature of the certification service provider issuing it
  9. Limitations on the scope of use of the certificate, if applicable
  10. Limits on the value of transactions for which the certificate can be used, if applicable

Annex II requires certification service providers to:

  1. Demonstrate the reliability necessary for providing certification services
  2. Ensure the operation of a prompt and secure directory and a secure and immediate revocation service
  3. Ensure that the date and time when a certificate is issued or revoked can be determined precisely
  4. Verify, by appropriate means in accordance with national law, the identity and, if applicable, any specific attributes of the person to which a qualified certificate is issued
  5. Employ personnel who possess the expert knowledge, experience, and qualifications necessary for the services provided, in particular competence at managerial level, expertise in electronic signature technology and familiarity with proper security procedures. They must also apply administrative and management procedures which are adequate and correspond to recognized standards.
  6. Use trustworthy systems and products which are protected against modification and ensure the technical and cryptographic security of the process supported by them
  7. Take measures against forgery of certificates, and, in cases where the certification service provider generates signature creation data, guarantee confidentiality during the process of generating such data
  8. Maintain sufficient financial resources to operate in conformity with the requirements laid down in the Directive, in particular to bear the risk of liability for damages, for example, by obtaining appropriate insurance
  9. Record all relevant information concerning a qualified certificate for an appropriate period of time, in particular for the purpose of providing evidence of certification for the purposes of legal proceedings. Such recording may be done electronically.
  10. Not store or copy signature creation data of the person to whom the certification service provider provided key management services
  11. Before entering into a contractual relationship with a person seeking a certificate to support their electronic signature, inform that person by a durable means of communication of the precise terms and conditions regarding the use of the certificate, including any limitations on its use, the existence of a voluntary accreditation scheme and procedures for complaints and dispute settlement. Such information, which may be transmitted electronically, must be in writing and in readily understandable language. Relevant parts of this information must also be made available on request to third parties relying on the certificate.
  12. Use trustworthy systems to store certificates in a verifiable form so that:
    • Only authorized persons can make entries and changes
    • Information can be checked for authenticity
    • Certificates are publicly available for retrieval in only those cases for which the certificate holder's consent has been obtained
    • Any technical changes compromising these security requirements are apparent to the operator

Certificate authorities

Main article: Certificate authority

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. According to NetCraft , 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."

Certificates and website security

The most common use of certificates is for HTTPS-based web sites. A web browser validates that a TLS (Transport Layer Security) web server is authentic, so that the user can feel secure that his/her interaction with the web site has no eavesdroppers and that the web site is who it claims to be. This security is important for electronic commerce. In practice, a web site operator obtains a certificate by applying to a certificate provider (a CA that presents as a commercial retailer of certificates) with a certificate signing request. The certificate request is an electronic document that contains the web site name, contact email address, company information and the public key (for security reasons the private key is not part of the request and is not sent to the certificate authority). The certificate provider signs the request, thus producing a public certificate. During web browsing, this public certificate is served to any web browser that connects to the web site and proves to the web browser that the provider believes it has issued a certificate to the owner of the web site.

Before issuing a certificate, the certificate provider will request the contact email address for the web site from a public domain name registrar, and check that published address against the email address supplied in the certificate request. Therefore, an https web site is only secure to the extent that the end user can be sure that the web site is operated by someone in contact with the person who registered the domain name.

As an example, when a user connects to https://www.example.com/ with their browser, if the browser does not give any certificate warning message, then the user can be theoretically sure that interacting with https://www.example.com/ is equivalent to interacting with the entity in contact with the email address listed in the public registrar under "example.com", even though that email address may not be displayed anywhere on the web site. No other surety of any kind is implied. Further, the relationship between the purchaser of the certificate, the operator of the web site, and the generator of the web site content may be tenuous and is not guaranteed. At best, the certificate guarantees uniqueness of the web site, provided that the web site itself has not been compromised (hacked) or the certificate issuing process subverted.

A certificate provider can opt to issue three types of certificates, each requiring its own degree of vetting rigor. In order of increasing rigor (and naturally, cost) they are: Domain Validation, Organization Validation and Extended Validation. These rigors are loosely agreed upon by voluntary participants in the CA/Browser Forum.

Validation levels

Domain validation

A certificate provider will issue a Domain Validation (DV) class certificate to a purchaser if the purchaser can demonstrate one vetting criterion: the right to administratively manage a domain name.

Organization validation

A certificate provider will issue an Organization Validation (OV) class certificate to a purchaser if the purchaser can meet two criteria: the right to administratively manage the domain name in question, and perhaps, the organization's actual existence as a legal entity. A certificate provider publishes its OV vetting criteria through its Certificate Policy.

Extended validation

To acquire an Extended Validation (EV) certificate, the purchaser must persuade the certificate provider of its legal identity, including manual verification checks by a human. As with OV certificates, a certificate provider publishes its EV vetting criteria through its Certificate Policy.

Browsers will generally offer users a visual indication of the legal identity when a site presents an EV certificate. Most browsers show the legal name before the domain, and use a bright green color to highlight the change. In this way, the user can see the legal identity of the owner has been verified.

Weaknesses

A web browser will give no warning to the user if a web site suddenly presents a different certificate, even if that certificate has a lower number of key bits, even if it has a different provider, and even if the previous certificate had an expiry date far into the future. However a change from an EV certificate to a non-EV certificate will be apparent as the green bar will no longer be displayed. Where certificate providers are under the jurisdiction of governments, those governments may have the freedom to order the provider to generate any certificate, such as for the purposes of law enforcement. Subsidiary wholesale certificate providers also have the freedom to generate any certificate.

All web browsers come with an extensive built-in list of trusted root certificates, many of which are controlled by organizations that may be unfamiliar to the user.[3] Each of these organizations is free to issue any certificate for any web site and have the guarantee that web browsers that include its root certificates will accept it as genuine. In this instance, end users must rely on the developer of the browser software to manage its built-in list of certificates and on the certificate providers to behave correctly and to inform the browser developer of problematic certificates. While uncommon, there have been incidents in which fraudulent certificates have been issued: in some cases, the browsers have detected the fraud; in others, some time passed before browser developers removed these certificates from their software.[4][5]

The list of built-in certificates is also not limited to those provided by the browser developer: users (and to a degree applications) are free to extend the list for special purposes such as for company intranets.[6] This means that if someone gains access to a machine and can install a new root certificate in the browser, that browser will recognize websites that use the inserted certificate as legitimate.

For provable security, this reliance on something external to the system has the consequence that any public key certification scheme has to rely on some special setup assumption, such as the existence of a certificate authority.[7]

Usefulness versus unsecured web sites

In spite of the limitations described above, certificate-authenticated TLS is considered mandatory by all security guidelines whenever a web site hosts confidential information or performs material transactions. This is because, in practice, in spite of the weaknesses described above, web sites secured by public key certificates are still more secure than unsecured http:// web sites.[8]

See also

References

  1. ↑ OpenSSL: Documentation ca(1)
  2. ↑ "Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures". Official Journal L 013 , 19/01/2000 P. 0012 - 0020. Annex II. Retrieved 2010-02-17.
  3. ↑ "List of certificates included by Mozilla". Mozilla.org. Retrieved 30 July 2012.
  4. ↑ "DigiNotar removal by Mozilla". Mozilla.org. Retrieved 30 July 2012.
  5. ↑ "DigitNotar removal by Google". Google.com. Retrieved 30 July 2012.
  6. ↑ "Using certificates article at Mozilla.org". Mozilla.org. Retrieved 30 July 2012.
  7. ↑ Ran Canetti: Universally Composable Signature, Certification, and Authentication. CSFW 2004, http://eprint.iacr.org/2003/239
  8. ↑ Ben Laurie, Ian Goldberg (18 January 2014). "Replacing passwords on the Internet AKA post-Snowden Opportunistic Encryption" (PDF).

External links

This article is issued from Wikipedia - version of the Wednesday, May 04, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.