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)
obsoleted by
- rfc-9525 — Service Identity in TLS
Extracted elements (28)
Each reference identifier SHOULD be based on the source domain rather than a derived domain because only a match between user-provided inputs and a presented identifier ensures the certificate legitimately secures the communication; derived domains from DNS SRV resolution could be subverted by a network attacker.
IP addresses are explicitly out of scope as service identifiers because they are unreliable (NAT, mobility, multiple interfaces, private internets, host grouping behind single IPs), constitute less than 1% of issued certificates, and are much harder for users to work with than DNS domain names.
The document recommends against multiple CN-IDs (SHOULD NOT rather than MUST NOT) because at least one major technology community (CA/Browser Forum EV-CERTS) and at least one major CA explicitly allow them, and many service providers require them in virtual hosting environments due to lack of TLS SNI support in some widely deployed operating systems.
The document recommends moving away from CN-ID and toward subjectAltName entries (DNS-ID, SRV-ID, URI-ID) because Common Name is not strongly typed — it might contain a human-friendly string rather than a DNS domain name — and because subjectAltName was specifically designed for machine-parseable service identity.
CN-ID support is expected to remain necessary for the foreseeable future because certificates containing CN-IDs are so widely deployed; implementers should monitor the state of certificate issuance policies and migrate away from CN-ID support in the future if possible.
The TLS Server Name Indication (SNI) extension (RFC 4366) allows a client to indicate the desired DNS domain name during the TLS handshake, enabling the server to return the appropriate single-domain certificate. Before SNI, the workaround was to embed all domain names into a single certificate with multiple DNS-IDs, SRV-IDs, or URI-IDs.
This document does not supersede identity verification rules in existing application protocol specifications (such as those for HTTP, LDAP, SMTP, XMPP, NNTP, NETCONF, Syslog, SIP, SNMP, and GIST excerpted in Appendix B). Future specifications and updates to existing ones may reference this document if the relevant technology communities agree.
A client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client. CN-ID checking is only a last resort when no other identifier types are present.
Each reference identifier in the client's list SHOULD be based on the source domain and SHOULD NOT be based on a derived domain (e.g., a host name discovered via DNS SRV resolution), since only a match between user inputs and a presented identifier ensures the certificate legitimately secures the communication.
If a match is found, the client MUST use the matched reference identifier as the validated identity of the application service. If no match is found and no pinned certificate exists, the client MUST proceed to the fallback behavior described in Section 6.6.4.
If no match is found and the client is an interactive client, it SHOULD inform the user of the identity mismatch and automatically terminate the communication with a bad certificate error. If automated, it SHOULD terminate with a bad certificate error and log appropriately; it MAY allow disabling this behavior via configuration but MUST enable it by default.
If the service uses a technology whose specification stipulates SRV-ID usage, the certificate SHOULD include an SRV-ID. If the specification stipulates URI-ID usage, the certificate SHOULD include a URI-ID where the scheme SHALL be the protocol's scheme and the host SHALL be the fully qualified DNS domain name.
The client MUST construct a list of acceptable reference identifiers independently of the identifiers presented by the service. Extracted data MUST include only information that can be securely parsed from inputs or derived in a manner not subject to subversion by network attackers.
The client MUST match the DNS domain name portion of a reference identifier using case-insensitive ASCII comparison per RFC 4343. For internationalized domain names, U-labels MUST be converted to A-labels before comparison, and A-labels MUST be compared as case-insensitive ASCII.
Unless a reusing specification allows continued wildcard support, the DNS domain name portion of a presented identifier SHOULD NOT contain the wildcard character '*', whether as the complete left-most label (e.g., *.example.com) or as a fragment (e.g., *oo.example.com).
When checking SRV-ID or URI-ID identifiers, a client MUST check both the DNS domain name portion and the application service type portion. The service name in an SRV-ID MUST be matched case-insensitively; the scheme name in a URI-ID MUST also be matched case-insensitively.
When issuing certificates, a certification authority SHOULD include a DNS-ID as a baseline for interoperability. The certificate SHOULD NOT include a CN-ID unless the issuing specification explicitly encourages continued CN-ID support for a given application technology.
When matching wildcard certificates, a client SHOULD NOT match a wildcard that comprises a label other than the left-most label. A wildcard as the entire left-most label (e.g., *.example.com) SHOULD NOT match against anything but the left-most label of the reference identifier, so it matches foo.example.com but not bar.foo.example.com.
A 'reference identifier' is constructed by the client from a source domain and optionally an application service type, used for matching against presented identifiers in a server's certificate. A 'presented identifier' is one provided by the server within its PKIX certificate during TLS negotiation.
Certificate pinning is the act of establishing a cached name association between a service's certificate and a client's reference identifier despite no identifier match, accomplished by explicit human user acceptance. Once pinned, the client verifies future connections by matching against the pinned certificate rather than re-checking identifiers.
RFC 6125 defines four identifier types used in PKIX certificates for application service identity: CN-ID (Common Name in subject field matching a DNS domain name form), DNS-ID (subjectAltName dNSName entry), SRV-ID (subjectAltName otherName of type SRVName), and URI-ID (subjectAltName uniformResourceIdentifier with scheme and host components).
The SRV-ID identifier type is a subjectAltName entry of type otherName with name form SRVName (per RFC 4985). It encodes both an application service type (e.g., 'imaps') and a DNS domain name (e.g., 'example.net'), making it restricted to a single application service type. It can represent either a direct or indirect (DNS-SRV-derived) name.
The URI-ID identifier type is a subjectAltName entry of type uniformResourceIdentifier whose value must include both a URI scheme component and a host component matching the reg-name rule (thus limited to DNS domain names, not IP addresses or bare hostnames). It is both direct and restricted to the application service type associated with its scheme.
A client MUST NOT construct a reference identifier corresponding to RDNs other than those of type Common Name, and MUST NOT check for RDNs other than Common Name in presented identifiers, to prevent attacks based on matching non-CN RDN attributes.
Allowing internationalized domain names in certificates can lead to inclusion of visually similar ('confusable') characters, creating homograph attack opportunities. Implementations are strongly discouraged from including or checking wildcard characters embedded within A-labels or U-labels of internationalized domain names.
Pinned certificate associations MUST take account of both the certificate presented and the context in which it was accepted, including the chain of certificates to the trust anchor, the source domain, application service type, derived domain, port number, and other relevant information. Pinning should be exposed only to advanced users with extreme caution.
Wildcard certificates automatically vouch for any and all hostnames within their domain, posing the risk of vouching for rogue or buggy hosts. Specifications for existing application technologies are inconsistent about allowable wildcard character placement, which can lead to exploitable differences in identity-checking behavior among client implementations.
The identity verification process proceeds through four stages: (1) client constructs reference identifier list from source domain; (2) server presents PKIX certificate with identifiers; (3) client checks reference identifiers against presented identifiers; (4) outcome is Match Found (success), No Match/Pinned (success if pinned cert matches), or No Match/No Pin (fallback/failure).