Could there be a new DNS integration problem in Lego?

[schoen]

Hi,

Over at the Let's Encrypt Community Forum, we just got a report about the error

mySSLclient.Certificate.Obtain error:error: one or more domains had a problem:\n[*.panghui.life] [*.panghui.life] acme: error presenting token: no subdomain because the domain and the zone are identical 

I first mistakenly thought this was Traefik-specific because the only other reference I could find to this error is

traefik/traefik#9826

I subsequently saw that this error is generated from

https://github.com/go-acme/lego/blob/master/challenge/dns01/domain.go

and so it could conceivably appear in some form for any Lego user using the DNS challenge.

Unfortunately, I don't know what DNS provider integration either the community forum user or the Traefik bug reporter was using. However, I wonder if something could have changed recently that could lead to a new form of DNS integration issue resulting in both of these errors. Alternatively, is there a specific mistaken way that people attempt to request certificates with Lego that might trigger this? (That seems a little less likely to me because the GitHub Traefik user says it was a renewal, not an initial cert request.)

Thanks!

[schoen]

It looks like the user on the forum is self-hosting something with Unraid and ultimately using the alidns integration. I'm not quite sure how Lego gets installed or which version it is.

Edit: Apparently it's bundled with Unraid and using an Unraid-provided UI.

[ldez]

Hello,

there is a change since v4.9.0: the support, by default, of CNAME.

To disable this support, the user has to set the env var LEGO_DISABLE_CNAME_SUPPORT to true.

[schoen]

Thanks!

I don't believe that Unraid users have a supported way to change environment variables, but I'm not positive of that because I've never used Unraid.

The original user on the Let's Encrypt forum wrote:

The cause of the problem has been identified. It is that the secondary domain name in the DNS supplier directly uses the IP of the primary domain name. By DDNS the secondary domain name separately, the problem can be solved.

I think this is consistent with what you said because there was a wildcard CNAME record in the relevant zone aliasing all RRs to the parent zone.

I don't have a good intuition for what the exact CNAME issue with the DNS-01 challenge integration is, but it sounds like you and this user have both understood the underlying problem. (I wonder if the associated error message could usefully be made more verbose.)

Anyway, thank you for looking into this!