OpenSSL Tutorial: Creating Your First Certificate

By /

OpenSSL Tutorial: Creating Your First Certificate – A Deep Dive

In the vast landscape of cybersecurity and network communication, digital certificates form the bedrock of trust and secure data exchange. Whether you’re securing a website with HTTPS, enabling secure email, signing software, or authenticating users and devices, certificates are indispensable. OpenSSL, the robust, open-source toolkit for Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols, is the de facto standard for generating, managing, and inspecting these certificates.

This comprehensive tutorial will guide you through the process of creating your very first digital certificate using OpenSSL. We won’t just provide commands; we’ll delve into the underlying concepts, explore the different components involved, and explain the significance of each step. By the end, you’ll not only have created a certificate but also gained a solid understanding of the fundamental principles of Public Key Infrastructure (PKI) and certificate management with OpenSSL.

Target Audience: This guide is intended for system administrators, developers, security enthusiasts, and anyone needing to understand or work with digital certificates and OpenSSL, particularly those new to the process.

What We Will Cover:

  1. Introduction to Core Concepts:
    • What is OpenSSL?
    • What are Digital Certificates (X.509)?
    • Public Key Cryptography (Asymmetric Encryption)
    • Hashing and Digital Signatures
    • Certificate Authorities (CAs) vs. Self-Signed Certificates
  2. Prerequisites: Installing and Verifying OpenSSL
  3. The Certificate Creation Process (Self-Signed):
    • Step 1: Generating a Private Key
    • Step 2: Creating a Certificate Signing Request (CSR)
    • Step 3: Generating the Self-Signed Certificate
    • Alternative: Combined Key and Certificate Generation
  4. Understanding the Generated Files:
    • Private Key (.key)
    • Certificate Signing Request (.csr)
    • Certificate (.crt, .pem)
  5. Inspecting Your Certificate: Viewing Details and Verification
  6. Use Cases for Self-Signed Certificates: When are they appropriate?
  7. Beyond Self-Signed: The Role of CAs and Next Steps
  8. Advanced Considerations:
    • Certificate Extensions (Subject Alternative Names – SANs)
    • Using Configuration Files (openssl.cnf)
    • Different Key Types (RSA vs. ECC)
    • Certificate Formats (PEM, DER, PKCS#12)
  9. Troubleshooting Common Issues
  10. Security Best Practices
  11. Conclusion

Let’s begin our journey into the world of OpenSSL and certificate creation.

1. Introduction to Core Concepts

Before we start typing commands, it’s crucial to understand the foundational concepts. This knowledge will transform the process from rote command execution into a meaningful understanding of digital trust.

What is OpenSSL?

OpenSSL is a powerful, commercial-grade, and full-featured toolkit for the TLS and SSL protocols. It’s also a general-purpose cryptography library. Developed by the OpenSSL Project, it provides:

  • Implementations of cryptographic algorithms: Symmetric ciphers (like AES), asymmetric ciphers (like RSA, ECC), hashing functions (like SHA-256).
  • Implementations of TLS/SSL protocols: Enabling secure communication over networks.
  • A command-line tool (openssl): Used for a wide range of tasks, including generating keys, creating CSRs, signing certificates, converting formats, testing connections, and much more.
  • Libraries: For developers to integrate cryptographic functions and TLS/SSL capabilities into their own applications.

It’s ubiquitous in the internet infrastructure, powering secure connections for web servers (Apache, Nginx), email servers, VPNs, and countless other applications.

What are Digital Certificates (X.509)?

Think of a digital certificate like an electronic passport or ID card. It binds an identity (like a person’s name, a server’s hostname, or an organization’s name) to a public key. This binding is asserted (digitally signed) by a trusted entity, typically a Certificate Authority (CA), or in the case of self-signed certificates, by the entity itself.

The most common standard for digital certificates is X.509. An X.509 certificate contains specific information, including:

  • Version: The X.509 version (usually v3 for modern certificates).
  • Serial Number: A unique identifier for the certificate, assigned by the issuer.
  • Signature Algorithm: The algorithm used by the issuer to sign the certificate (e.g., SHA256withRSA).
  • Issuer: The entity that signed and issued the certificate (e.g., a CA like Let’s Encrypt, or the subject itself for self-signed certs).
  • Validity Period: The dates (Not Before and Not After) defining when the certificate is valid.
  • Subject: The identity the certificate belongs to (e.g., the website domain name, organization details).
  • Subject Public Key Info: The public key associated with the subject, along with the algorithm (e.g., RSA, ECC).
  • Extensions (Optional, usually in v3): Additional information like Key Usage (signing, encryption), Extended Key Usage (server auth, client auth), Subject Alternative Names (SANs – crucial for multiple hostnames), Basic Constraints (identifying CAs), etc.
  • Issuer’s Digital Signature: The signature created by the issuer using their private key over the certificate’s content. This verifies the certificate’s authenticity and integrity.

Certificates allow others to verify that a specific public key truly belongs to the claimed subject, provided they trust the issuer.

Public Key Cryptography (Asymmetric Encryption)

This is the cornerstone upon which digital certificates are built. Unlike symmetric encryption (where the same key is used for encryption and decryption), asymmetric cryptography uses a pair of mathematically related keys:

  • Public Key: Can be shared freely without compromising security. It’s used to encrypt data for the owner of the key pair or to verify a digital signature created by the private key.
  • Private Key: Must be kept strictly secret by the owner. It’s used to decrypt data encrypted with the corresponding public key or to create digital signatures.

Anything encrypted with the public key can only be decrypted by the corresponding private key, and vice versa (though the latter is less common for encryption, it’s fundamental for digital signatures).

In the context of certificates: The certificate securely distributes the public key of the subject. The subject keeps the corresponding private key secret.

Hashing and Digital Signatures

  • Hashing: A hashing algorithm (like SHA-256) takes an input (any data, like the content of a certificate) and produces a fixed-size string of characters called a hash digest or simply “hash.” Key properties include:

    • Deterministic: The same input always produces the same hash.
    • One-way: It’s computationally infeasible to reverse the process (find the input from the hash).
    • Collision Resistant: It’s extremely difficult to find two different inputs that produce the same hash.
    • Avalanche Effect: A tiny change in the input results in a drastically different hash.
      Hashing ensures data integrity. If the data changes even slightly, the hash will change completely.

  • Digital Signature: This combines hashing and asymmetric cryptography to provide authenticity, integrity, and non-repudiation. Here’s how it works when a CA signs a certificate:

    1. The CA takes the certificate information (Subject, Public Key, Validity, etc.).
    2. The CA calculates a hash digest of this information using a specific algorithm (e.g., SHA-256).
    3. The CA encrypts this hash digest using its own private key. This encrypted hash is the digital signature.
    4. The digital signature is attached to the certificate.

    To verify the signature, anyone can:
    1. Obtain the CA’s public key (usually from the CA’s own certificate).
    2. Decrypt the digital signature using the CA’s public key to retrieve the original hash digest calculated by the CA.
    3. Independently calculate a hash digest of the received certificate information using the same hashing algorithm (e.g., SHA-256).
    4. Compare the decrypted hash (from step 2) with the independently calculated hash (from step 3). If they match, the signature is valid. This proves:
    * Authenticity: Only the CA, possessing the private key, could have created this signature.
    * Integrity: The certificate content hasn’t been altered since it was signed (otherwise the hashes wouldn’t match).

Certificate Authorities (CAs) vs. Self-Signed Certificates

  • Certificate Authority (CA): A trusted third-party organization whose job is to verify the identity of entities (like websites or organizations) and issue digital certificates binding those identities to public keys. Browsers, operating systems, and applications maintain a list of trusted root CAs. If a certificate is signed by a CA in this trusted list (or by an intermediate CA that chains back to a trusted root), it’s generally considered trustworthy. Examples: Let’s Encrypt, DigiCert, GlobalSign.

  • Self-Signed Certificate: A certificate that is signed using its own private key. The “Issuer” field and the “Subject” field typically contain the same information. Since it’s not signed by a universally trusted CA, browsers and applications will usually issue warnings because they cannot automatically verify the identity claims. There’s no external validation.

For this tutorial, we will create a self-signed certificate. While not suitable for public-facing websites, they are invaluable for development, testing, and internal networks where trust can be established manually or is implicitly understood.

2. Prerequisites: Installing and Verifying OpenSSL

Before you can create certificates, you need OpenSSL installed on your system.

  • Linux (Debian/Ubuntu):
    bash
    sudo apt update
    sudo apt install openssl
  • Linux (Fedora/CentOS/RHEL):
    bash
    sudo dnf update # or yum for older versions
    sudo dnf install openssl
  • macOS: OpenSSL is usually pre-installed. You can also install/update it using Homebrew:
    bash
    brew update
    brew install openssl
    # You might need to follow brew's instructions to link it properly
    # or use the path provided by brew, e.g., /usr/local/opt/openssl/bin/openssl
  • Windows:
    • WSL (Windows Subsystem for Linux): Install a Linux distribution (like Ubuntu) from the Microsoft Store and follow the Linux instructions above. This is often the easiest way for developers.
    • Git for Windows: Git Bash includes a version of OpenSSL.
    • Pre-compiled Binaries: Download pre-compiled binaries from reputable sources (e.g., Shining Light Productions – slproweb.com/products/Win32OpenSSL.html – always verify sources). Install them and add the OpenSSL bin directory to your system’s PATH environment variable.

Verifying the Installation:
Open your terminal or command prompt and run:
bash
openssl version
You should see output similar to this (the version number may vary):
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
If you get a “command not found” error, revisit the installation steps or check your system’s PATH configuration.

3. The Certificate Creation Process (Self-Signed)

We’ll now create a self-signed certificate in three distinct steps: generating the private key, creating a Certificate Signing Request (CSR), and finally, signing the CSR with the private key to generate the certificate. This breakdown helps understand the individual components.

Choose a Working Directory:
It’s good practice to create a dedicated directory for your keys and certificates.
bash
mkdir ~/openssl-tutorial
cd ~/openssl-tutorial

Step 1: Generating a Private Key

The private key is the secret component. It must be kept secure. We’ll generate an RSA private key, which is still the most common type, although Elliptic Curve Cryptography (ECC) is gaining traction.

Command:
bash
openssl genpkey -algorithm RSA -out private.key -pkeyopt rsa_keygen_bits:4096

Explanation:

  • openssl: Invokes the OpenSSL command-line tool.
  • genpkey: The command (preferred over older genrsa) for generating private keys (and parameters).
  • -algorithm RSA: Specifies the algorithm to use (RSA in this case).
  • -out private.key: Specifies the output filename for the private key (private.key). The .key extension is conventional.
  • -pkeyopt rsa_keygen_bits:4096: An option specific to the chosen algorithm. For RSA, this sets the key length in bits.
    • 2048 bits is generally considered the minimum secure length currently.
    • 4096 bits provides stronger security but is computationally more intensive. We’ll use 4096 for this example.

Output:
You won’t see much output, just the command prompt returning. A file named private.key will be created in your current directory. This file is in PEM (Privacy-Enhanced Mail) format, which is Base64 encoded text with header and footer lines (-----BEGIN PRIVATE KEY----- and -----END PRIVATE KEY-----).

Securing the Private Key (Optional but Recommended):
The command above creates an unencrypted private key. For better security, especially in production or sensitive environments, you should encrypt the private key with a passphrase.

Command (Encrypted Key):
bash
openssl genpkey -algorithm RSA -out private_encrypted.key -aes256 -pkeyopt rsa_keygen_bits:4096

  • -aes256: This flag tells OpenSSL to encrypt the output private key using the AES-256 symmetric cipher.
  • You will be prompted to enter and verify a passphrase. Choose a strong passphrase and remember it! If you lose the passphrase, the key is unusable.

Using an encrypted key means you’ll need to enter the passphrase whenever the key is used (e.g., when starting a web server that uses the corresponding certificate).

For this tutorial, we’ll proceed using the unencrypted private.key for simplicity, but be aware of the security implications.

Viewing the Key (Optional):
You can view the details of the private key (don’t do this casually with sensitive keys):
bash
openssl pkey -in private.key -text -noout
This will display the private exponent, prime numbers, and other components of the RSA key in human-readable form (though still quite technical).

Step 2: Creating a Certificate Signing Request (CSR)

A CSR is a formal request sent to a Certificate Authority (CA) to obtain a digital certificate. It contains information identifying the requester (the “Subject”) and the public key corresponding to their private key. Even though we are creating a self-signed certificate (acting as our own CA), generating a CSR is a standard part of the workflow and helps structure the information correctly.

Command:
bash
openssl req -new -key private.key -out certificate.csr -sha256

Explanation:

  • req: The OpenSSL command for creating and processing certificate requests (CSRs).
  • -new: Specifies that we want to generate a new CSR.
  • -key private.key: Specifies the private key file to use. The public key is derived from this private key and embedded in the CSR.
  • -out certificate.csr: Specifies the output filename for the CSR (certificate.csr). The .csr extension is conventional.
  • -sha256: Specifies that the CSR should be signed (a self-signature on the request itself, mainly for integrity) using the SHA-256 hash algorithm. This is a modern, secure choice.

Interactive Prompt:
After running this command, OpenSSL will prompt you to enter information that will form the Distinguished Name (DN) of the certificate’s Subject field.

“`
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) [AU]:UK
State or Province Name (full name) [Some-State]:London
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Test Company Ltd
Organizational Unit Name (eg, section) []:Development Department
Common Name (e.g. server FQDN or YOUR name) []:myt Mytesthost.local
Email Address []:admin@my Mytesthost.local

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
“`

Explanation of Fields:

  • Country Name (C): The two-letter ISO code for the country (e.g., US, UK, DE, FR).
  • State or Province Name (ST): The full name of the state or province (e.g., California, Ontario, Bavaria).
  • Locality Name (L): The city or locality name (e.g., San Francisco, Toronto, Munich).
  • Organization Name (O): The legal name of the organization or company (e.g., Example Inc., My Company Ltd).
  • Organizational Unit Name (OU): A division or department within the organization (e.g., IT Department, Web Services, Marketing). You can have multiple OUs.
  • Common Name (CN): This is critically important.
    • For SSL/TLS server certificates, this must be the Fully Qualified Domain Name (FQDN) of the server the certificate will protect (e.g., www.example.com, secure.internal.net). Browsers and clients check that the CN matches the hostname they are connecting to.
    • For client certificates or other types, it might be a username, email address, or device ID.
    • For our self-signed test, we used my Mytesthost.local. If you were making this for a local web server accessible at dev.local, you would enter dev.local.
    • Important Note: While historically CN was used for hostname validation, modern practice relies heavily on Subject Alternative Names (SANs), which we’ll discuss later. However, the CN is still typically required.
  • Email Address: An email address associated with the certificate request (often an administrative contact).

Extra Attributes:

  • Challenge Password: An optional password used by some CAs for additional verification or revocation purposes. Generally leave this blank unless you have a specific reason or your CA requires it. It’s often confusing and not widely used.
  • Optional Company Name: Another optional field, usually left blank.

Fill these fields accurately according to the intended use of the certificate. For a self-signed certificate used in testing, exact legal names might not be critical, but the Common Name should reflect how you intend to access the resource it protects (e.g., the hostname).

Non-Interactive CSR Generation:
If you need to script this process, you can provide the subject information directly on the command line using the -subj option. Be careful with special characters and quoting.

bash
openssl req -new -key private.key -out certificate.csr -sha256 \
-subj "/C=UK/ST=London/L=London/O=My Test Company Ltd/OU=Development Department/CN=my Mytesthost.local/emailAddress=admin@my Mytesthost.local"
The format is /Type0=Value0/Type1=Value1/....

Viewing the CSR (Optional):
You can inspect the contents of the CSR file:
bash
openssl req -in certificate.csr -text -noout -verify
* -in certificate.csr: Specifies the CSR file to read.
* -text: Displays the CSR content in human-readable text.
* -noout: Prevents outputting the encoded version of the request.
* -verify: Checks the signature on the CSR itself.

This will show you the Subject DN you entered, the public key information, and the signature algorithm used.

Step 3: Generating the Self-Signed Certificate

Now we have the private key (private.key) and the CSR (certificate.csr). The final step is to act as our own CA and “sign” the CSR using our private key, creating the actual X.509 certificate.

Command:
bash
openssl x509 -req -in certificate.csr -signkey private.key -out certificate.crt -days 365 -sha256

Explanation:

  • x509: The OpenSSL command for processing X.509 certificates.
  • -req: Specifies that the input (-in) is a CSR (certificate request).
  • -in certificate.csr: The input CSR file we created in Step 2.
  • -signkey private.key: The crucial part for self-signing. This tells OpenSSL to use the specified private key (private.key) to sign the certificate. OpenSSL extracts the public key from the CSR and the subject information, bundles it with other details (like validity), and then signs the whole thing using private.key.
  • -out certificate.crt: The output filename for the generated certificate (certificate.crt). Common extensions are .crt, .pem, or .cer.
  • -days 365: Sets the validity period of the certificate in days from the current time. 365 days (1 year) is common for testing. Production certificates obtained from CAs often have shorter validity periods now (e.g., 90 days for Let’s Encrypt).
  • -sha256: Specifies that the SHA-256 algorithm should be used for the certificate’s digital signature. This should ideally match or be stronger than the hash used in the CSR signature.

Output:
You’ll see output similar to:
Signature ok
subject=C = UK, ST = London, L = London, O = My Test Company Ltd, OU = Development Department, CN = my Mytesthost.local, emailAddress = admin@my Mytesthost.local
Getting Private key
A file named certificate.crt will be created. This is your self-signed X.509 certificate in PEM format.

Congratulations! You have successfully generated:
1. A private key (private.key)
2. A certificate signing request (certificate.csr)
3. A self-signed certificate (certificate.crt)

Alternative: Combined Key and Certificate Generation

OpenSSL provides a shortcut command to generate a private key and a self-signed certificate simultaneously, bypassing the separate CSR creation step. This is convenient for quick testing but offers less granular control and doesn’t produce a separate CSR file.

Command:
bash
openssl req -x509 -newkey rsa:4096 -keyout private_combined.key -out certificate_combined.crt -sha256 -days 365 -nodes \
-subj "/C=UK/ST=London/L=London/O=My Quick Test/OU=Testing/CN=quicktest.local"

Explanation of New/Changed Options:

  • req: Still using the certificate request command.
  • -x509: This flag tells req to output a self-signed certificate instead of a CSR.
  • -newkey rsa:4096: Generates a new RSA private key of 4096 bits on the fly.
  • -keyout private_combined.key: Specifies where to save the newly generated private key.
  • -out certificate_combined.crt: Specifies where to save the generated self-signed certificate.
  • -sha256: Hash algorithm for the certificate signature.
  • -days 365: Validity period.
  • -nodes: (Short for “no DES”). This tells OpenSSL not to encrypt the output private key. If you omit this, you will be prompted for a passphrase to protect private_combined.key.
  • -subj "/C=...": Provides the subject information non-interactively (optional; omit it to be prompted).

This single command produces private_combined.key and certificate_combined.crt. It’s efficient but hides the distinct steps of key generation, CSR creation, and signing. For learning, the three-step process is more instructive.

4. Understanding the Generated Files

Let’s recap the purpose and nature of the files we created in the three-step process:

  1. private.key:

    • Content: Contains the RSA private key components in PEM format (-----BEGIN PRIVATE KEY-----).
    • Security: Highly sensitive. Must be kept secret and protected. Anyone with this key can impersonate the identity associated with the certificate, decrypt messages intended for it, and sign data as if they were the owner. File permissions should restrict access (e.g., chmod 600 private.key on Linux/macOS). If generated with a passphrase, the passphrase is also critical.
    • Usage: Used by the server/application (e.g., web server, email client) to decrypt incoming TLS connections, sign outgoing data (like during the TLS handshake), and was used by us to sign the certificate itself.

  2. certificate.csr:

    • Content: Contains the Subject information (DN), the public key corresponding to private.key, and potentially requested extensions, all in PEM format (-----BEGIN CERTIFICATE REQUEST-----). It also includes a self-signature for integrity.
    • Security: Not sensitive. Contains only public information.
    • Usage: Primarily used to request a certificate from a real Certificate Authority (CA). The CA verifies the information in the CSR (according to its policies) and then issues a certificate based on it. For self-signing, it served as structured input to the openssl x509 command. You often don’t need to keep the CSR file after the certificate is generated unless you need to resubmit it.

  3. certificate.crt:

    • Content: The X.509 digital certificate in PEM format (-----BEGIN CERTIFICATE-----). Contains the Subject information, the public key, the validity period, usage constraints, information about the Issuer (which, in this case, is the same as the Subject), and the digital signature created using private.key.
    • Security: Public information. Designed to be shared. It’s distributed to clients (e.g., web browsers) connecting to a server, or included in signed emails/documents.
    • Usage: Presented by a server during a TLS handshake to prove its identity and provide its public key. Clients use it to verify the server’s identity (checking the hostname and trusting the issuer) and to encrypt data (like the symmetric session key) that only the server (with its private key) can decrypt.

PEM Format:
All three files we generated use the PEM format. It’s a text-based format that uses Base64 encoding for the binary certificate/key data, enclosed within plain-text headers and footers (e.g., -----BEGIN...-----, -----END...-----). This makes it easy to copy/paste or transmit via email, although binary formats like DER also exist.

5. Inspecting Your Certificate

Once you have the certificate (certificate.crt), you’ll often want to examine its contents to verify the details.

Command to View Certificate Details:
bash
openssl x509 -in certificate.crt -text -noout

Explanation:

  • x509: The certificate utility command.
  • -in certificate.crt: Specifies the certificate file to inspect.
  • -text: Decodes the certificate structure and displays its contents in a human-readable text format.
  • -noout: Prevents outputting the PEM-encoded version of the certificate.

Example Output Analysis (abbreviated and annotated):

“`
Certificate:
Data:
Version: 3 (0x2) # X.509 Version 3
Serial Number:
d8:e8:a5:d6:b0:f3:a1:b2:4c:3d:e9:f0:a0:b1:c2:d3:e4:f5:a6:b7 # Unique serial (generated by OpenSSL)
Signature Algorithm: sha256WithRSAEncryption # Algorithm used to sign this cert
Issuer: C = UK, ST = London, L = London, O = My Test Company Ltd, OU = Development Department, CN = my Mytesthost.local, emailAddress = admin@my Mytesthost.local
# — Identifies who signed the certificate. —
# — For self-signed, this is the same as the Subject. —
Validity
Not Before: Nov 18 10:30:00 2023 GMT # Start date/time
Not After : Nov 17 10:30:00 2024 GMT # Expiry date/time (matches -days 365)
Subject: C = UK, ST = London, L = London, O = My Test Company Ltd, OU = Development Department, CN = my Mytesthost.local, emailAddress = admin@my Mytesthost.local
# — Identifies who the certificate belongs to. —
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit) # Algorithm and key size
Modulus: # The actual public key modulus (long hex string)
00:c1:d2:…
Exponent: 65537 (0x10001) # Public exponent (usually this value)
X509v3 extensions: # — V3 extensions provide additional info —
X509v3 Basic Constraints:
CA:FALSE # Indicates this is NOT a Certificate Authority certificate
Netscape Cert Type:
SSL Server # Older extension indicating usage (less common now)
Netscape Comment:
OpenSSL Generated Certificate # Comment added by OpenSSL
X509v3 Subject Key Identifier: # Hash of the public key, helps identify the key
E1:F2:…
X509v3 Authority Key Identifier: # Helps identify the signer’s key
keyid:E1:F2:…
# — In self-signed certs, Subject Key ID and Authority Key ID match —

Signature Algorithm: sha256WithRSAEncryption # Confirms signature algorithm again
Signature Value: # The actual digital signature (long hex string)
    1f:8b:...

—–BEGIN CERTIFICATE—–
MIIG… # The Base64 encoded certificate data follows
—–END CERTIFICATE—–
“`

Key things to check:
* Issuer vs. Subject: Are they identical (confirming it’s self-signed)?
* Validity Period: Is it correct?
* Subject CN: Does it match the intended hostname/identity?
* Public Key Algorithm & Size: Is it RSA 4096 bits as requested?
* Signature Algorithm: Is it SHA256 with RSA?
* Basic Constraints: Is CA:FALSE (unless you intended to create a self-signed CA)?

Verifying Key/Certificate Match:
You can mathematically verify that the public key inside the certificate corresponds to your private key. This involves extracting the public modulus (a large number that’s part of both the public and private key) from both files and comparing them. A simple way is to hash the modulus from each:

“`bash

Extract & hash modulus from private key

openssl pkey -in private.key -pubout -outform pem | openssl pkey -pubin -text -noout | grep ‘Modulus:’ -A 15 | sed ‘1d’ | tr -d ‘ \n:’ | openssl sha256

Extract & hash modulus from certificate

openssl x509 -in certificate.crt -text -noout | grep ‘Modulus:’ -A 15 | sed ‘1d’ | tr -d ‘ \n:’ | openssl sha256
``
*(Note: These commands extract the hex representation of the modulus, clean it up, and hash it. The exact commands might vary slightly based on OpenSSL version and OS, especially thegrep/sed` parts.)*

If the resulting SHA-256 hashes are identical, the private key and the certificate belong together.

A simpler, often sufficient check using OpenSSL’s built-in modulus output:
bash
openssl pkey -in private.key -noout -modulus | openssl md5
openssl x509 -in certificate.crt -noout -modulus | openssl md5
If the MD5 hashes match, the key and certificate correspond. (Using MD5 here is just for comparison brevity, not for cryptographic security).

6. Use Cases for Self-Signed Certificates

Self-signed certificates are useful but have significant limitations.

Appropriate Uses:

  1. Development Environments: Securing local development servers (e.g., localhost, dev.local). Developers can manually add the self-signed certificate to their browser or system trust store to bypass warnings on their machine only.
  2. Testing Environments: Testing TLS configurations or application features that require HTTPS before deploying with a CA-signed certificate.
  3. Internal Networks/Services: Securing communication between servers or services within a private network where all clients can be configured to trust the specific self-signed certificate or a private internal CA. Examples include internal APIs, databases, or management interfaces not exposed to the public internet.
  4. Point-to-Point Encryption: Situations where two specific endpoints communicate, and the certificate can be manually installed and trusted on the peer.
  5. Creating a Root CA: A self-signed certificate can serve as the root certificate for your own private Certificate Authority (a more advanced topic).

Inappropriate Uses:

  1. Public-Facing Websites: Never use a self-signed certificate on a public website. Users will see prominent security warnings (“Your connection is not private,” “Warning: Potential Security Risk Ahead”), severely damaging trust and deterring visitors. Search engines may also penalize sites with invalid certificates.
  2. Services Requiring Public Trust: Any service where clients (users, other external systems) need to automatically verify the server’s identity without manual configuration.

The core issue is the lack of external validation by a trusted third party. Browsers and operating systems have no way to know if the entity presenting the self-signed certificate is truly who they claim to be.

7. Beyond Self-Signed: The Role of CAs and Next Steps

For public trust, you need a certificate signed by a recognized Certificate Authority (CA). The process builds upon what we learned:

  1. Generate Private Key: Same as Step 1 (openssl genpkey ...). Keep this key secure!
  2. Generate CSR: Same as Step 2 (openssl req -new ...). Ensure the Common Name (and/or SANs) correctly matches the public domain name(s) you want to secure (e.g., www.yourdomain.com).
  3. Submit CSR to CA: Instead of self-signing (Step 3), you submit the certificate.csr file (the text content, usually via a web form) to your chosen CA (e.g., Let’s Encrypt, DigiCert, GoDaddy, etc.).
  4. CA Verification: The CA performs validation checks to ensure you control the domain name listed in the CSR. Common methods include:
    • Email Validation: Sending a verification email to a standard address (admin@, hostmaster@) at the domain.
    • DNS Validation: Requiring you to add a specific TXT record to your domain’s DNS zone.
    • HTTP Validation: Requiring you to place a specific file on your web server at a known location.
  5. CA Issues Certificate: Once validation is complete, the CA signs your CSR’s public key and subject information using its own intermediate private key, creating the certificate. They will provide you with:
    • Your Server Certificate: The certificate for your domain.
    • Intermediate Certificate(s): One or more certificates forming a “chain” from your server certificate up to the CA’s trusted root certificate.
    • (Sometimes) The Root Certificate (though usually already present in trust stores).
  6. Install Certificate Chain: You configure your web server (Apache, Nginx, etc.) or application to use your private key and the full certificate chain (your server certificate + the intermediate certificate(s) bundled together, usually in that order).

Clients connecting to your server receive the certificate chain. They verify each signature, starting from your server certificate signed by the intermediate, the intermediate signed by another intermediate or the root, until they reach a root CA certificate present in their trust store. This establishes the chain of trust.

8. Advanced Considerations

While our basic self-signed certificate works, modern TLS practices involve more details.

Certificate Extensions (Subject Alternative Names – SANs)

The Common Name (CN) field was historically used to identify the server hostname. However, it’s limited to a single name and its use for hostname validation is deprecated by modern standards (RFC 6125).

The standard way to specify the domain names a certificate is valid for is the Subject Alternative Name (SAN) extension. This extension can list multiple DNS names, IP addresses, email addresses, etc. Browsers and clients primarily check the SAN extension for matches.

Why SANs are Crucial:

  • Multiple Hostnames: Secure www.example.com, example.com, api.example.com, mail.example.com all with a single certificate.
  • IP Addresses: Secure services accessed directly via IP address (less common for public sites, more for internal ones).
  • Modern Compatibility: Browsers like Chrome ignore the CN for hostname validation if SANs are present. Certificates must include the relevant hostnames in the SAN extension.

Adding SANs during Self-Signing:

You cannot add SANs directly via the standard interactive openssl req prompt or the basic -subj argument. There are two main ways:

  1. Using -addext (OpenSSL 1.1.1+): Add extensions directly during the x509 signing step.
    bash
    openssl x509 -req -in certificate.csr -signkey private.key -out certificate_san.crt -days 365 -sha256 \
    -extfile <(printf "subjectAltName=DNS:my Mytesthost.local,DNS:alt Mytesthost.local,IP:192.168.1.10")

    • -extfile <(printf "..."): This uses bash process substitution (<(...)) to pass the extension configuration directly. The content is subjectAltName=type:value,type:value,.... Common types are DNS and IP.
    • Alternatively, create a small text file (e.g., san.ext) with the line subjectAltName=DNS:my Mytesthost.local,DNS:alt Mytesthost.local,IP:192.168.1.10 and use -extfile san.ext.

  2. Using a Configuration File: This is the most robust method, especially for complex scenarios. We modify the OpenSSL configuration file (or a copy) to include the desired extensions when generating the CSR or when signing. See the next section.

When you inspect a certificate with SANs using openssl x509 -text -noout, you’ll see an X509v3 Subject Alternative Name section listing the specified names/IPs.

Using Configuration Files (openssl.cnf)

OpenSSL’s behavior is heavily influenced by its configuration file (often openssl.cnf, openssl.cfg, or located in /etc/ssl/, /usr/lib/ssl/, etc.). You can find the default location using openssl version -d.

Using a config file allows you to pre-define settings for CSR generation, certificate signing, extensions, and more. This is ideal for repeatability and complex setups.

Example: Generating a CSR with SANs via Config:

  1. Find and Copy the Default Config:
    bash
    openssl version -d
    # Example output: OPENSSLDIR: "/usr/lib/ssl"
    cp /usr/lib/ssl/openssl.cnf my_openssl.cnf

  2. Edit my_openssl.cnf:

    • Locate the [ req ] section. Uncomment or add the line: req_extensions = v3_req (or a custom section name).
    • Locate the [ req_distinguished_name ] section. You can optionally set default values here to avoid prompts.
    • Locate or create the [ v3_req ] section (or your custom name). Add the subjectAltName extension here:
      ini
      [ v3_req ]
      basicConstraints = CA:FALSE
      keyUsage = nonRepudiation, digitalSignature, keyEncipherment
      subjectAltName = @alt_names
    • Create a new section named [ alt_names ] (referenced by @alt_names) and define your SANs:
      ini
      [ alt_names ]
      DNS.1 = my Mytesthost.local
      DNS.2 = alt Mytesthost.local
      IP.1 = 192.168.1.10
      IP.2 = ::1

  3. Generate the CSR using the Config:
    “`bash
    # Generate private key first (if not already done)
    openssl genpkey -algorithm RSA -out private_san.key -pkeyopt rsa_keygen_bits:2048

    Generate CSR using the custom config

    openssl req -new -key private_san.key -out certificate_san.csr -sha256 -config my_openssl.cnf
    ``
    * You'll still be prompted for the DN fields (unless defaults were set in the config).
    * The generated    certificate_san.csr` will now include the SAN extension request.

  4. Sign the CSR (Self-Signed Example):
    bash
    openssl x509 -req -in certificate_san.csr -signkey private_san.key -out certificate_san.crt -days 365 -sha256 \
    -extensions v3_req -extfile my_openssl.cnf

    • -extensions v3_req: Tells x509 to copy extensions from the specified section in the config file.
    • -extfile my_openssl.cnf: Specifies the config file containing the [v3_req] section.

This method ensures the SANs are correctly embedded either in the CSR (if requested from a CA) or directly in the final certificate.

Different Key Types (RSA vs. ECC)

While RSA is traditional, Elliptic Curve Cryptography (ECC) offers equivalent security with much smaller key sizes, leading to faster computations (especially during the TLS handshake) and lower overhead.

Generating an ECC Private Key (e.g., using NIST P-256 curve):
bash
openssl genpkey -algorithm EC -out private_ecc.key -pkeyopt ec_paramgen_curve:P-256
* -algorithm EC: Specifies Elliptic Curve.
* -pkeyopt ec_paramgen_curve:P-256: Selects the specific curve. P-256 (secp256r1) is widely supported. Other common choices include P-384 and P-521.

The rest of the process (creating a CSR, signing the certificate) remains conceptually the same, just substitute private_ecc.key where appropriate. The resulting certificate will have an EC Public-Key section instead of RSA.
“`bash

Create CSR with ECC key

openssl req -new -key private_ecc.key -out cert_ecc.csr -sha256 -subj “/CN=ecc Mytesthost.local”

Create Self-Signed Cert with ECC key

openssl x509 -req -in cert_ecc.csr -signkey private_ecc.key -out cert_ecc.crt -days 365 -sha256
“`

Certificate Formats (PEM, DER, PKCS#12)

  • PEM (Privacy-Enhanced Mail): The most common format we’ve been using. Base64 encoded ASCII text with -----BEGIN...----- and -----END...----- headers/footers. Can contain certificates, private keys, CSRs, etc. Often uses .pem, .crt, .cer, .key extensions. Preferred by many Unix/Linux systems (Apache, Nginx).

  • DER (Distinguished Encoding Rules): A binary format for certificates and private keys. Contains the same information as PEM but in a compact binary structure. Often uses .der or .cer extensions. Common in Windows environments and Java key stores.

  • PKCS#12 (PFX): A binary format designed to bundle a private key and its corresponding certificate chain (and potentially other items) into a single, password-protected file. Very common in Windows environments (IIS) and for distributing client certificates with their keys. Often uses .pfx or .p12 extensions.

Conversion Examples using OpenSSL:

  • PEM to DER (Certificate):
    bash
    openssl x509 -in certificate.crt -outform DER -out certificate.der
  • DER to PEM (Certificate):
    bash
    openssl x509 -inform DER -in certificate.der -out certificate_from_der.pem
  • PEM Key and Cert to PKCS#12:
    bash
    # Assumes certificate.crt contains the cert and private.key contains the key
    openssl pkcs12 -export -out certificate_bundle.pfx -inkey private.key -in certificate.crt
    # You will be prompted to set an export password for the .pfx file
    # Optionally add -certfile intermediate_ca.crt to include chain certificates

  • PKCS#12 to PEM (Extract Key and Cert):
    “`bash
    # Extract private key
    openssl pkcs12 -in certificate_bundle.pfx -nocerts -out private_from_pfx.key -nodes
    # Enter import password for .pfx; -nodes prevents encrypting output key

    Extract certificate(s)

    openssl pkcs12 -in certificate_bundle.pfx -nokeys -out certificate_from_pfx.pem

    Enter import password for .pfx

    “`

9. Troubleshooting Common Issues

  • Browser Trust Warnings: Expected for self-signed certificates on public sites. For development, you may need to add the certificate.crt to your browser’s or OS’s trust store (process varies by browser/OS) or accept the security exception.
  • “Unable to load Private Key” / “Bad Password Read”: If you encrypted your private key, ensure you’re providing the correct passphrase when prompted (e.g., by a web server on startup). If using -nodes wasn’t intended, regenerate the key with encryption. If the key file is corrupted, regenerate it.
  • “Certificate Signature Failure” / “Verification Error”: Could indicate a mismatch between the private key used for signing and the public key in the certificate/CSR, or file corruption. Use the verification commands (openssl pkey/x509 -modulus) to check the key pair.
  • Incorrect Common Name / SAN: If clients complain about hostname mismatch (e.g., NET::ERR_CERT_COMMON_NAME_INVALID), ensure the CN and/or SAN entries in the certificate correctly match the exact hostname(s) clients use to access the server. Regenerate the CSR and certificate with the correct names. Remember the importance of SANs!
  • Certificate Expired: Certificates have a defined validity period. If the current date is outside the Not Before / Not After range, the certificate is invalid. You need to generate a new certificate (often using the existing private key and a new CSR, or generating all new components).
  • Command Not Found: OpenSSL is not installed or not in the system’s PATH environment variable. Revisit installation/configuration.
  • Permission Denied: Ensure you have read permissions for input files (.key, .csr) and write permissions in the output directory. Private key files should have restricted permissions (chmod 600).

10. Security Best Practices

  • Protect Your Private Keys: This is paramount.
    • Use strong passphrases to encrypt sensitive private keys.
    • Restrict file system permissions (e.g., chmod 400 or 600 on Linux/macOS, appropriate ACLs on Windows).
    • Store keys securely, potentially using hardware security modules (HSMs) for high-value keys.
    • Never share private keys.
  • Use Strong Keys and Algorithms:
    • RSA keys: Minimum 2048 bits, 4096 bits recommended for longevity.
    • ECC keys: Use standard, reputable curves like P-256 (secp256r1) or stronger.
    • Use SHA-256 or stronger hash algorithms (SHA-1 is broken, MD5 is insecure).
  • Use SANs: Always include hostnames in the Subject Alternative Name extension, even if also present in the CN.
  • Appropriate Validity Periods: Don’t issue certificates with excessively long lifetimes. Shorter lifetimes (e.g., 1 year, 90 days) reduce the window of exposure if a key is compromised. Automate renewal where possible.
  • Keep OpenSSL Updated: Patch vulnerabilities by regularly updating your OpenSSL installation.
  • Understand the Use Case: Use self-signed certificates only where appropriate (dev, test, internal). Use CA-signed certificates for public-facing services.
  • Implement Certificate Revocation Checking (where applicable): For CAs (especially private ones), ensure clients can check Certificate Revocation Lists (CRLs) or use the Online Certificate Status Protocol (OCSP) to verify that a certificate hasn’t been revoked before its expiry date.

11. Conclusion

Creating your first certificate with OpenSSL might seem daunting initially, but by breaking it down into generating a private key, creating a Certificate Signing Request, and signing the certificate, the process becomes much clearer. We’ve journeyed from the fundamental concepts of public key cryptography, hashing, and digital signatures to the practical OpenSSL commands needed to generate a self-signed X.509 certificate.

We explored the importance of protecting the private key, the structure of certificates and CSRs, and how to inspect their contents. We also highlighted the critical role of Subject Alternative Names (SANs) for modern compatibility and discussed the differences between self-signed and CA-signed certificates, emphasizing the appropriate use cases for each. Touching upon configuration files, alternative key types like ECC, and different file formats provides a foundation for more advanced usage.

While we focused on self-signed certificates, the skills you’ve learned – generating keys, crafting CSRs, and understanding certificate structures – are directly applicable when obtaining publicly trusted certificates from Certificate Authorities.

OpenSSL is an incredibly versatile tool with a vast array of options and capabilities far beyond what we’ve covered here. This tutorial serves as your starting point. Continue exploring, experiment with different options, consult the man pages (man openssl, man x509, man req, etc.), and practice generating and managing certificates to solidify your understanding. Secure communication is built on trust, and understanding how that trust is established through certificates and tools like OpenSSL is a vital skill in today’s connected world.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top