Repository: traefik/traefik (language: go)

Issue:
Certificate renewal and generation fails for wildcard domain using gandiv5 DNS challenge
### Welcome!

- [X] Yes, I've searched similar issues on [GitHub](https://github.com/traefik/traefik/issues) and didn't find any.
- [X] Yes, I've searched similar issues on the [Traefik community forum](https://community.traefik.io) and didn't find any.

### What did you do?

Upgrading from docker image for Traefik 2.9.1 to 2.9.4 and subsequent (bringing lego 4.9.0+).
I am unable to process a cert renewal (wildcard gandiv5 dns challenge) with the following error :

`time="2023-01-28T17:13:58+01:00" level=error msg="Error renewing certificate from LE: {subdomain.domain.name [*.subdomain.domain.name]}" providerName=letsencrypt.acme error="error: one or more domains had a problem:\n[*.subdomain.domain.name] [*.subdomain.domain.name] acme: error presenting token: gandiv5: unexpected authZone domain.name. for fqdn domain.name.\n[subdomain.domain.name] [subdomain.domain.name] acme: error presenting token: gandiv5: unexpected authZone domain.name. for fqdn domain.name.\n" ACME CA="https://acme-v02.api.letsencrypt.org/directory"`

### What did you see instead?

The issue seems related to the packaged lego component from version 4.9.0 brought with Traefik 2.9.4 and subsequent.

Since [v4.9.0](https://github.com/go-acme/lego/releases/tag/v4.9.0) lego follows CNAME as expected by the ACME, see https://letsencrypt.org/2019/10/09/onboarding-your-customers-with-lets-encrypt-and-acme.html#the-advantages-of-a-cname

In order to allow certificate generation or renewal in such a case, one must add the following to the Traefik docker definition file : 

`      - LEGO_DISABLE_CNAME_SUPPORT=true`

### What version of Traefik are you using?

2.9.6

### What is your environment & configuration?

```yaml

    environment:
      - GANDIV5_API_KEY=APIKEYGOESHERE
    
    labels:
      - "traefik.http.routers.traefik-secure.tls.certresolver=letsencrypt"
      - "traefik.http.routers.traefik-secure.tls.domains[0].main=subdomain.domain.name"
      - "traefik.http.routers.traefik-secure.tls.domains[0].sans=*.subdomain.domain.name"
```

Add more configuration information here.
traefik.yml

```
certificatesResolvers:
  letsencrypt:
    acme:
      email: emacron@gmail.com
      storage: /acme.json
      dnsChallenge:
        provider: gandiv5
        resolvers:
          - "1.1.1.1:53"
          - "8.8.8.8:53"
```





### If applicable, please paste the log output in DEBUG level

_No response_


Discussion / hints:
https://github.com/go-acme/lego/issues/1772
Hello,

the change related to CNAME support is expected (but not some side effects).

hello @Lefuneste83 ,

Sorry, but we're not sure to follow.

Are you saying that if you set `LEGO_DISABLE_CNAME_SUPPORT=true` in your docker-compose then there's no problem anymore ?

If yes, do you still think that there's a problem in Traefik regarding your issue?

All I am saying is that this change, although entirely brought by the lego component, may be considered as a regression in some specific, but quite common use cases, and that it should at least be documented somewhere (maybe this ticket is sufficient).
The added environment variable does indeed seem to correct the issue in my case (wildcard with gandiv5).
TODO:
- in acme provider doc: mention CNAME support, and LEGO_DISABLE_CNAME_SUPPORT=true option
- in FAQ: explain that they can use option when they get error such as the one reported by OP

Fix patch:
diff --git a/docs/content/getting-started/faq.md b/docs/content/getting-started/faq.md
index 01b33f6398..1ae3def8e5 100644
--- a/docs/content/getting-started/faq.md
+++ b/docs/content/getting-started/faq.md
@@ -181,3 +181,23 @@ and the message should help in figuring out the mistake(s) in the configuration,
 
 When using the file provider,
 one easy way to check if the dynamic configuration is well-formed is to validate it with the [JSON Schema of the dynamic configuration](https://json.schemastore.org/traefik-v2-file-provider.json).
+
+## Why does Let's Encrypt wildcard certificate renewal/generation with DNS challenge fail?
+
+If you're trying to renew wildcard certificates, with DNS challenge,
+and you're getting errors such as:
+
+```txt
+msg="Error renewing certificate from LE: {example.com [*.example.com]}"
+providerName=letsencrypt.acme error="error: one or more domains had a problem:
+[example.com] acme: error presenting token: gandiv5: unexpected authZone example.com. for fqdn example.com."
+```
+
+then it could be due to `CNAME` support.
+
+In which case, you should make sure your infrastructure is properly set up for a
+`DNS` challenge that does not rely on `CNAME`, and you should try disabling `CNAME` support with:
+
+```bash
+LEGO_DISABLE_CNAME_SUPPORT=true
+```
diff --git a/docs/content/https/acme.md b/docs/content/https/acme.md
index 7d942b1a20..89326e1b56 100644
--- a/docs/content/https/acme.md
+++ b/docs/content/https/acme.md
@@ -283,8 +283,19 @@ Use the `DNS-01` challenge to generate and renew ACME certificates by provisioni
     # ...
     ```
 
-    !!! important
-        A `provider` is mandatory.
+!!! warning "`CNAME` support"
+
+    `CNAME` are supported (and sometimes even [encouraged](https://letsencrypt.org/2019/10/09/onboarding-your-customers-with-lets-encrypt-and-acme.html#the-advantages-of-a-cname)),
+    but there are a few cases where they can be [problematic](../../getting-started/faq/#why-does-lets-encrypt-wildcard-certificate-renewalgeneration-with-dns-challenge-fail).
+
+    If needed, `CNAME` support can be disabled with the following environment variable:
+
+    ```bash
+    LEGO_DISABLE_CNAME_SUPPORT=true
+    ```
+
+!!! important
+    A `provider` is mandatory.
 
 #### `providers`
 


Test patch: