From Wikipedia, the free encyclopedia In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is an electronic document which uses a digital signature to bind a public keywith an identity — information such as the name of a person or an organization, their address, and so forth. The certificate can be used to verify that a public key belongs to an individual. In a typical public key infrastructure (PKI) scheme, the signature will be of a certificate authority (CA). In a web of trust scheme, the signature is of either the user (a self-signed certificate) or other users ("endorsements"). In either case, the signatures on a certificate are attestations by the certificate signer that the identity information and the public key belong together. 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.[1] Certificates can be created for Unix-based servers with tools such as OpenSSL's ca command.[2] or SuSE's gensslcert. These may be used to issue unmanaged certificates, Certification Authority (CA) certificates for managing other certificates, and user and/or computer certificate requests to be signed by the CA, as well as a number of other certificate related functions. Similarly, Microsoft Windows 2000 Server and Windows Server 2003 contain a Certification Authority (CA) as part of Certificate Services for the creation of digital certificates. In Windows Server 2008 the CA may be installed as part of Active Directory Certificate Services. The CA is used to manage and centrally issue certificates to users and/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.
[edit]Contents of a typical digital certificateSerial Number: Used to uniquely identify the certificate. Subject: The person, or entity identified. Signature Algorithm: The algorithm used to create the signature. Issuer: The entity that verified the information and issued the certificate. Valid-From: The date the certificate is first valid from. Valid-To: The expiration date. Key-Usage: Purpose of the public key (e.g. encipherment, signature, certificate signing...). Public Key: the purpose of SSL when used with HTTP is not just to encrypt the traffic, but also to authenticate who the owner of the website is, and that someone's been willing to invest time and money into proving the authenticity and ownership of their domain. Thumbprint Algorithm: The algorithm used to hash the certificate. Thumbprint: The hash itself to ensure that the certificate has not been tampered with. [edit]Classification[edit]Vendor defined classesVeriSign uses the concept of classes of digital certificates https://www.verisign.com/support/roots.html[citation needed]:
[edit]Usage in the European UnionThe EU Directive 1999/93/EC on a Community framework for electronic signatures[3] defines the term qualified certificate as "a certificate which meets the requirements laid down in Annex I and is provided by a certification-service-provider who fulfils the requirements laid down in Annex II":
[edit]Certificates and web site securityThe most common use of certificates is for HTTPS-based web sites. A web browser validates that an SSL (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 acertificate signing request. The certificate request is an electronic document that contains the web site name, contact email address, and company information. 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 [edit]Extended ValidationCertificate providers issue "higher security" certificates that require further security checks, and therefore warrant much higher fees. This is called an Extended Validation. These security checks cross reference the owner of the domain name with the owner of the legal entity that claims to operate under it. (These checks may involve the presentation of utility bills, passports, etc.) The difference between these higher security certificates and regular certificates are that the browser URL bar changes to a different color. This improved security assumes the user knows the meaning of the colors, and would choose to navigate away from the site if the color code was not commensurate with the purpose of the web site. To be clear, for a https:// web site URL, the difference between having no certificate, and having a regular certificate is that the browser will refuse to access the site without confirming with the user. By comparison, the difference between a regular certificate and an extended validation certificate is merely a change in color. [edit]UniquenessA 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 lacks Extended Validation, even if it has a different provider, and even if the previous certificate had an expiry date far into the future. 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 unknown organizations. Each of these organizations is free to issue any certificate for any web site and have the guarantee that all web browsers will accept it as genuine. The list of built-in certificates is also not fixed: users (and to a degree applications) are free to extend the list for special purposes such as for company intranets. Whoever is able to insert a temporary trusted root certificate into a browser's installed list of trusted root certificates will have the freedom to generate any certificate with the guarantee that the web browser will accept it as genuine. The only way to discern a fake is to carefully inspect the certificate path. [edit]Usefulness versus unsecured web sitesIn spite of the limitations described above, certificate-authenticated SSL 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 serious flaws described above, web sites secured by public key certificates are still more secure than unsecured http:// web sites. [edit]See also |