Return to Security-Related RFCs, Network Security, Container Security - Kubernetes Security, Cloud Security, Web Security, DevSecOps

See: 6125 on datatracker.ietf.org

RFC 6125 defines guidelines for server identity verification when using certificates in TLS (Transport Layer Security) and similar security protocols. The primary focus of RFC 6125 is on verifying the identity of a server based on its domain name, ensuring that clients can confirm they are communicating with the correct server during the establishment of a secure connection. The document provides a detailed set of rules for how this verification should be performed, helping to mitigate the risks of man-in-the-middle attacks and other security vulnerabilities associated with incorrect server identity validation.

RFC 6125 was developed to address inconsistencies and gaps in the previous practices for verifying server identities in various TLS-based protocols. Historically, different applications and protocols implemented their own ad hoc methods for verifying server identities, leading to a fragmented and sometimes insecure landscape. By standardizing these practices, RFC 6125 aims to provide a unified approach that improves both security and interoperability across different systems.

The core of RFC 6125 revolves around how clients should handle the identity information provided in X.509 certificates. In particular, the document specifies how clients should match the server's identity, as presented in its certificate, to the expected identity of the server they are trying to reach. This typically involves comparing the domain name presented in the certificate with the domain name requested by the client, ensuring that they match according to the rules laid out in the RFC.

One of the key concepts introduced in RFC 6125 is the distinction between “DNS-IDs” and “Common Names” (CN-IDs) within certificates. Historically, the Common Name field was used to represent the domain name of the server. However, RFC 6125 deprecates this practice in favor of the Subject Alternative Name (SAN) extension, where DNS-IDs are specified. The use of DNS-IDs in the SAN extension provides a more flexible and robust way of representing domain names, and it is now considered the preferred method for indicating the server’s identity.

RFC 6125 outlines several rules for matching domain names in certificates. These rules include exact matching, wildcard matching (e.g., “

• .example.com”), and handling of internationalized domain names (IDNs). The document emphasizes the importance of performing these matches carefully and correctly, as any mistakes could lead to successful man-in-the-middle attacks or other forms of exploitation. Wildcard matching, in particular, introduces potential security risks if not properly implemented, and RFC 6125 provides guidance on the appropriate use of wildcards in certificates.

Another important aspect of RFC 6125 is its guidance on handling certificates in environments where multiple services or hosts share the same TLS infrastructure. In such cases, it is common to use Subject Alternative Names to specify multiple DNS-IDs in a single certificate, allowing the certificate to be used for multiple domain names. This is especially important in cloud environments and multi-tenant hosting scenarios, where a single server may serve many different customers or services.

The RFC also discusses how clients should handle certificates that include both DNS-IDs and CN-IDs. While RFC 6125 strongly encourages the use of DNS-IDs over CN-IDs, it recognizes that many legacy systems still rely on the Common Name field for identity verification. As a result, the document provides guidance for clients to transition to using DNS-IDs, while still maintaining compatibility with older certificates that use CN-IDs.

RFC 6125 places a strong emphasis on security considerations, particularly the need to prevent attackers from exploiting weaknesses in the identity verification process. For example, the document advises against trusting wildcard certificates for top-level domains (e.g., “

• .com”), as this could allow attackers to impersonate any domain under the top-level domain. It also emphasizes the importance of validating all identity-related fields in a certificate, rather than relying solely on the presence of a valid digital signature.

The document acknowledges that RFC 6125 is not a comprehensive solution for all identity verification problems. In particular, it focuses primarily on verifying server identities based on domain names, and does not cover other types of identifiers that may be used in certificates, such as IP addresses or email addresses. However, the guidance provided in RFC 6125 forms a critical part of the overall security framework for TLS and other secure communication protocols.

RFC 6125 also discusses how clients should handle situations where the identity presented in the certificate does not match the expected identity of the server. In these cases, the client should terminate the connection and present an error to the user, indicating that the server's identity could not be verified. This behavior is essential for maintaining the security of TLS connections, as proceeding with a connection to an unverified server could expose the client to significant security risks.

In conclusion, RFC 6125 provides essential guidelines for verifying server identities based on domain names in TLS and similar protocols. By standardizing the process of matching server identities to the information provided in X.509 certificates, the document helps improve the security and reliability of secure communication systems. The shift from relying on Common Names to using DNS-IDs in the SAN extension is a key part of this effort, ensuring that identity verification is both more secure and more consistent across different systems. The rules for matching domain names, handling wildcards, and managing certificates in shared environments are all critical components of this standard. The full text of RFC 6125 is available on the IETF website at https://datatracker.ietf.org/doc/html/rfc6125.