Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension
Extracted elements (21)
By requiring a new ALPN protocol ID ("acme-tls/1") rather than relying solely on SNI, and by using the domain name itself (not a synthetic subdomain) in the SAN, the tls-alpn-01 challenge ensures service providers must opt in and deploy explicit code, enabling stronger access controls and eliminating the SNI hijack vector.
The tls-alpn-01 challenge was created to replace the TLS SNI challenge from early ACME drafts, which had a security vulnerability discovered by Frans Rosen: many service providers did not enforce that users could only respond to SNI requests for their own registered names, allowing a user to hijack validation for another user's domain by responding to the SNI challenge name (a synthetic subdomain) on shared infrastructure.
Because "acme-tls/1" does not build on a pre-existing deployment base, completing tls-alpn-01 challenges requires explicit changes by service providers; it is an opt-in process, unlike HTTP or DNS-based ACME validation.
ACME servers implementing "acme-tls/1" MUST only negotiate TLS 1.2 or higher when connecting to clients for validation.
The ACME server MUST initiate validation using TCP port 443, MUST provide an ALPN extension with only "acme-tls/1", and MUST provide an SNI extension containing only the domain name being validated.
The ACME server MUST verify that the "acme-tls/1" protocol was successfully negotiated (ALPN contained only this value) and that the certificate contains a subjectAltName with only the dNSName being validated and a critical acmeIdentifier extension with the expected SHA-256 digest.
The "acme-tls/1" protocol MUST only be used for validating ACME tls-alpn-01 challenges. Once the TLS handshake is completed, the client MUST NOT exchange any further data and MUST immediately close the connection.
The acmeIdentifier extension MUST contain the SHA-256 digest of the key authorization for the challenge, and MUST be marked critical so the certificate is not inadvertently used by non-ACME software.
The challenge token MUST have at least 128 bits of entropy and MUST NOT contain any characters outside the base64url alphabet. Trailing '=' padding characters MUST be stripped.
The comparison of dNSNames MUST be case insensitive per RFC 4343, and all dNSNames MUST be encoded using Punycode (RFC 3492) since ACME does not support Unicode identifiers.
The self-signed certificate prepared by the ACME client MUST contain an acmeIdentifier extension and a subjectAlternativeName extension. The subjectAlternativeName extension MUST contain a single dNSName entry equal to the domain being validated.
The validation certificate MUST be provisioned such that it is returned during a TLS handshake where the "acme-tls/1" ALPN protocol has been negotiated and an SNI extension containing the domain being validated has been provided.
The acme-tls/1 protocol consists solely of a TLS handshake transmitting the required validation information; it does not carry application data. It does not require a valid certificate signature nor a fully completed TLS handshake, though servers MAY withhold authorization if these fail.
The tls-alpn-01 challenge object requires two fields: 'type' (the string "tls-alpn-01") and 'token' (a random base64url-encoded value with at least 128 bits of entropy, with trailing '=' padding stripped).
A new OID id-pe-acmeIdentifier (decimal 31) is added to the SMI Security for PKIX Certificate Extension (1.3.6.1.5.5.7.1) registry to identify the acmeIdentifier X.509 extension.
The ALPN Protocol ID "acme-tls/1" (identification sequence 0x61 0x63 0x6d 0x65 0x2d 0x74 0x6c 0x73 0x2f 0x31) is added to the TLS ALPN Protocol IDs registry.
The validation method "tls-alpn-01" with identifier type "dns" is added to the ACME Validation Methods registry within the ACME Protocol registry.
Hosting providers, CDNs, and service providers SHOULD NOT allow users to supply their own certificates for TLS ALPN validation. Providers wishing to implement tls-alpn-01 SHOULD generate validation certificates themselves and not expose this to users.
The challenge assumes that HTTPS servers hosting multiple domain names from a single IP properly segregate SNI-based control between users. If a server allows User B to serve TLS for a name registered by User A, User B can illegitimately prove domain control to the ACME server.
The challenge relies on the assumption that a server will not violate RFC 7301 by blindly agreeing to use "acme-tls/1" without actually understanding it, which would allow unauthorized parties to complete the validation handshake.
The acmeIdentifier extension uses OID id-pe-acmeIdentifier (id-pe 31) and has ASN.1 type Authorization ::= OCTET STRING (SIZE (32)), encoded as ASN.1 DER. The 32-byte value is the SHA-256 digest of the key authorization.