SSL Certificate Server Name Resolution and Subject Alternative Names Configuration

SSL Certificate Server Name Resolution Mechanism

Server name verification in SSL/TLS protocols is a critical component for establishing secure connections. According to RFC 6125 (General Server Identity Verification Specification) and its predecessor RFC 2818 (HTTPS-specific specification), hostname verification follows explicit priority rules. When a certificate contains Subject Alternative Names (SAN) extensions, the system must prioritize matching against the dNSName (domain name) or iPAddress (IP address) entries in the SAN. Only when SAN extensions are absent does the system fall back to using the Common Name (CN) field.

Differences Between Browser and Java Implementations

Browsers typically exhibit greater flexibility in certificate validation. Many browser implementations check both the CN field and SAN extensions, and may even ignore missing SANs when the CN field contains a valid hostname. This lenient approach stems from historical compatibility considerations and the ambiguous definition of "most specific Common Name" in RFC 2818.

In contrast, Java's security implementation adheres more strictly to the specifications. Starting from Java 7, the sun.security.util.HostnameChecker class explicitly requires: when connecting using a hostname, the certificate must contain a matching dNSName SAN; when connecting using an IP address, the certificate must contain a matching iPAddress SAN. If the corresponding SAN extension is missing, validation fails and throws java.security.cert.CertificateException: No subject alternative names present, even if the CN field contains the correct hostname or IP address.

Adding Subject Alternative Names Using keytool

Starting from Java 7, the keytool utility supports adding SAN extensions directly via the -ext option. Below are specific usage examples:

# Add SAN extension for domain names
keytool -genkeypair -alias myserver -keyalg RSA -keysize 2048 \
  -keystore keystore.jks -validity 365 \
  -ext san=dns:www.example.com,dns:example.com

# Add SAN extension for IP addresses
keytool -genkeypair -alias myserver -keyalg RSA -keysize 2048 \
  -keystore keystore.jks -validity 365 \
  -ext san=ip:192.168.1.100,ip:10.0.0.1

# Mix domain names and IP addresses
keytool -genkeypair -alias myserver -keyalg RSA -keysize 2048 \
  -keystore keystore.jks -validity 365 \
  -ext "san=dns:server.example.com,ip:192.168.1.100"

Note that the value of the -ext option must be enclosed in quotes, especially when containing multiple SAN entries or spaces. The generated certificate can be verified for SAN extensions using:

keytool -list -v -alias myserver -keystore keystore.jks

Configuring SAN Extensions Using OpenSSL

For more complex certificate requirements or integration with systems outside the Java ecosystem, OpenSSL offers more flexible SAN configuration options. SAN extensions can be specified by modifying the openssl.cnf configuration file or using environment variables.

Method 1: Adding SAN via configuration file

# Add the following configuration to openssl.cnf
[req]
req_extensions = v3_req

[v3_req]
subjectAltName = @alt_names

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

Then generate the certificate signing request using the configuration:

openssl req -new -key server.key -out server.csr -config openssl.cnf

Method 2: Dynamically specifying via environment variables (suitable for temporary testing)

export OPENSSL_CONF=/dev/null
cat > /tmp/openssl.cnf <<EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_ren

[req_distinguished_name]
countryName = Country Name (2 letter code)

[v3_req]
subjectAltName=DNS:test.example.com,IP:192.168.1.100
EOF

openssl req -new -key server.key -out server.csr -config /tmp/openssl.cnf

Practical Application Scenarios and Best Practices

In enterprise internal deployments, proper SAN configuration is crucial when using self-signed certificates to connect to multiple servers. Below is a typical configuration scheme for multi-server HTTPS communication:

1. Unified Certificate Management: Generate a SAN certificate for the main server containing addresses of all target servers
2. IP Address Handling: Ensure certificates contain corresponding iPAddress SAN entries when connecting directly via IP addresses
3. Trust Store Configuration: Import self-signed certificates into Java's cacerts truststore or application-specific truststores
4. Verification Testing: Test connections using Java's SSLSocket or HttpsURLConnection, avoiding reliance on browser leniency

For scenarios requiring coverage of numerous servers, consider using wildcard certificates (e.g., *.example.com) or deploying private PKI infrastructure. However, wildcards do not apply to IP addresses, which must be explicitly listed for all required IPs.

Troubleshooting and Common Issues

When encountering Java certificate validation failures, follow these diagnostic steps:

1. Use keytool -list -v or openssl x509 -text to check if certificates contain correct SAN extensions
2. Verify that the address used for connection (hostname or IP) exactly matches SAN entries in the certificate
3. Ensure certificates are properly imported into Java truststores
4. Avoid using custom HostnameVerifier to bypass validation unless security risks are fully understood

Particularly important is that RFC specifications explicitly discourage using IP addresses in the CN field. While some legacy systems may support this practice, modern Java implementations strictly reject such certificates to ensure compliance with current security standards.