Generating a Self-Signed Certificate

One of the most prevalent tasks in certificate management is generating a self-signed certificate. If you're developing an encrypted network or testing an HTTPS web server, obtaining a certificate is necessary.

The quickest and easiest method for this is to create a "self-signed" certificate. This type of certificate essentially declares: "I am the only authority and I affirm my own identity."

It’s important to understand that this certificate is not secure or trusted, as it validates itself without any credible certificate authority involved.

For a valid and trusted certificate, you could utilize a free service like Let’s Encrypt or purchase one from a company such as DigiCert.

For internal testing or development environments, a self-signed certificate is often sufficient. Let’s see how to generate a self-signed certificate using the openssl utility:

openssl req -new

-newkey rsa:4096 -nodes

-x509

-days 3650

-keyout self_signed.key

-out self_signed.pem

-subj '/CN=TestCertificate/C=US/ST=CA/L=SF/O=Test'

Let’s break down this command step by step:

• Create a new certificate request in the PKCS10 format.
• Generate a new 4096-byte private key for this request.
• Keep the private key unencrypted (no password).
• Produce a self-signed certificate (indicated by the -x509 flag).
• Set the certificate to expire in 10 years (longer durations are typical for offline root CAs).
• Save the private key to the file self_signed.key.
• Save the certificate to the file self_signed.pem.
• Include the specified subject details, such as country, state, and organization.

After executing this command, you will have two critical files:

• The first file, with a .key extension, is the private key used for the certificate. This is similar to an SSH key pair.
• The second file, ending with .pem, is the certificate itself. Once you possess both the certificate and the key, you can install them in services that require encryption.

Clients connecting to the service will recognize it as a self-signed certificate and may display a warning. While this certificate is not trusted, it will still encrypt traffic between the service.

Next, we’ll look at how to use our new self-signed certificate to sign other types of certificates.

Generating a Certificate Signing Request (CSR)

With our self-signed certificate in hand, we can act as a Certificate Authority (CA) and begin signing additional certificates. This establishes a chain of trust (albeit a weak one) and forms the basis of distributed PKI.

Suppose you have a new host that requires a certificate. This host and others within the same domain should trust each other and refer back to a central authority. This is the role of a certificate authority, or CA. We can generate unique certificates for all our hosts and sign them using a single CA.

To sign a host certificate, we must first create a Certificate Signing Request (CSR), which is a specific request from the host to the CA for signature.

Let’s create a new CSR for our TestHost:

openssl req -new

-newkey rsa:4096 -nodes

-keyout host.key

-out host.csr

-subj '/CN=TestHost/C=US/ST=CA/L=SF/O=Test'

Again, let’s break this down line by line:

• Create a new certificate request in PKCS10 format.
• Generate a new unencrypted 4096-byte private key for this request.
• Save the private key to host.key.
• Save the CSR to host.csr.
• Include the host subject information.

After executing this command, we will have a new CSR file ready to be signed by our CA. Next, let’s see how to do this.

Signing the CSR

The final step involves signing our CSR. We’ll use the host.csr file we created earlier and submit it to the CA. This could be done on a central server, a portal, etc. In this instance, we will sign it directly on the same host:

openssl x509 -req

-in host.csr

-CA self_signed.pem

-CAkey self_signed.key

-CAcreateserial

-out host.pem

-days 30 -sha256

Let’s break down what happens here:

• We’re performing an x509 request, which means we’re signing a certificate rather than creating a new request.
• Provide the previously created host CSR as input.
• Specify the self-signed CA certificate.
• Specify the self-signed CA private key.
• Create a serial number file to avoid errors during signing.
• Output the signed certificate as host.pem.
• The certificate is valid for 30 days and signed using the SHA256 algorithm.

Upon completion, we will have our signed host certificate. This certificate, along with any others signed by this CA, can be utilized to establish a system of trusted hosts within the domain.

It’s worth noting that host certificates typically have shorter expiration periods. A common recommendation is around 30 days, which encourages monthly renewals and prevents host certs from lingering for extended periods.

Inspecting Certificates

As we have several certificates in our environment, it’s beneficial to know how to inspect them. Some certificates have shorter lifespans than others. While an offline root CA might last for 10 years, a client certificate could be valid for as little as 24 hours.

Let’s utilize one final openssl command to inspect existing certificates:

openssl x509 -text -noout < cert.pem

This straightforward command provides a wealth of information at a glance, including:

• The issuer
• The expiration date
• The subject information
• Encryption details

Additional details, such as encrypted keys and cipher information, are also present but may not be as helpful for troubleshooting.

If you’re trying to determine when a certificate expires or who issued it, this is an excellent starting point.

Let’s examine what our initial self-signed certificate looks like:

Certificate:

Data:

Version: 1 (0x0)

Serial Number: 15449774297344832821 (0xd6689fddf532f535)

Signature Algorithm: sha256WithRSAEncryption

Issuer: CN=TestCertificate, C=US, ST=CA, L=SF, O=Test

Validity

Not Before: Sep 21 01:48:35 2022 GMT

Not After : Sep 18 01:48:35 2032 GMT

Subject: CN=TestCertificate, C=US, ST=CA, L=SF, O=Test

Everything looks good. We can quickly ascertain how long the certificate is valid, its origin, and its purpose.

Thank you for reading! If you found this article helpful, please follow and subscribe for more updates. Interested in more content? Check out these additional posts:

• A Simple Way To Make RPCs With Python
• Python Modules That Make Handling JSON Even Faster