Self-signed certificate

In cryptography and computer security, a self-signed certificate is a certificate that is not signed by a certificate authority (CA). These certificates are easy to make and do not cost money. However, they do not provide all of the security properties that certificates signed by a CA aim to provide. For instance, when a website owner uses a self-signed certificate to provide HTTPS services, people who visit that website will see a warning in their browser. Website visitors who bypass such warnings are exposed to a risk that a third party could intercept traffic to the website using the third-party's own self-signed certificate. This is a type of man-in-the-middle (MitM) attack, and it allows the third party to read and modify all data sent to or from the website by the target user.

By comparison, visitors to a website that uses a certificate signed by a CA will not see warnings about self-signed certificates. Because such visitors do not become accustomed to bypassing browser warnings, they are less vulnerable to a MitM attack. However, all website visitors may still be vulnerable to a MitM attack if a CA trusted by their browser is compromised or maliciously issues an incorrect certificate for the target website. (Most browsers also do not give warnings for visiting a website using unencrypted HTTP, which is no more secure than HTTPS with a self-signed certificate.)

In certificate applications outside of HTTPS in a web browser, self-signed certificates have different properties. For instance, if an HTTPS or TLS server is configured with a self-signed certificate, non-browser clients that will connect to that server may be configured to explicitly trust that specific self-signed certificate. So long as the configuration information for the client is provided securely, and the configuration is done correctly, this can result in secure communication between the client and the server that is not vulnerable to MitM.

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 are 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.[1]

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,[1] 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.[2] 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.[3]

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. "Certificate and CRL Profile - RFC 3280". tools.ietf.org. Retrieved 2017-04-06.
  2. http://www.ietf.org/rfc/rfc2459.txt
  3. "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.