Self-signed certificate

Last updated • 4 min readFrom Wikipedia, The Free Encyclopedia

In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.

Contents

For instance, if a website owner uses a self-signed certificate to provide HTTPS services, people who visit that website cannot be certain that they are connected to their intended destination. For all they know, a malicious third-party could be redirecting the connection using another self-signed certificate bearing the same holder name. The connection is still encrypted, but does not necessarily lead to its intended target. In comparison, a certificate signed by a trusted CA prevents this attack because the user's web browser separately validates the certificate against the issuing CA. The attacker's certificate fails this validation.

Benefits

Self-signed certificates can be created for free, using a wide variety of tools including OpenSSL, Java's keytool, Adobe Reader, wolfSSL and Apple's Keychain. They are easy to customize; e.g, they can have larger key sizes or hold additional metadata. Their use doesn't involve 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 certificate revocation checks like CRL and OCSP.

Trust issues

In a CA-based PKI system, parties engaged in secure communication must trust a CA, i.e. place the CA certificates in a whitelist of trusted certificates. Developers of web browsers may use procedures specified by the CA/Browser Forum to whitelist well-known, public certificate authorities. Individual groups and companies may whitelist additional, private CA certificates. 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 certificate's cryptographic 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 only be trusted when the values were verified out-of-band during the acceptance of the certificate, 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. [2] 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 formerly 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]

Revocation of self-signed certificates differs from CA-signed certificates. By nature, no entity (CA or others) can revoke a self-signed certificate. But one could invalidate a self-signed CA by removing it from the trust whitelist. [3]

Uses

Self-signed certificates have limited uses, e.g. in the cases where the issuer and the sole user are the same entity. For example, the Encrypting File System on Microsoft Windows issues a self-signed certificate on behalf of a user account to transparently encrypt and decrypt files on the fly. Another example is a root certificate, which is a form of self-signed certificate.

Name Confusion

The terms "self-signed" and "self-issued" are occasionally used interchangeably and "self-signed certificate" is sometimes even incorrectly used to indicate a certificate issued by a private (not publicly trusted) CA. [4] [5] [6]

RFC 5280 defines self-signed certificates as "self-issued certificates where the digital signature may be verified by the public key bound into the certificate" [7] whereas a self-issued certificate is a certificate "in which the issuer and subject are the same entity". While in the strict sense the RFC makes this definition only for CA certificates, there is no reason to also adopt that definition for end-entity certificates.

See also

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). ITU-T was formerly known as the Consultative Committee for International Telephony and Telegraphy (CCITT). X.500 was first approved in 1988. The directory services were developed to support requirements of X.400 electronic mail exchange and name lookup. The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) were partners in developing the standards, incorporating them into the Open Systems Interconnection suite of protocols. ISO/IEC 9594 is the corresponding ISO/IEC identification.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

<span class="mw-page-title-main">Certificate revocation list</span> A list of revoked digital certificates

In cryptography, a certificate revocation list (CRL) is "a list of digital certificates that have been revoked by the issuing certificate authority (CA) before their scheduled expiration date and should no longer be trusted".

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

S/MIME is a standard for public-key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 8551. It was originally developed by RSA Data Security, and the original specification used the IETF MIME specification with the de facto industry standard PKCS #7 secure message format. Change control to S/MIME has since been vested in the IETF, and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.

The certification path validation algorithm is the algorithm which verifies that a given certificate path is valid under a given public key infrastructure (PKI). A path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted certificate authority (CA).

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

Delegated Path Validation (DPV) is a cryptographic method used to offload the task of validating the certification path of digital certificates from the client to a trusted server. This process is integral to various security protocols that rely on Public Key Infrastructure (PKI). DPV aim to enhance the efficiency of certification path validation by leveraging a server dedicated to this task, which provides validation results to the client. This approach is particularly useful in resource-constrained environments where clients may not have the computational power to perform extensive certificate validation themselves.

Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed. The process employs the use of a cryptographic hash to validate authenticity and integrity. Code signing was invented in 1995 by Michael Doyle, as part of the Eolas WebWish browser plug-in, which enabled the use of public-key cryptography to sign downloadable Web app program code using a secret key, so the plug-in code interpreter could then use the corresponding public key to authenticate the code before allowing it access to the code interpreter's APIs.

The Time-Stamp Protocol, or TSP is a cryptographic protocol for certifying timestamps using X.509 certificates and public key infrastructure. The timestamp is the signer's assertion that a piece of electronic data existed at or before a particular time. The protocol is defined in RFC 3161. One application of the protocol is to show that a digital signature was issued before a point in time, for example before the corresponding certificate was revoked.

The Certificate Management Protocol (CMP) is an Internet protocol standardized by the IETF used for obtaining X.509 digital certificates in a public key infrastructure (PKI).

The Certification Authority Browser Forum, also known as the CA/Browser Forum, is a voluntary consortium of certification authorities, vendors of Internet browser and secure email software, operating systems, and other PKI-enabled applications that promulgates industry guidelines governing the issuance and management of X.509 v.3 digital certificates that chain to a trust anchor embedded in such applications. Its guidelines cover certificates used for the SSL/TLS protocol and code signing, as well as system and network security of certificate authorities.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of digital certificates. When an internet user interacts with a website, a trusted third party is needed to assure the user that the website is legitimate and that the website's encryption key is valid. This third party, called a certificate authority (CA), will issue a certificate for the website that the user can validate. The security of encrypted internet traffic (HTTPS) depends on the trust that certificates are only given out by the certificate authority and that the certificate authority has not been compromised.

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

References

  1. 1 2 Housley, Russ; Polk, Tim; Ford, Warwick S.; Solo, David (May 2002). "Certificate and CRL Profile – RFC 3280". tools.ietf.org. Archived from the original on 2017-04-26. Retrieved 2017-04-06.
  2. "How to bypass SSLHandshakeException". Archived from the original on 2021-08-01. Retrieved 2021-08-01.
  3. "RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile". www.ietf.org. January 1999. Archived from the original on 2012-12-14. Retrieved 2009-01-03.
  4. "How to Create Trusted Self-Signed SSL Certificates and Local Domains for Testing". "A self-signed certificate is a certificate that’s signed by the person creating it". Retrieved 2024-02-15.
  5. "Generate an Azure Application Gateway self-signed certificate with a custom root CA" . Retrieved 2024-02-15.
  6. "Creating a browser trusted, self signed, SSL certificate | by Thijs Busser | Medium". "a self signed SSL certificate to use for website development needs a root certificate". Retrieved 2024-02-15.
  7. https://datatracker.ietf.org/doc/html/rfc5280#section-3.2 [ bare URL ]
  8. "Public Beta". Let's encrypt. Archived from the original on 2018-04-07. Retrieved 2015-12-06.