Location>code7788 >text

OpenSSL certificates extend the domain names supported by the certificate with the Subject Alternative Name extension field.

Popularity：967 ℃/2024-09-19 11:36:07

In the early days of the Internet, each SSL/TLS certificates typically contain only a CN field to identify a single domain name or IP address. As web hosting technology evolves and the need for simplified management by organizations increases, there is a need for a mechanism that allows a single certificate to effectively represent multiple domain names or services. For example, an organization may have multiple sub-domains and wish to protect them with a single certificate.

To address this issue, SAN extensions were introduced into the X.509 certificate standard. Originally introduced in RFC 2459 in 1999, SAN provides a way to specify additional subject names, thus allowing a single certificate to effectively represent multiple entities.

1.3 Role and importance of SANs

  1. Multi-Domain Protection: SAN makes it possible to protect multiple domains and sub-domains with a single certificate, reducing administrative complexity and cost.
  2. Increased flexibility: Businesses and organizations can manage and deploy certificates more flexibly, quickly adjusting and extending protection as needed.
  3. Compatibility: As technology has evolved, modern browsers and client software have come to support SANs. they prioritize checking SAN fields, and if a match is found, they usually don't fall back to checking the CN.

1.4 How to use SAN

When requesting an SSL/TLS certificate, you can specify one or more SAN values. These values are typically the domain name or IP address that you want the certificate to protect. The Certificate Authority (CA) verifies that this information is correct when issuing the certificate and includes it in the SAN field of the certificate.

2, how to add SAN in OpenSSL certificate

Adding a SAN when creating a certificate in OpenSSL requires adding a configuration file to thesubjectAltNameExtension. This usually involves the following steps:

  1. Prepare the configuration file: Specify in the configuration filesubjectAltNameextension and list the domain names and IP addresses to include.
  2. Generate key: Use OpenSSL to generate a private key.
  3. Generate Certificate Issuance Request (CSR): generates a CSR using the private key and configuration file, which will contain SAN information.
  4. Issuing a certificate: Use a CA (Certificate Authority) or self-signed method to issue a certificate, which will contain SAN information.

2.1 Preparing a Certificate Request Profile with SAN Extensions

  • Create a configuration file for Certificate Signing Requests (CSRs) with SAN extension fields. the configuration segment for alt_names is configured for SAN extension fields. Ensure that you are saving it to a file (for example).

[ req ]  
default_bits = 2048  
prompt = no  
default_md = sha256  
req_extensions = v3_ext  
distinguished_name = dn  
  
[ dn ]  
C = CN  
ST = ShangDong
L = SZ  
O = Wise2c  
OU = Wise2c  
CN = zmc  
  
[ req_ext ]  
subjectAltName = @alt_names  
  
[ alt_names ]  
DNS.1 = *.  
DNS.2 = *.  
DNS.3 = *.  
DNS.4 = *.  
  
[ v3_ext ]  
basicConstraints=CA:FALSE  
keyUsage=keyEncipherment,dataEncipherment  
extendedKeyUsage=serverAuth,clientAuth  
subjectAltName=@alt_names

2.2 Generating Keys

  • Generate a key with 2048 bits

openssl genrsa -out  2048

  • Generated based on (use the -days parameter to set the certificate validity time):

openssl req -x509 -new -nodes -key  -subj "/CN=zmc" -days 10000 -out

  • Generate a key with 2048 bits

openssl genrsa -out  2048

2.3 Generating a certificate issuance request

  • Generate a certificate signing request based on a configuration file

openssl req -new -key  -out  -config

 

2.4 Issuance of certificates

  • Generate server certificates using , and

openssl x509 -req -in  -CA  -CAkey  \-CAcreateserial -out  -days 10000 \-extensions v3_ext -extfile

  • Viewing the certificate, you can see that the certificate with the SAN extension field is created

openssl x509  -noout -text -in ./

3、Client side to verify the server-side certificate steps

The process of verifying server-side certificates when a client (generally a browser) requests an HTTPS website is indeed a complex and critical security step. The following is an example of the steps for a browser to validate a server-side certificate:

  1. Initiates an HTTPS request:
    • The user enters the URL of the HTTPS site through the browser and presses the Enter key or clicks on the link, and the browser begins to initiate the HTTPS request.
  2. The server responds and sends the certificate:
    • Upon receiving an HTTPS request, the server sends its SSL/TLS certificate to the browser. This certificate contains the server's public key, information about the certificate authority (CA), the certificate's expiration date, and the SAN (Subject Alternate Name) and CN (Common Name) fields that may be included.
  3. Browser Validation Certificate Authority (CA):
    • The browser checks to see if the certificate was issued by a trusted CA. The browser has a built-in list of trusted CAs (also known as the root certificate list), and it uses the public keys of these CAs to verify the validity of the certificate signatures at each level of the certificate chain until it finds a trusted root certificate.
  4. Check the validity of the certificate:
    • The browser verifies the validity of the certificate to ensure that the current time is within the validity period of the certificate.
  5. Validating certificate domains：
    • The browser checks the SAN field (if present) and CN field in the certificate to make sure they match the domain name the user is accessing. If the domain name does not match, the browser will assume the certificate is invalid and display a warning message.
  6. Check certificate revocation status (optional):
    • The browser may check to see if the certificate has been revoked via OCSP (Online Certificate Status Protocol) or CRL (Certificate Revocation List). This step is optional, but helps to detect and block the use of certificates with compromised private keys in a timely manner.
  7. Generate the session key (part of the TLS handshake process):
    • If the certificate validation passes, the browser and server will perform a TLS handshake to negotiate a secure session key. This key will be used for encryption and decryption of subsequent communications.
  8. Encrypted communication:
    • Once the session key has been negotiated, the browser and server can begin encrypted communication. The browser encrypts the data sent to the server using the session key, and the server decrypts that data using the same session key.

caveat

  • If the browser finds any problems in verifying the certificate (e.g., the certificate is untrusted, has expired, domain name does not match, etc.), it will display a warning message to the user and may prevent the user from continuing to access the site.
  • The SAN field is usually prioritized over the CN field. If both the SAN and CN fields are included in the certificate and the domain names between them do not match, the browser will prioritize the domain name in the SAN field for validation.
  • The browser's built-in list of trusted CAs may be updated over time to reflect new CAs or to revoke old ones; therefore, users should keep their browsers and operating systems up to date to ensure that they recognize the latest trusted CAs.

The above steps describe in detail the process by which the browser verifies the server's certificate when requesting an HTTPS website. This process ensures that the communication between the user and the server is secure and trustworthy.

4, example - Kubectl client access KubeApiserver

4.1 Environment

KubeApiserver address: 10.20.32.205:6443

KubeApiserver certificate information:

[root@member-cluster2-master1 pki]# pwd
/etc/kubernetes/pki
[root@member-cluster2-master1 pki]# ls
          
          
[root@member-cluster2-master1 pki]# openssl x509  -noout -text -in ./ 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 495742113187184862 (0x6e13ad34cb940de)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = kubernetes
        Validity
            Not Before: Sep 11 01:13:49 2024 GMT
            Not After : Aug 18 01:16:09 2124 GMT
        Subject: CN = kube-apiserver
       .......

            X509v3 Subject Alternative Name: 
                DNS:kubernetes, DNS:, DNS:, DNS:, DNS:, DNS:localhost, DNS:member-cluster2-master1, DNS:, IP Address:10.234.0.1, IP Address:10.20.32.205, IP Address:127.0.0.1
    Signature Algorithm: sha256WithRSAEncryption
       .......

4.2 Kubectl normal access to KubeApiserver (certificate SAN extension field value contains access address)

  • Access via KubeApiserver ip address

  • Accessed via domain host mapping, the domain is inside the SAN

4.3 Kubectl exception access to KubeApiserver (certificate SAN extension field value does not contain access address)

  • Accessed via domain host mapping, the domain name is not inside the SAN, and the client fails to validate the certificate.

5. Other - whether the KubeApiserver certificate SAN extension field should list the entire cluster IPs

When I first approached Kubernetes and installed a cluster, I went through a lot of blogs on the Internet, and in the session of generating KubeApiserver certificates, it was written that the ip addresses of the entire cluster to be installed should be written into the SAN Extension field of the KubeApiserver certificate request file, and it didn't say anything about the reason for that.

As to whether the entire cluster's ip address should be written inside the SAN extension field of the KubeApiserver certificate request file during the KubeApiserver certificate generation session or if it depends on how the components inside the cluster are accessing KubeApiserver. if:

  • The scheduler (kube-scheduler), and controller (kube-controller-manage) all interact directly with the kube-apiserver component of the current node;
  • kubelet, kubectl, kube-proxy to kube-apiserver component via VIP proxy.

For this case, the SAN extension field can just write VIPs (responsible for equalizer IPs, etc.) and MasterIPs, and there is no need to write the WorkerIP into the SAN extension field.

6. Conclusion

Subject Alternative Name is a certificate extension field that specifies a list of hostnames to which the certificate applies. When a client connects to a server, the subject alias in the certificate returned by the server is checked to see if it contains an entry that matches the requested hostname.

The introduction of SANs has greatly enhanced the functionality and range of applications for digital certificates, making it much more efficient and easy to manage and secure multi-domain environments. As a key component of modern network security, understanding and properly using SANs is critical for any individual or organization that needs to deploy SSL/TLS protection. As network environments continue to evolve and new requirements emerge, SANs will continue to play an important role in securing network communications. Both IT professionals and casual users should understand the basic concepts and practices of SANs to ensure secure communications and interactions in the digital world.

<Previous Next>