Letsencrypt DNS-ACME: No default certificate, fallback to the internal generated certificate

Traefik Traefik v2
,
1

I am trying to set up traefik with letsencrypt and DNS validation.
It looks like the letsencrypt certificates are generated - but not used by traefik

traefik  | time="2023-03-05T16:40:15Z" level=debug msg="No default certificate, fallback to the internal generated certificate" tlsStoreName=default
traefik  | time="2023-03-05T16:40:15Z" level=debug msg="Adding certificate for domain(s) *.dataweeder.cloud,dataweeder.cloud"
traefik  | time="2023-03-05T16:40:15Z" level=debug msg="No default certificate, fallback to the internal generated certificate" tlsStoreName=default

GitHub - geoHeil/aceme-ssl-traefik: Debugging acme ssl traefik contains the details of the traefik configuration

After reading Default certificate from letsencrypt - #6 by jakubhajek and Traefik TLS Documentation - Traefik I tried to set the default cert store to the ones generated from letsencrypt - but this does not work
aceme-ssl-traefik/docker-compose.yml at master · geoHeil/aceme-ssl-traefik · GitHub

2

switching to the production version of letsencrypt and waiting longer for DNS propagation seems to fix the issue with letsencrypt certificate generation

BUT: the / or whoami.dataweeder.com routes are still only resolving to 404s also the dashboard is not viewable. Something must be wrong with the configuration of traefik - but so far I do not yet know what.

3

I posted a simple working docker-compose.yml yesterday in a comment, maybe compare.

Did you forget to attach whoami to a Docker network?

I would not assign a service if no service (port) is defined, just remove

traefik.http.routers.whoami-rtr.service=whoami-svc

What happens when you access https://traefik.dataweeder.com/dashboard/?

4

Deleting this line does not fix the problem. https://traefik.dataweeder.com/dashboard returns a 404 - which is super confusing for me.

5

Your docker-compose file does not work for me. See it here (with modifications for Cloudflare).
However, I think the problem is not cloudflare specific, as the 404 is not SSL related. Something in the config must be off. Strangely, not even the dashboard is served.
Neither the whoami nor the traefik dashboard service result in anything besides 404:

version: '3.9'

services:
  traefik:
    image: traefik:v3.0
    ports:
      - 80:80
      - 443:443
    networks:
      - proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./z_data/letsencrypt2:/letsencrypt
    environment:
      - CF_API_EMAIL=$CLOUDFLARE_EMAIL
      - CF_API_KEY=$CLOUDFLARE_API_KEY
    command:
      - --api.dashboard=true
      - --log.level=DEBUG
      - --accesslog=true
      - --providers.docker.network=proxy
      - --providers.docker.exposedByDefault=false
      - --entrypoints.web.address=:80
      - --entrypoints.web.http.redirections.entrypoint.to=websecure
      - --entryPoints.web.http.redirections.entrypoint.scheme=https
      - --entrypoints.websecure.address=:443
      - --entrypoints.websecure.asDefault=true
      - --entrypoints.websecure.http.tls.certresolver=myresolver
      - --certificatesresolvers.myresolver.acme.dnschallenge.provider=cloudflare
      - --certificatesresolvers.myresolver.acme.email=$CLOUDFLARE_EMAIL
      - --certificatesresolvers.myresolver.acme.dnschallenge.delaybeforecheck=20
      - --certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json
    labels:
      - traefik.enable=true
      - traefik.http.routers.mydashboard.rule=Host(`traefik.$DOMAINNAME_CLOUD_SERVER`)
      - traefik.http.routers.mydashboard.service=api@internal
      - traefik.http.routers.mydashboard.middlewares=myauth
      - traefik.http.middlewares.myauth.basicauth.users=user:$$apr1$$jnlbaIYa$$2b3cCAUqLD0oWBky7zVoJ/

  whoami:
    image: traefik/whoami:v1.8
    networks:
      - proxy
    labels:
      - traefik.enable=true
      - traefik.http.routers.mywhoami.rule=Host(`whoami.$DOMAINNAME_CLOUD_SERVER`)
      - traefik.http.services.mywhoami.loadbalancer.server.port=80

networks:
  proxy:
    name: proxy
6

In the logs I can observe:

acme_ssl_traefik-traefik-1  | 2023-03-05T19:17:29Z DBG github.com/traefik/traefik/v2/pkg/tls/tlsmanager.go:294 > No default certificate, fallback to the internal generated certificate tlsStoreName=default
7

Adding: - traefik.http.routers.mywhoami.rule=Host(whoami.$DOMAINNAME_CLOUD_SERVER) || Path(/whoami) will allow to resolve https://foo.bar/whoami. The https://whoami.foo.bar is still a 404 though.

Assuming that the DNS foo.bar resolves to 127.0.0.1 - what do I have to change to allow for the 2nd option to resolve nicely as well?

8

The first thing I can think of is that the env variables are not resolved, then Traefik does not have the right domains. But I thought I have seen those domains in the logs. Can you check again? Or just try to hardcode into the config?

9

No, they definitely are resolved as these ENV variables are also used when generating the letsencrypt cert requests

and indeed these domains are in the logs.

10

In the last version of the file you posted the ENV seems not to be set.

Just for fun please try hardcoding.

11

I did - it does not change anything.

12

Config looks fine. Ping the hosts foo.bar and whoami.foo.bar and check their IPs.

13

As this is a dev setup in docker-compose: foo.bar resolves to 127.0.0.1 and whoami.foo.bar resolves to 127.0.0.1 however, traefik is not serving anything on 127.0.0.1/ besides a 404 even though it has the subdomain registered in its routes.