Traefik liefert das falsche Zertifikat: SNI, Router und ACME prüfen

1. Das Zertifikat mit dem richtigen SNI prüfen

Führen Sie die Prüfung außerhalb des Hosting-Netzes aus. Behalten Sie den Hostnamen bei -servername bei, auch wenn -connect eine IP-Adresse verwendet. Notieren Sie SHA-256-Fingerabdruck, Aussteller, Gültigkeitsdaten und die Subject-Alternative-Name-Einträge. Dieser Befehl zeigt ein Zertifikat an; er prüft weder das Vertrauen in die Kette noch die Übereinstimmung des Hostnamens.

set -o pipefail
timeout 10 openssl s_client -connect example.com:443 \
  -servername example.com </dev/null |
  openssl x509 -noout -sha256 -fingerprint \
    -issuer -dates -ext subjectAltName

Ein Standardzertifikat kann bedeuten, dass kein geladenes Zertifikat zum SNI passt oder dass der Client kein SNI gesendet hat. Bei strenger SNI-Prüfung kann Traefik die Verbindung stattdessen ablehnen. Wird kein Zertifikat angezeigt, untersuchen Sie den Verbindungsfehler. Ein zusätzlicher HTTP-Host-Header ändert das Zertifikat nicht, das bereits beim TLS-Handshake ausgewählt wurde.

2. HTTPS-Router und Zertifikatsresolver prüfen

Wenn Traefik die ACME-Zertifikate Ihrer Docker-Anwendung verwaltet, prüfen Sie die Labels am laufenden Anwendungscontainer. Der Router muss den vorgesehenen EntryPoint verwenden und TLS aktivieren. Der Wert certresolver muss einen vorhandenen Resolver benennen, sofern er nicht vom EntryPoint übernommen wird. Diese Labels sind ein Auszug für eine bestehende Anwendung. Sie konfigurieren weder deren Backend-Port noch den Docker-Provider.

labels:
  - "traefik.http.routers.app.rule=Host(`example.com`)"
  - "traefik.http.routers.app.entrypoints=websecure"
  - "traefik.http.routers.app.tls=true"
  - "traefik.http.routers.app.tls.certresolver=letsencrypt"

Der Resolver gehört in die statische Traefik-Konfiguration. Das folgende Beispiel für die HTTP-Challenge definiert auch die EntryPoints. Passen Sie Kontaktadresse und persistenten Speicherpfad an. Für diese Challenge muss der öffentliche Port 80 den EntryPoint web erreichen. Bei DNS-Validierung oder einer anderen Challenge behalten Sie stattdessen die passende Konfiguration bei.

entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"
certificatesResolvers:
  letsencrypt:
    acme:
      email: [email protected]
      storage: /data/acme.json
      httpChallenge:
        entryPoint: web

Ein deklarierter Resolver wird nicht automatisch von jedem Router verwendet. Änderungen an der statischen Konfiguration erfordern einen Traefik-Neustart. Ein Provider kann seine Konfiguration dagegen dynamisch aktualisieren. Prüfen Sie vor einem Neustart die aktive Konfiguration und die Fehler. Eine HTTP-Host-Regel kann Namen für die ACME-Ausstellung liefern; SNI bestimmt, welches Zertifikat bei der jeweiligen TLS-Verbindung präsentiert wird.

3. ACME-Fehler von Auswahlproblemen unterscheiden

Wenn Traefik die Zertifikate selbst anfordert, prüfen Sie seine aktuellen Logs. In diesem Compose-Beispiel heißt der Dienst traefik. Suchen Sie nach einem unbekannten Resolver, einer fehlgeschlagenen Challenge, einem Testaussteller oder fehlenden Speicherberechtigungen. Beheben Sie den gemeldeten Fehler, bevor Sie erneut ein Zertifikat anfordern.

docker compose logs --since=30m traefik

Die konfigurierte Datei acme.json enthält private Schlüssel und ACME-Kontodaten. Halten Sie sie vertraulich und über Containerwechsel hinweg persistent. Traefik muss mit den erforderlichen Dateirechten (600) darauf zugreifen können. Löschen Sie die Datei nicht als Reparaturversuch und teilen Sie sie nicht zwischen gleichzeitig laufenden Traefik-Instanzen. Ein Logeintrag zur erfolgreichen Ausstellung prüft nicht, welches Zertifikat jede öffentliche Adresse ausliefert.

4. Bei Zertifikatsdateien die geladenen Pfade prüfen

Folgen Sie diesem Zweig, wenn ein anderes Werkzeug die Zertifikate ausstellt. Prüfen Sie tls.certificates in der dynamischen Dateikonfiguration. certFile und keyFile müssen innerhalb des Traefik-Containers unter diesen Pfaden erreichbar sein. Das Zertifikat muss den angefragten Hostnamen abdecken und zum privaten Schlüssel passen. Das folgende Beispiel ist ein Auszug aus der dynamischen Konfiguration, keine vollständige Traefik-Installation.

tls:
  certificates:
    - certFile: /certs/example.com/fullchain.pem
      keyFile: /certs/example.com/privkey.pem

Aktivieren Sie den File-Provider mit watch: true in der statischen Konfiguration. Binden Sie bei Bind-Mounts das übergeordnete Verzeichnis ein, damit Dateiänderungen erkannt werden können. Die Demonstration verweist in der dynamischen Konfiguration auf ein neues Zertifikat-Schlüssel-Paar und ersetzt die Konfigurationsdatei atomar. Prüfen Sie nach einer Erneuerung, ob Traefik die Änderung tatsächlich geladen hat. Ein ausgetauschtes Zertifikat auf der Festplatte beweist noch keine Änderung an der TLS-Verbindung.

5. Die Auslieferung eines Standardzertifikats lokal nachstellen

Das herunterladbare Skript startet Traefik auf 127.0.0.1 mit einem automatisch vergebenen Port. Es erstellt selbstsignierte Zertifikate für fallback.test, unrelated.test und renewal.test. Anfangs sind nur das unrelated-Zertifikat und das Standardzertifikat konfiguriert. Die Anfrage für renewal.test erhält das Standardzertifikat. Anschließend lädt das Skript über den File-Provider das passende Zertifikat und prüft eine neue Verbindung ohne Traefik-Neustart.

Traefik-Demonstration herunterladen und prüfen

Voraussetzungen: Linux, Bash, OpenSSL, GNU timeout und ein lokaler Docker-Daemon. Docker lädt bei Bedarf das festgelegte Image herunter. Lesen Sie das Skript und starten Sie bash traefik-certificate-selection.sh. BEFORE zeigt den Fingerabdruck des Standardzertifikats, CONTROL das durch seinen SNI ausgewählte unrelated-Zertifikat und AFTER das passende Zertifikat. NO_SNI liefert weiterhin das Standardzertifikat. Das Skript prüft die Fingerabdrücke und die unveränderte Startzeit des Containers. Temporäre Schlüssel und Container werden beim Beenden entfernt. Getestet werden Zertifikatsauswahl und dynamisches Laden, keine ACME-Ausstellung oder -Erneuerung.

6. Öffentliche Verbindungen prüfen und weiter überwachen

Prüfen Sie jede relevante öffentliche Adresse mit demselben Hostnamen als SNI. Ersetzen Sie die Beispieladresse unten; verwenden Sie für IPv6 [Adresse]:443. Ein CDN kann TLS vor Traefik terminieren und sein eigenes Zertifikat präsentieren. Bei TLS-Passthrough über einen TCP-Router präsentiert dagegen der nachgelagerte Server das Zertifikat. Prüfen Sie die Komponente, die die jeweilige Verbindung terminiert. Mehrere Instanzen, IPv4/IPv6-Pfade oder RSA/ECDSA-Handshakes können unterschiedliche Ergebnisse liefern.

set -o pipefail
timeout 10 openssl s_client -connect 192.0.2.10:443 \
  -servername example.com </dev/null |
  openssl x509 -noout -sha256 -fingerprint \
    -issuer -dates -ext subjectAltName

Nocert beobachtet regelmäßig die Zertifikate erreichbarer TLS-Endpunkte und wertet Ablaufwarnregeln in einem täglichen Zyklus aus. Prüfen Sie Endpunkt und Beobachtungszeitpunkt und konfigurieren Sie die Empfänger der Warnungen. Diese Überwachung ergänzt die unmittelbare externe Prüfung. Nocert konfiguriert Ihren Traefik-Resolver nicht, erneuert keine Zertifikate und garantiert nicht, dass jeder Besucher dasselbe Zertifikat erhält.