Automated Certificate Management Environment (ACME) for Subdomains
Extracted elements (20)
ACME does not mandate that the identifier in a newOrder request matches the identifier in authorization objects. This existing flexibility in RFC 8555 is the foundation that allows subdomain certificate issuance via ancestor domain authorization without protocol changes to the core order/authorization relationship.
The document clarifies the RFC 8499 subdomain definition as ambiguous because it appears to allow a domain to be a subdomain of itself. This document explicitly interprets it as requiring a 'different domain', so mmm.example.com is not a subdomain of mmm.example.com.
The pre-authorization flow enables a client to authorize an ancestor domain once and then issue multiple newOrder requests for certificates across many subdomains without repeating DNS challenges, significantly reducing operational overhead for large subdomain deployments.
Server newOrder handling for subdomain requests generally follows RFC 8555 Section 7.4. When the server allows subdomain authorizations for the ancestorDomain, it creates an authorization object against that ancestor domain and includes subdomainAuthAllowed=true.
This document is only relevant for the 'dns' identifier type as defined in RFC 8555. It does not apply to other identifier types such as the 'ip' identifier type defined in RFC 8738.
If server policy does not allow subdomain authorization for an ancestor domain specified in a newOrder request, the server SHOULD NOT include the subdomainAuthAllowed flag in the authorization object for the indicated identifier.
If the ACME server supports authorization of subdomains and policy allows wildcard identifier issuance under that authorization object, the server SHOULD include the wildcard field with a value of true per RFC 8555 Section 7.1.4.
If the subdomainAuthAllowed field is present in an authorization object, it MUST be true for authorizations where ACME server policy allows certificates to be issued for any subdomain subordinate to the domain specified in the identifier field.
When a client includes the ancestorDomain field in a newOrder identifier, the client MUST be able to fulfill a challenge against the ancestor domain specified in that field.
The ancestorDomain field is a new optional string field for the identifier object in newOrder requests. It specifies an ancestor domain of the requested identifier that the client has DNS control over and is capable of fulfilling challenges against.
The subdomainAuthAllowed field is a new optional boolean field added to the ACME authorization object. When true, it indicates that ACME server policy allows certificates to be issued for any subdomain subordinate to the domain specified in the identifier field. If not present, the assumed default value is false.
The subdomainAuthAllowed field is also defined for the identifier object in newAuthz requests. A client sets this flag to indicate to the server that it is requesting an authorization for the subdomains subordinate to the specified domain identifier value.
The subdomainAuthAllowed field is defined as a new ACME directory metadata field (optional boolean). An ACME server can advertise support for subdomain authorization by including this flag with value true in its directory metadata. If not specified, the assumed default is false.
The subdomainAuthAllowed boolean field has been added to the IANA 'ACME Directory Metadata Fields' registry defined in RFC 8555, with reference to RFC 9444.
The subdomainAuthAllowed boolean field (not configurable) has been added to the IANA 'ACME Authorization Object Fields' registry defined in RFC 8555, with reference to RFC 9444.
ACME for Subdomains assumes that control over a domain may imply control over a subdomain, and thus authorization for certificate issuance for the former may imply authorization for the latter. In ecosystems where this assumption does not hold, a more complicated threat analysis and server policy is needed.
ACME server policy for subdomain issuance should consider whether the claimed identifier is syntactically valid, whether the domain name is on the Public Suffix List or is a high-value name, and whether the key in the CSR is sufficiently strong, as per RFC 8555 Section 10.5.
Clients should deactivate authorization objects for ancestor domains or their accounts entirely if an account key is compromised or if a subdomain authorization is no longer needed, using the mechanisms specified in RFC 8555 Sections 7.5.2 and 7.3.6 respectively.
When comparing domains to determine if one is a subdomain of another, implementations MUST compare entire DNS labels and not rely on string prefix matches, as prefix matching may yield incorrect results (e.g., ooo.example.com must not be considered a subdomain of oo.example.com).
In the pre-authorization flow, the authorization object starts in 'pending' state after creation. Once the ACME server validates the DNS challenge (or HTTP challenge), it transitions the authorization object and associated challenge object to 'valid' state. If validation is slow, the server may return 'processing' and the client must poll.