Authorization object is missing "wildcard" field when issuing wildcard certificates

[sipe90]

I'm having issues with cert-manager when issuing wildcard certificates using DNS01 challenges. Cert-manager presents the challenge incorrectly because the authorization object does not contain the wildcard field with value true.

According to the ACME spec:

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.

So when trying to issue a wildcard certificate for *.example.com, cert-manager sees that the wildcard-field is missing from the authorization object and so assumes that the certificate is NOT a wildcard certificate. This results in cert-manager creating a TXT record of _acme-challenge.*.example.com instead of _acme-challenge.example.com and so the challenge validation never succeeds.

[grindsa]

Thx for spotting this. Seems cert-manager is the first acme-client make use of this field. Creating a fix should not be a big issue. Will look into this later this week...

[grindsa]

A fix got already included in the devel branch and a docker image based on apache2-wsgi got uploaded to docker-hub. Can you please give it a try (docker pull grindsa/acme2certifier:devel) and check if it works for you? I am sorry but I cannot test enrolment of wildcard-certificates via cert-manager as I am missing the environment to do so.

[sipe90]

I'm getting a deserialization error from cert-manager: E1115 07:03:09.340176 1 controller.go:163] cert-manager/controller/orders "msg"="re-queuing item due to error processing" "error"="acme: invalid response: json: cannot unmarshal string into Go struct field wireAuthz.Wildcard of type bool" "key"="cert-manager/xxxxxxxxx". The wildcard field value seems to be returned as a string while it is expected to be boolean.

[grindsa]

New devel build got uploaded to dockerhub. Pls try again...

[sipe90]

Okay, now the parsing succeeds, but the created TXT record is still incorrect: _acme-challenge.*.example.com. The spec.wildcard field value is now true in the Challenge resource, but now I noticed this documentation about field spec.dnsName:

dnsName is the identifier that this challenge is for, e.g. example.com. If the requested DNSName is a 'wildcard', this field MUST be set to the non-wildcard domain, e.g. for `*.example.com`, it must be `example.com`.

Somehow the value still ended up being set to *.example.com.

Found this from the ACME spec:

An authorization returned by the server for a wildcard domain name identifier MUST NOT include the asterisk and full stop ("*.") prefix in the authorization identifier value.  The returned authorization MUST include the optional "wildcard" field, with a value of true.

[grindsa]

Ok. this explains why regression failed last night as the tests using acme.sh did fail as well. The fix is already in devel. I will upload a new image during next hour...

[sipe90]

I tested with the latest version and now the certificate was issued successfully. Seems to be working as expected by cert-manager. Thank you!

[grindsa]

Fixes got included in v0.19. Thus, I am closing the issue.