Generating Self-Signed Certificates with SubjectAltName Using OpenSSL: Configuration and Implementation Guide

In modern network communications, SSL/TLS certificates are fundamental components ensuring data transmission security. Self-signed certificates, as solutions requiring no third-party certificate authority validation, are widely used in development testing and internal systems. However, many traditional methods generate certificates lacking SubjectAltName extensions, potentially causing compatibility issues with modern browsers and applications. This article delves into generating self-signed certificates with SubjectAltName using OpenSSL, combining configuration file modifications with command-line operations to achieve certificate generation compliant with RFC 5280 standards.

OpenSSL Configuration File Structure and Modifications

OpenSSL's certificate generation process relies on configuration files, typically located at /usr/lib/ssl/openssl.cnf or /etc/ssl/openssl.cnf. To add SubjectAltName extensions, first define an alternate names section in the configuration file. Add the following content anywhere in openssl.cnf:

[ alternate_names ]

DNS.1        = example.com
DNS.2        = www.example.com
DNS.3        = mail.example.com
DNS.4        = ftp.example.com

This section defines the list of domain names the certificate will include, with each DNS entry corresponding to an acceptable alternate name. This structured definition ensures the certificate supports multiple domains, meeting the multi-domain requirements of modern web applications.

v3_ca Extension Configuration and Key Usage

Next, modify the existing [ v3_ca ] section to reference the alternate names. Locate the [ v3_ca ] section in the configuration file and add the following line:

subjectAltName      = @alternate_names

This configuration associates the alternate names section with the certificate's v3 extensions. Additionally, adjust the key usage settings to align with standard server certificate requirements:

keyUsage = digitalSignature, keyEncipherment

digitalSignature indicates the certificate can be used for digital signature verification, while keyEncipherment permits key encryption operations. These two flags are typical configurations for server certificates, ensuring proper functionality during TLS handshakes.

Extension Copying Mechanism and CA Configuration

To ensure SubjectAltName extensions are correctly copied to the final certificate, modify relevant settings in the CA_default section. Locate the following lines:

# Extension copying option: use with caution.
# copy_extensions = copy

Uncomment and modify to:

# Extension copying option: use with caution.
copy_extensions = copy

This setting enables extension copying, preserving all defined extensions during the certificate signing process. This is a critical step in generating certificates with SubjectAltName, preventing the loss of extension information during conversion.

Certificate Generation and Verification Process

After completing configuration file modifications, generate the self-signed certificate via command line. First, generate an RSA private key:

openssl genrsa -out private.key 3072

This command generates a 3072-bit RSA private key stored in the private.key file. Next, generate the self-signed certificate:

openssl req -new -x509 -key private.key -sha256 -out certificate.pem -days 730

This command uses the modified configuration file to generate an X.509 certificate valid for 730 days. The -x509 parameter indicates a self-signed certificate, while -sha256 specifies the SHA-256 hash algorithm. During execution, prompts will request certificate subject information such as country, organization, and common name.

Certificate Content Parsing and Verification

After generating the certificate, verify its content using the following command:

openssl x509 -in certificate.pem -text -noout

The output displays detailed certificate information, including version, serial number, signature algorithm, and extension sections. Key verification points include:

• Version Identification: Should display Version: 3 (0x2), indicating an X.509v3 certificate.
• Basic Constraints: X509v3 Basic Constraints should include CA:FALSE, indicating this certificate cannot act as a certificate authority.
• Key Usage: X509v3 Key Usage should include Digital Signature, Key Encipherment.
• Subject Alternative Name: X509v3 Subject Alternative Name should list all DNS names defined in the configuration file.

The following example shows typical output for the certificate extensions section:

X509v3 extensions:
    X509v3 Subject Key Identifier:
        34:66:39:7C:EC:8B:70:80:9E:6F:95:89:DB:B5:B9:B8:D8:F8:AF:A4
    X509v3 Authority Key Identifier:
        keyid:34:66:39:7C:EC:8B:70:80:9E:6F:95:89:DB:B5:B9:B8:D8:F8:AF:A4
    X509v3 Basic Constraints: critical
        CA:FALSE
    X509v3 Key Usage:
        Digital Signature, Non Repudiation, Key Encipherment, Certificate Sign
    X509v3 Subject Alternative Name:
        DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com

Technical Points and Best Practices

When generating self-signed certificates, consider the following technical points:

1. Key Length: Use 3072-bit or longer RSA keys to ensure security, avoiding outdated 1024-bit keys.
2. Hash Algorithm: Prefer SHA-256 or higher versions, avoiding algorithms like MD5 or SHA-1 that have proven vulnerabilities.
3. Certificate Validity Period: Set reasonable validity periods based on usage scenarios—shorter for development environments, considering renewal cycles for production.
4. Extension Integrity: Ensure all necessary extensions are correctly configured, particularly SubjectAltName and key usage, to avoid compatibility issues.

The certificates generated through these steps not only include standard subject names but also support multiple domains via SubjectAltName extensions, meeting the needs of modern web applications. This method's advantage lies in complete control over the certificate generation process, eliminating reliance on external certificate authorities while ensuring compliance with current security standards and compatibility requirements.