Why SAN Matters: Modern SSL Certificate Requirements

Quick Navigation

Difficulty: 🟡 Intermediate
Estimated Time: 15-25 minutes
Prerequisites: Basic Linux command line knowledge, Understanding of SSL/TLS concepts, Access to OpenSSL tools

What You'll Learn

This tutorial covers essential SSL certificate concepts and tools:

• SAN Fundamentals - Understanding why Subject Alternative Names matter
• Configuration Files - Creating proper SAN configuration for OpenSSL
• Certificate Generation - Step-by-step CSR creation with SAN support
• Modern Compatibility - Ensuring your certificates work with current browsers

Prerequisites

• Basic Linux command line knowledge
• Understanding of SSL/TLS concepts
• Access to OpenSSL tools

Related Tutorials

• Docker Security Best Practices - Container security implementation
• OpenTelemetry Guide - Observability and monitoring

Introduction

Without SANs, modern browsers will reject your SSL certificates — even if your CN is perfect. SANs let you support multiple domain names, wildcard domains, and IP addresses. This tutorial will teach you how to create SSL certificates with Subject Alternative Names for modern browser compatibility.

Understanding SANs (Subject Alternative Names)

What is a SAN?

A Subject Alternative Name (SAN) is an extension to X.509 certificates that allows you to specify additional hostnames, IP addresses, or other identifiers beyond the Common Name (CN).

Why SANs Matter Today

Modern browsers and security policies have become stricter about SSL certificates:

• Chrome 58+: Rejects certificates without SANs
• Firefox 60+: Requires SANs for proper validation
• Safari 11+: Strict SAN checking
• Mobile browsers: Increasingly strict about SAN requirements

Common Name vs. Subject Alternative Name

Creating SAN Configuration Files

Step 1: Create the SAN Config File

Create a file named hostname-san.conf and insert the following content:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
C = FR
L = PARIS
O = yourcompany
CN = hostname

[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = hostname

Configuration Breakdown

• [req]: Main request section
• distinguished_name: Certificate subject information
• req_extensions: Enables v3 extensions (required for SANs)
• v3_req: Version 3 extension specifications
• subjectAltName: Points to the alt_names section
• [alt_names]: Defines the actual alternative names

Customization Options

Replace the placeholder values with your actual information:

[req_distinguished_name]
C = US                    # Country
ST = California           # State/Province
L = San Francisco         # City/Locality
O = Your Company Inc.     # Organization
OU = IT Department        # Organizational Unit
CN = example.com          # Common Name (legacy, but still used)

[alt_names]
DNS.1 = example.com       # Primary domain
DNS.2 = www.example.com   # Subdomain
DNS.3 = api.example.com   # API subdomain
IP.1 = 192.168.1.100     # IP address

Generating Certificates and CSRs

Step 2: Generate the Private Key and CSR

Now run this OpenSSL command:

sudo openssl req -out hostname.csr -newkey rsa:4096 -nodes -keyout hostname.key -config hostname-san.conf

What This Command Does

• -out hostname.csr: Outputs the Certificate Signing Request
• -newkey rsa:4096: Creates a new 4096-bit RSA private key
• -nodes: Skips encrypting the private key (omit for added security)
• -keyout hostname.key: Saves the private key to a file
• -config hostname-san.conf: Uses your custom SAN configuration

Security Considerations

Option 1: Unencrypted key (faster, less secure)

openssl req -out hostname.csr -newkey rsa:4096 -nodes -keyout hostname.key -config hostname-san.conf

Option 2: Encrypted key (slower, more secure)

openssl req -out hostname.csr -newkey rsa:4096 -keyout hostname.key -config hostname-san.conf

Example Output

After running the command, you should see:

Generating a 4096 bit RSA private key
..................................++++
writing new private key to 'hostname.key'

And your hostname.csr is now ready to send to a Certificate Authority (CA)!

Verifying and Testing

Verify Your CSR

Check CSR Contents

# View CSR details
openssl req -in hostname.csr -noout -text

# Verify SAN extension is present
openssl req -in hostname.csr -noout -text | grep -A 10 "Subject Alternative Name"

Expected SAN Output

You should see something like:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

Testing Your Certificate

Self-Signed Certificate for Testing

# Generate self-signed certificate
openssl x509 -req -in hostname.csr -signkey hostname.key -out hostname.crt -days 365

# Test with OpenSSL
openssl s_client -connect localhost:443 -servername example.com

Browser Testing

1. Install your certificate on your web server
2. Access via HTTPS in different browsers
3. Check browser security indicators (green lock, etc.)
4. Verify SAN validation in browser developer tools

Advanced Configurations

Multiple Domains

[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = api.example.com
DNS.4 = mail.example.com
DNS.5 = blog.example.com

Wildcard Certificates

[alt_names]
DNS.1 = example.com
DNS.2 = *.example.com

Note: Wildcard certificates only cover one level of subdomains.

Mixed Domains and IPs

[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
IP.1 = 192.168.1.100
IP.2 = 10.0.0.50

Internal/Private Domains

[alt_names]
DNS.1 = example.com
DNS.2 = internal.example.com
DNS.3 = dev.example.local
DNS.4 = staging.example.local

Troubleshooting Common Issues

Issue: "Certificate doesn't match the domain name"

Solution: Ensure the domain you're accessing is listed in the SAN section.

Issue: "Certificate has no SAN extension"

Solution: Verify your config file includes req_extensions = v3_req and subjectAltName = @alt_names.

Issue: "Private key doesn't match certificate"

Solution: Always use the same private key that was used to create the CSR.

Issue: "Wildcard doesn't work for sub-subdomains"

Solution: Wildcards only cover one level. Use *.sub.example.com for deeper subdomains.

Production Best Practices

Certificate Management

• Use strong key sizes: RSA 4096 or ECDSA P-384
• Implement key rotation: Regular private key updates
• Monitor expiration: Set up alerts for certificate renewal
• Backup securely: Store private keys in secure locations

Security Considerations

• Limit SAN entries: Only include necessary domains
• Avoid overly broad wildcards: Be specific about subdomain coverage
• Regular audits: Review certificate configurations periodically
• Compliance: Ensure certificates meet your organization's security policies

Docker Integration

Using SAN Certificates with Docker

version: '3.8'

services:
  nginx:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./hostname.crt:/etc/ssl/certs/hostname.crt:ro
      - ./hostname.key:/etc/ssl/private/hostname.key:ro
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

Nginx Configuration

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    
    ssl_certificate /etc/ssl/certs/hostname.crt;
    ssl_certificate_key /etc/ssl/private/hostname.key;
    
    # Additional SSL configuration...
}

Conclusion

You now know how to create SSL certificates with Subject Alternative Names for modern browser compatibility. You've learned to create SAN configurations, generate CSRs with OpenSSL, and implement best practices for production use.

Key Takeaways:

• SANs are essential for modern browser compatibility
• Proper OpenSSL configuration ensures SAN support
• Regular certificate management maintains security

Next Steps:

• Implement SAN certificates in your infrastructure
• Set up monitoring for certificate expiration
• Consider automated certificate renewal processes

Tags: #SSL #OpenSSL #SAN #DevOps #CloudSecurity #LinuxTips #Cybersecurity #ServerAdmin #HTTPS