You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
https://www.rfc-editor.org/rfc/rfc9444.html has just been published as an RFC. We could choose to implement the ACME extensions specified by this document, if we think they would provide sufficient value to our community.
The minimum changes would be:
If an authorization is fulfilled via BRs 3.2.2.4.7 DNS Change (i.e. DNS-01), then add the subdomainAuthAllowed: true field to that authz
When collecting pre-existing authzs to attach to a new Order object, if there are any valid authzs for ancestor domains that have the subdomainAuthAllowed flag set, use those
The combination of those changes would potentially allow clients to take advantage of subdomain auth without the clients themselves having to make any changes. Specifically in the situation where a client requests certificates for both "example.com" and "sub.example.com", and uses DNS-01 to fulfill those authzs.
More comprehensive changes would be:
3. Add the subdomainAuthAllowed: true capability flag to the directory meta object
4. Respect the ancestorDomain: "foo.com" field in the identifier fields of newOrder requests
We won't be implementing the pre-authorization subdomainAuthAllowed: true flag, as we do not implement pre-authorization at all.
The text was updated successfully, but these errors were encountered:
https://www.rfc-editor.org/rfc/rfc9444.html has just been published as an RFC. We could choose to implement the ACME extensions specified by this document, if we think they would provide sufficient value to our community.
The minimum changes would be:
subdomainAuthAllowed: true
field to that authzThe combination of those changes would potentially allow clients to take advantage of subdomain auth without the clients themselves having to make any changes. Specifically in the situation where a client requests certificates for both "example.com" and "sub.example.com", and uses DNS-01 to fulfill those authzs.
More comprehensive changes would be:
3. Add the
subdomainAuthAllowed: true
capability flag to the directory meta object4. Respect the
ancestorDomain: "foo.com"
field in the identifier fields of newOrder requestsWe won't be implementing the pre-authorization
subdomainAuthAllowed: true
flag, as we do not implement pre-authorization at all.The text was updated successfully, but these errors were encountered: