Why does wildcard certificates require a new ACME protocol?

Why does wildcard certificates require a new ACME protocol?

What is the problem of rejecting any validation attempts with any other method than DNS (dns-01 validation), if they are attempted on a wildcard certificate request?

Yes, it would “cost” an extra roundtrip to the server without the v2 ACME where the server can tell which methods are acceptable Before doing authorization, but that would still save much more Resources than requesting a single cert for each domain.

you should review the announcement as all these questions have been discussed and answered in detail

in short DNS validation is the only way to prove that you control domain. HTTP/TLS validation doesn’t work for example if you have another party looking after a server for you (one of let’s say 1000)


I already covered that in my question.

Current ACME protocol uses a “hardcoded” list of acceptable challenge types. Since its the server deciding if a authorization is accepted, it could process HTTPS/TLS challenges for wildcard certificates, but reject them as invalid (authorization failed) at the last step instead of issuing the certificate, on the server, even if the authorizations are in fact valid (since HTTPS/TLS isn’t acceptable for wildcard).

Basically, pretend to accept a HTTPS/TLS validation by providing the requied challenge, and then fail it at submission of challenge completion regardless of the actual authorization result. It does not even need to check if the HTTPS/TLS authorization is present, it could just immidiately fail it.

And only accept DNS-01 authorization of the base domain for wildcard certificates.

This means only the server software (inside Let’s encrypt server Machines) does need to be changed. The client software or ACME protocol does not need to be changed.

i believe that there is a new API endpoint being deployed (to align boulder with version 7 of the ACME protocol) which is why clients will need to be updated to work with this new API endpoint

I also believe the old endpoint will allow issuance of wildcard certificates so clients you are using now will be able to issue wildcards

@jsha @cpu can you confirm I am on the right track?

I know that the ACME protocol is being updated. But what I meant is that the wildcard certificate system could be deployed already today, even with the “old” ACME protocol, by making the Changes I suggested.

My understanding is that the old endpoint will not allow wildcards. But technically, the old endpoint can validate wildcards by doing as I outlined in my post.

It’s true that we could “backport” wildcard certificate issuance into our ACMEv1 endpoint, but it’s additional work, it would be a confusing workflow for clients, and it would leave client authors without an incentive to implement the newest protocol. Since we want to follow the final RFC and help foster a broadly interoperable ecosystem, we think its important to have carrots for the ecosystem to move with us, in addition to the stick of eventually shutting down the ACMEv1 endpoint (with suitable advance notice).

Clients will need to be updated in order to issue wildcards.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.