What is a Self Signed Certificate and How Does it Work?
A self signed certificate is an X.509 certificate that is not signed by a trusted Certificate Authority but rather is signed by its own private key.
This guide will cover everything you need to know about Self Signed Certificates including:
- What is a Self Signed Certificate?
- How is a Self Signed Certificate created?
- What are Best Practices for Self Signed Certificates?
- What are the Dangers of Self Signed Certificates?
- What are the Alternatives to Self Signed Certificates?
What is a Self Signed Certificate?
A Self Signed Certificate (SSC) is an X.509 (or similar) certificate that is not signed by a trusted Certificate Authority but instead is signed with its own private key. The purpose of a certificate is to provide trusted validation of identity or provide public keys for asymmetric encryption. The trust is validated using one or more trusted Certificate Authorities that form a chain of trust. The chain of trust is implemented by trusted Certificate Authorities which sign certificates. Certificate consumers validate a certificate was issued (signed) by a list of trusted Certificate Authorities. Certificates which are self signed do not use a Certificate Authority to create a certificate but instead use an untrusted private key. That means a SSC cannot be validated as trusted.
Self signed certificates are often used in SSL/TLS which require an X.509 certificate. However, like most all uses of SSC this is not secure as it's not possible to validate the certificate.
Creating a SSC is very easy which is why they are so appealing and used frequently. Applications which provide HTTPS (HTTP over SSL/TLS) and device manufacturers (routers, VPN servers, switches, etc) usually use a SSC to enable access to their services via HTTPS. The intent is the SSC is used to perform the initial configuration of the application/device including the provisioning of a certificate issued by a trusted Certificate Authority. Often times this is not done and the SSC created by the application/device is left in place for production use.
How is a Self Signed Certificate Created?
A self signed certificate is created by creating a private key and using it to sign a certificate created from a Certificate Signing Request (CSR). The high level steps are:
- Create private key
- Create Certificate Signing Request
- Create certificate from CSR and sign using private key
We will use OpenSSL to illustrate the process of how a self signed certificate is created.
STEP 1 - Create Private Key
Create a private key which will be used to sign the certificate request and certificate itself. In the command below we create a 2048 bit RSA key and save the key to the private.key file:
$ openssl genrsa -out private.key 2048 Generating RSA private key, 2048 bit long modulus (2 primes) .................................................................................................+++++ ..........................................................................................+++++ e is 65537 (0x010001)
STEP 2 - Create Certificate Signing Request (CSR)
In this step we create a Certificate Signing Request which contains the information we want placed in the certificate. We sign the CSR using the private key from private.key and store the CSR in the request.csr file.
$ openssl req -key private.key -new -out request.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:California Locality Name (eg, city) [Default City]:San Jose Organization Name (eg, company) [Default Company Ltd]:Revocent Inc Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:www.revocent.com Email Address []:[email protected] Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
STEP 3 - Create Self Signed Certificate
We will now create a self signed certificate using the same private key found in the CSR:
$ openssl x509 -signkey private.key -in request.csr -req -days 365 -out revocent.crt Signature ok subject=C = US, ST = California, L = San Jose, O = Revocent Inc, CN = www.revocent.com, emailAddress = [email protected] Getting Private key
The revocent.crt file now contains the self signed certificate.
What are best practices for Self Signed Certificates
Self-signed certificates (SSC) should be used sparingly and with great care. Keep in mind that whenever you use a self signed certificate you are not providing a secure connection in the case of a self-signed SSL/TLS certificate.
- Signing Root Certificate Authority certificates. When a Root CA certificate is created it must be self signed since there is no higher level in the chain of trust as the Root CA.
- Initial access to an application server or device using HTTP (HTTP over SSL/TLS). When an application server or device is initially configured it will not have a trusted certificate from the customer's PKI. It's usually acceptable for the application/device to automatically generate a SSC to allow access for the initial configuration. The application server/device should take steps to remind the customer to install a trusted CA certificate during initial configuration and to discourage the use of the auto generated SSC for any production use.
What are the dangers of Self Signed Certificates?
There are a number of dangers when using self-signed certificates. It's very important that both certificate creators and certificate users (such as application users) be aware of the limitations and risks of self-signed certificates.
DANGER #1
A self-signed certificate cannot be verified with a trusted source such as a Certificate Authority. That means the self-signed certificate may very well have been created by a malicious third-party which intercepted the application communication and is masquerading as the intended application server. A similar problem of trust exists with the self-signed certificate's subject. There is no means to valid the subject is truly what it says it is. An employee or malicious intruder could create a certificate for say "finance.contoso.com" even if they are not authorized to do so. Since the primary purpose of a certificate is to be able to verify it's authentic, the ability to trust the application server is compromised.
DANGER #2
There is no means to revoke a self-signed certificate. If the application server which provides the certificate is moved or decommissioned the server's certificate should be revoked so it cannot be used elsewhere. This is not possible with a self-signed certificate. In contrast, certificates issued by a CA can be revoked and applications can valid the revocation from trusted sources.
DANGER #3
The enterprise PKI/security team has little, if any visibility into what self-signed certificates are in use in their enterprise, who created the self-signed certificate, and if the identity of the self-signed certificate is valid.
The dangers of self-signed certificates are discussed in more details in Why Self-Signed Certificates Are Evil And Alternatives That Are Good
What are the Alternatives to Self Signed Certificates?
One of the biggest reasons self-signed certificates are created in enterprise environments is to rapidly create certificates without performing a lengthy, tedious manual certificate creation process. This problem can be solved quickly and securely by creating trusted, Certificate Authority issued certificates using an automated Certificate Lifecycle Management (CLM) solution such as CertAccord Enterprise. A CLM solution provides the ability to automatically push certificates to a large number of systems automatically or to provide a "self service" ability for an authorized user to create a certificate immediately without waiting for a long, drawn out manual certificate creation process.
Automate Trusted Certificate Creation and More
CertAccord Enterprise integrates with your trusted Microsoft PKI Certificate Authorities to automate the creation and renewal of X.509 certificates on Linux, Mac, and Windows. It can quickly create trusted certificates safely, securely, and deploy at scale.