Self-signed certificate

In cryptography and computer security, a self-signed certificate is an identity certificate that is signed by the same entity whose identity it certifies. This term has nothing to do with the identity of the person or organization that actually performed the signing procedure. In technical terms a self-signed certificate is one signed with its own private key.

In typical public key infrastructure (PKI) arrangements, a digital signature from a certificate authority (CA) attests that a particular public key certificate is valid.[1] Each CA has one or more root keys; and the certificates associated with those public keys are "trust anchors" that use a special type of self-signed certificates.[2] Establishing trust of the CA root certificate is dependent upon procedures beyond checking its digital signature.

Security issues

In a CA based PKI system, the CA must be trusted by both parties. This is usually accomplished by placing the CA certificates in a whitelist of trusted certificates. For example, web browsers developers may use procedures specified by the CA/Browser Forum, or a private CA's certificate may be placed in the firmware of an embedded system. The trust issues of an entity accepting a new self-signed certificate, is similar to the issues of an entity trusting the addition of a new CA certificate. The parties in a self-signed PKI must establish trust with each other (using procedures outside the PKI), and confirm the accurate transfer of public keys (e.g. compare the hash out of band).

There are many subtle differences between CA signed and self-signed certificates, especially in the amount of trust that can be placed in the security assertions of the certificate. Some CAs can verify the identity of the person to whom they issue a certificate; for example the US military issues their Common Access Cards in person, with multiple forms of other ID. The CA can attest identity values like these by including them in the signed certificate. The entity that validates the certificate can trust the information in that certificate, to the same extent that they trust the CA that signed it (and by implication, the security procedures the CA used to verify the attested information).

With a self-signed certificate by contrast, trust of the values in the certificate are more complicated because the entity possesses the signing key, and can always generate a new certificate with different values. For example, the validity dates of a self-signed certificate might not be trusted because the entity could always create and sign a new certificate that contained a valid date range. The values in a self-signed certificate can be trusted when the following conditions are true: the values were (out-of-band) verified when the self-signed was formally trusted, and there is a method to verify the self-signed certificate has not changed after it was trusted. For example, the procedure of trusting a self-signed certificate includes a manual verification of validity dates, and a hash of the certificate is incorporated into the white list. When the certificate is presented for an entity to validate, they first verify the hash of the certificate matches the reference hash in the white-list, and if they match (indicating the self-signed certificate is the same as the one that was formally trusted) then the certificate's validity dates can be trusted. Special treatment of X.509 certificate fields for self-signed certificate can be found in RFC 3280.[3]

There are at least two reasons why a self-signed certificate based PKI may have decreased overall risk. The first, also shared with private PKI systems, is that they avoid the problems of trusting third parties that may improperly sign certificates. Self-signed certificate transactions usually present a far smaller attack surface by eliminating both the complex certificate chain validation,[3] and CA revocation checks like CRL and OCSP.

Revocation of self-signed certificates differs from CA signed certificates. The self-signed certificate cannot (by nature) be revoked by a CA.[4] Revocation of a self-signed certificate is accomplished by removing it from the whitelist of trusted certificates (essentially the same as revoking trust in a CA). Failure to revoke a self-signed certificate may allow an attacker who has already gained access to monitor and inject data into a connection to spoof an identity if a private key has been compromised.

Other issues

Cost Self-signed certificates can be created for free using a wide variety of tools including OpenSSL, Java's keytool, Adobe Reader, and Apple's Keychain. Certificates bought from major CAs often cost around a hundred dollars per year. In December 2015 Mozilla Foundation launched Let's Encrypt, which allows one to obtain a Domain-validated certificate for free.[5]

Speed to Deploy Self-signed certificates require the two parties to interact (e.g. to securely trade public keys). Using a CA requires only the CA and the certificate holder to interact; the holder of the public key can validate its authenticity with the CA's root certificate.

Customization Self-signed certificates are easier to customize, for example a larger key size, contained data, metadata, etc.

See also

References

  1. ↑ PERLMAN, RADIA (1995). Network Security Private Communication in a PUBLIC World. Prentice Hall. p. 190. ISBN 0-13-061466-1.
  2. ↑ "Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". tools.ietf.org. Retrieved 2017-04-06.
  3. 1 2 "Certificate and CRL Profile - RFC 3280". tools.ietf.org. Retrieved 2017-04-06.
  4. ↑ http://www.ietf.org/rfc/rfc2459.txt
  5. ↑ "Public Beta". Let's encrypt. Retrieved 2015-12-06.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.