DNS-01 validation for non-wildcard names about getssl HOT 3 OPEN

There's actually an erratum clarifying that either absent or "false" is acceptable, so upon further reading I don't believe Sectigo is being non-compliant. Note that the example in that section contains "wildcard": false!

Edit: this erratum was reported in 2020, but just verified on 2024-03-22. Coincidence? Maybe, but awfully timely!

I agree that interpreting "true" as wildcard and everything else as not makes the most sense.

from getssl.

Heh, I just ran into the same issue. I've been using Incommon ACME for a year or so for both wildcard and non-wildcard certs, then it mysteriously broke within the past few weeks. I tracked it down to the same code you did, but fixed it a little differently:

1233a1234,1236
>       if [ -z "$wildcard" ] ; then
>         wildcard=false
>       fi
1240c1243
<         if [[ ( "$lower_d" == "$authdomain" && -z "$wildcard" ) || ( "$lower_d" == "*.${authdomain}" && -n "$wildcard" ) ]]; then
---
>       if [[ ( "$lower_d" == "$authdomain" && "$wildcard" == "false" ) || ( "$lower_d" == "*.${authdomain}" && "$wildcard" == "true" ) ]]; then

IMHO, per spec, JSON booleans are either "true" or "false", so checking those values seems more "correct".

I assume in the past Incommon just didn't include the wildcard attribute if the request wasn't for a wildcard, and now they do with the value "false". Per the ACME spec for wildcard certs:

https://datatracker.ietf.org/doc/html/rfc8555

"The returned authorization MUST include the optional "wildcard" field, with a value of true."

I guess either leaving it out or setting it to false for non-wildcard certs is acceptable from the server side.

from getssl.

I ran into this as well. RFC 8555 section 7.1.4 clearly reads that it can be either true or absent. present and false is not allowed. getssl is mostly correct in that if it is present it should be able to assume it is "true," but it is a bit fragile to just check for empty or not.

wildcard (optional, boolean): This field MUST be present and true
for authorizations created as a result of a newOrder request
containing a DNS identifier with a value that was a wildcard
domain name. For other authorizations, it MUST be absent.
Wildcard domain names are described in Section 7.1.3.

I fixed it in my own fork by checking for the value "true" which as we see above is the only allowed value. I put that in as a PR #844.

I also have a ticket open with Sectigo to see if they will fix this. I don't have high hopes, but if by some miracle they actually do something I'll share it here.

from getssl.