Last updated on February 21, 2022
Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS)
Likewise, during TLS
negotiation, the server presents its notion of the service’s identity
in the form of a public-key certificate that was issued by a
certification authority (CA) in the context of the Internet Public
Key Infrastructure using X.509 [PKIX].
Informally, we can think of
these identities as the client’s “reference identity” and the
server’s “presented identity”
RFC 6125 – Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (ietf.org)
Application service clients typically establish TLS connections to application servers identified by DNS domain names. The process of obtaining this “source” domain is application specific [RFC6125].
The name could be entered by a user or found through an automated discovery process such as an SRV or NAPTR record. After obtaining the address of the server via an A or AAAA DNS record, the client conducts a TLS handshake with the server, during which the server presents a PKIX certificate [RFC5280].
The TLS layer performs PKIX validation of the certificate, including verification that the certificate chains to one of the client’s trust anchors.
If this validation is successful, then the application layer determines whether the DNS name for the application service presented in the certificate matches the source domain name [RFC6125]. Typically, if the name matches, then the client proceeds with the TLS connection.
The certificate authorities (CAs) that issue PKIX certificates are asserting bindings between domain names and the public keys they certify.
Application service clients are verifying these bindings and making authorization decisions — whether to proceed with connections — based on them.
When peer verification is enabled, it is common for clients to also check whether the hostname of the server they are connecting to matches one of two fields in the server certificate:
- the SAN (Subject Alternative Name) or
- CN (Common Name).
- When wildcard certificates are used, the hostname is matched against a pattern. If there is no match, peer verification will also be failed by the client.
- Hostname checks are also optional and generally orthogonal to certificate chain verification performed by the client.
Because of this it is important to know what SAN (Subject Alternative Name) or CN (Common Name) values were used when generating the certificate.
If a certificate is generated on one host and used on a different host then the $(hostname) value should be replaced with the correct hostname of the target server.
Information below ref SNI..