OpenSSL Generate CSR with SANs: Securing Multiple Hostnames

When securing websites or applications, administrators often turn to the powerful OpenSSL toolkit, especially in Linux environments or for command-line workflows. A fundamental task is using OpenSSL Generate CSR to create the Certificate Signing Request needed to obtain an SSL/TLS certificate. But what happens when you need a single certificate to cover multiple hostnames, like www.yourdomain.com, yourdomain.com, and mail.yourdomain.com? This requires including Subject Alternative Names (SANs) in your certificate.

A common point of confusion arises here. People often ask if they can simply add san to certificate after it’s already been issued. The short answer is no. This guide will walk you through the correct process: how to use OpenSSL to generate a CSR that includes SANs from the start, and explain why modifying an existing certificate isn’t possible, ensuring you get the right Multi-Domain (SAN) certificate from providers like sslrepo.com.

Key Takeaways

• OpenSSL for CSRs: A standard command-line tool to generate CSRs and private keys.
• SANs Needed for Multiple Hostnames: To secure multiple domains/subdomains with one certificate, you need Subject Alternative Names (SANs) listed within it.
• Cannot Modify Issued Certs: You cannot “add san to certificate” after it has been issued by a Certificate Authority (CA). Certificates are cryptographically immutable.
• Generate CSR with SANs: The correct process involves specifying all required hostnames (including SANs) during the CSR generation using OpenSSL, typically via a configuration file.
• Configuration File: OpenSSL’s req command usually needs a .cnf configuration file to properly include SAN extensions in the CSR.
• Result: This process yields a CSR ready for ordering a Multi-Domain (SAN/UCC) certificate.

Recap: Basic OpenSSL CSR Generation

First, let’s recall the basic command to generate a CSR and a new private key without SANs:

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

This command prompts you interactively for details like Country, State, Org, OU, and crucially, the Common Name (CN). The CN is the primary domain the certificate secures. However, this basic interactive mode doesn’t easily allow for adding SANs.

Why You Might Need SANs

You need SANs included in your certificate if:

• You want to secure both the www and non-www versions of your domain (e.g., www.yourdomain.com and yourdomain.com).
• You need to secure multiple specific subdomains (e.g., www.yourdomain.com, mail.yourdomain.com, shop.yourdomain.com).
• You need to secure completely different domain names under one certificate (e.g., yourdomain.com, anotherdomain.net).
• You are securing services like Microsoft Exchange that require specific hostnames (e.g., autodiscover.yourdomain.com).

Certificates that utilize the SAN field are often called Multi-Domain Certificates or UCC (Unified Communications Certificates).

The Misconception: “Add SAN to Certificate”

It’s essential to understand that digital certificates, once issued and signed by a CA, are tamper-proof and immutable. Their cryptographic signature guarantees their contents haven’t changed. Therefore, you cannot take an existing, issued certificate and simply “add” more SANs to it.

To include additional hostnames, you must obtain a new certificate that lists all required names (the original ones plus the new ones) in the SAN field. This involves generating a new CSR that specifies these names.

How to OpenSSL Generate CSR with SANs

To include SANs using OpenSSL’s req command, you typically need a configuration file (often ending in .cnf). This file tells OpenSSL how to structure the request and what extensions (like subjectAltName) to include.

Step 1: Create a Configuration File (e.g., req.cnf)

Create a text file (let’s call it req.cnf) with content similar to this, customizing the values for your needs:

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = v3_req
prompt             = no # Set to 'yes' if you want to be prompted for DN values

[ req_distinguished_name ]
C            = US                 # Country Code
ST           = California         # State
L            = Los Angeles        # Locality/City
O            = My Company Ltd     # Organization Name
OU           = IT Department      # Organizational Unit
CN           = www.yourdomain.com # Common Name (Primary Domain)

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[ alt_names ]
# List all domains and subdomains here
DNS.1 = www.yourdomain.com   # Must include CN as a SAN
DNS.2 = yourdomain.com
DNS.3 = mail.yourdomain.com
DNS.4 = dev.yourdomain.com
DNS.5 = anotherdomain.net    # Example of a different domain

Explanation of Key Sections:

• [ req ]: Basic settings. prompt = no uses the values directly from the file; prompt = yes would ask you interactively (but you still need the config for SANs).
• [ req_distinguished_name ]: Defines the Subject fields (CN, O, L, etc.). Customize these.
• req_extensions = v3_req: Tells OpenSSL to add extensions defined in the [v3_req] section.
• [ v3_req ]: Defines request extensions. subjectAltName = @alt_names is the crucial line linking to the SAN list.
• [ alt_names ]: This is where you list all hostnames. Use DNS.1, DNS.2, etc., for each name. It’s best practice to include the Common Name (CN) as the first SAN entry.

Step 2: Run the OpenSSL Command with the Config File

Now, run the openssl req command, telling it to use your configuration file:

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain_san.key -out yourdomain_san.csr -config req.cnf

• -keyout yourdomain_san.key: Saves the new private key. Secure this file.
• -out yourdomain_san.csr: Saves the new CSR file containing the SAN information.
• -config req.cnf: Tells OpenSSL to use the settings from your req.cnf file.

This command will generate yourdomain_san.key (private key) and yourdomain_san.csr (your CSR file, now including the specified SANs).

Step 3: Verify Your CSR with SANs

Before submitting this new CSR, use a CSR Reader/Decoder tool (available on sites like sslrepo.com) that explicitly shows Subject Alternative Names.

1. Copy the entire content of yourdomain_san.csr (including BEGIN/END lines).
2. Paste it into the CSR Decoder.
3. Verify that the Common Name is correct AND that all the DNS names listed under [alt_names] in your config file appear correctly in the decoded SAN field.

Step 4: Obtain and Install Your SAN Certificate

1. Submit CSR: Use the verified CSR text when ordering a Multi-Domain (SAN/UCC) certificate from your provider (e.g., sslrepo.com). Ensure you select a product that supports the number of SANs you included.
2. Validation: The CA will validate your control over the Common Name and all the domains listed in the SAN field.
3. Installation: Once issued, perform the ssl certificate installation on your server using the new certificate files and the corresponding private key (yourdomain_san.key). The installation process depends on your server software (Apache, Nginx, IIS, etc.).

Conclusion

While you can’t simply add san to certificate after issuance, using OpenSSL Generate CSR with a carefully crafted configuration file allows you to create a request that includes all necessary Subject Alternative Names from the beginning. This is the correct procedure for obtaining a single SSL/TLS certificate that secures multiple hostnames. Always remember to verify your CSR using a decoder that shows SANs before ordering your Multi-Domain certificate from a trusted provider like sslrepo.com, and always keep your private key secure.

Need to secure multiple domains with one certificate? Generate your CSR with SANs and explore our Multi-Domain SSL options at sslrepo.com.

Frequently Asked Questions (FAQ)

Q1: Why can’t I just add a name to my existing SSL certificate?
A: SSL certificates are cryptographically signed by the Certificate Authority. Modifying any part of the certificate after issuance, including adding SANs, would invalidate this signature, rendering the certificate untrusted.

Q2: Do I need a special type of certificate if I use SANs?
A: Yes, you need to order a certificate type specifically designed to support multiple domains, usually called a Multi-Domain (SAN) certificate or sometimes a UCC certificate.

Q3: Is using a configuration file (.cnf) the only way to add SANs with OpenSSL req?
A: It’s the most common and reliable method for the req command. While there might be complex command-line argument ways depending on the OpenSSL version, using a config file is standard practice for clarity and managing multiple SANs effectively.

Q4: Should I list my Common Name (CN) also as a SAN in the config file?
A: Yes, it is considered best practice to list the Common Name as the first entry in the [alt_names] section (e.g., DNS.1 = www.yourdomain.com) in addition to setting it in the [req_distinguished_name] section. This ensures maximum compatibility.

Q5: How do I verify if my generated CSR actually includes the SANs?
A: Use an online CSR Decoder tool that explicitly lists the Subject Alternative Names found within the CSR. Don’t rely on decoders that only show the basic Subject fields.

Q6: What if I need to add another domain later after getting my SAN certificate?
A: You would need to repeat the process: generate a new CSR using OpenSSL and a config file that includes the original hostnames plus the new one(s), and then request a reissue (if possible/allowed by your provider) or purchase a new SAN certificate based on this latest CSR.