We’re using wildcard certificates with dnsChallenge everywhere, however, we onboarded a service that is delegated to nameservers we don’t control. We had to add another certificateResolver to Traefik using httpChallenge, but actually tlsChallenge.
Our first attempt was using httpChallenge with the following static config:
certificatesResolvers:
le-prod-http:
acme:
email: "[email protected]"
keyType: "RSA4096"
httpChallenge:
entryPoint: web
This resulted in the following log errors:
traefikee_controller-0.1.ooby8h4drk1g@ovh03 | time="2022-04-09T21:03:21Z" level=error
msg="Unable to obtain ACME certificate for domains \"service.example.com\": unable to
generate a certificate for the domains [service.example.com]: error: one or more domains
had a problem:\n[service.example.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized ::
Invalid response from https://service.example.com/.well-known/acme-challenge/_4GMS8OYr_Ya4AKFPBHwBJ_mIhCTQWoWFMD11uCax5E
[123.123.123.123]: 404\n" routerName=prod-example-secure@docker providerName=le-prod-http.acme ACME
CA="https://acme-v02.api.letsencrypt.org/directory" rule="Host(`service.example.com`)"
Notice the 404 error and the https prefix on the acme-challenge url. httpChallenge explicitly happens over http so Traefik publishes the challenge to http urls. If you’re using the copypasta global https redirect found everywhere on the net, or any other variant of http->https redirection, the Let’s Encrypt httpChallenge isn’t going to work for you. Thankfully the fix is simple. Traefik provides us with tlsChallenge which saves the day.
Add this to your static configuration with the following and apply it.
certificatesResolvers:
le-prod-tls:
acme:
email: "[email protected]"
keyType: "RSA4096"
tlsChallenge: {}
Now update your service label and redeploy the stack.
- "traefik.http.routers.prod-example-secure.tls.certresolver=le-prod-tls"
Acme should now be using TLS-ALPN-01 challenges which will yeild a successful certificate request.
