Analysis of the Collaborative Mechanism Between Common Name and Subject Alternative Name in SSL Certificates

Core Principles of SSL Certificate Verification Mechanism

Domain name verification in SSL/TLS certificates forms the foundation of secure connection establishment. Within the certificate structure, Common Name (CN) and Subject Alternative Name (SAN) are two critical domain identification fields. According to RFC 5280 standards, certificate subject names may appear in the subject field and/or the subject alternative name extension, meaning the verification process must check both locations.

From an implementation perspective, domain verification follows a specific checking order: first verify all domain names in the SAN extension, passing verification if a match is found; if SAN doesn't exist or no match occurs, continue checking the CN field. This design ensures backward compatibility while supporting more flexible domain management.

Analysis of Specific CN and SAN Configuration Scenarios

Consider a typical scenario: a certificate's SAN extension contains two DNS names domain.example and host.domain.example, while the CN field is set only to CN=domain.example. This configuration has clear implications and impacts in practical applications.

From a technical perspective, when a client requests host.domain.example, the verification process first checks the SAN extension. Since this domain exists in SAN, verification succeeds immediately without further CN checking. This mechanism ensures that even when CN doesn't contain all domains, the certificate can still provide valid verification for all domains listed in SAN.

Compared to configuring multiple CN certificates, the single-CN multiple-SAN configuration offers significant advantages: supporting multiple domains requires only a single IP address, simplifying server configuration and management. The traditional approach requires separate IP addresses for each CN, increasing infrastructure complexity and cost.

Specific Implementation in OpenSSL 0.9.8b+

OpenSSL 0.9.8b+, as a widely used cryptographic library, implements certificate verification following RFC standards but with specific historical considerations. In this version, verification logic still checks both CN and SAN fields, differing from newer RFC 6125 recommendations.

In specific implementation, OpenSSL 0.9.8b+ will:

1. Parse the certificate's SAN extension, checking if the requested domain matches
2. If SAN matching fails or doesn't exist, check the CN field
3. Consider verification successful if either match succeeds

This implementation ensures compatibility with older certificates but may not align with the latest security best practices. Developers should note that newer OpenSSL versions may have updated verification logic to prioritize RFC 6125 recommendations.

Historical Evolution and Best Practice Recommendations

The CN field was originally used to store server domain names, a historical design from the Netscape era. With internet development, the SAN extension was introduced to support multi-domain certificates, gradually becoming a more appropriate location for domain storage.

According to the latest RFC 6125 recommendations, when the SAN extension exists, validators should check only SAN and ignore CN. This change reflects the evolution of security practices, but compatibility factors must still be considered in actual deployments. Many certificate authorities still include the primary domain in CN and additional domains in SAN.

Based on the above analysis, we propose the following best practice recommendations:

• Place all domains requiring verification in the SAN extension
• Duplicate the primary domain in CN to ensure backward compatibility
• Avoid relying on CN as the primary domain verification mechanism
• Regularly update cryptographic libraries to ensure compliance with the latest security standards

In actual deployments, developers should carefully test certificate verification behavior, particularly in environments mixing old and new systems and libraries. Understanding the collaborative mechanism between CN and SAN helps build more secure and flexible SSL/TLS infrastructure.