[Anleitung] DANE/TLSA mit Letsencrypt

  • Hallo Leute,


    ich wollte heute mal eine kleine Anleitung dazu geben, wie Ihr DANE in Verbindung mit Letsencrypt verwenden könnt.
    Das ganze kann relativ kompliziert werden und die Anleitungen im Internet sind meist nicht vollständig zu gebrauchen oder auf Netcup anwendbar.


    Voraussetzungen für diese Anleitung:

    • Im CCP ist für die Domains DNSSEC aktiviert
    • Letsencrypt / Certbot eingerichtet
    • Zertifikate für eure Domains beantragt
    • E-Mail/SMTP Server mit STARTTLS und Zertifikat konfiguriert
    • Es wird die fullchain.pem verwendet


    Ihr braucht also ein vollständig laufendes System, indem nur noch DANE fehlt ;)
    Hinweis: Für SMTP ist es notwendig a) einen einzelnen MX Hostname für alle Domains zu verwenden oder b) ein sammel Zertifikat in dem alle Domains enthalten sind


    1. Schritt: Zertifikat Fingerprint
    Dazu empfehle ich das TLSAGEN Skript von sys4.de

    Code
    printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' \
        $(uname -n) \
        $(openssl x509 -in cert.pem -noout -pubkey |
            openssl pkey -pubin -outform DER |
            openssl dgst -sha256 -binary |
            hexdump -ve '/1 "%02x"')


    Dieses Skript speichern unter:
    /etc/letsencrypt/live/deinedomain.tld/
    Ausführbar machen und starten, der Output enthält nun den notwendigen Hash des aktuellen Letsencrypt Zertifikates.


    2. Schritt: Letsencrypt CA Fingerprint
    Wir benötigen nun noch den Hash von der Letsencrypt CA selbst, ich verwende "Let’s Encrypt Authority X3",
    in der Zukunft könnte sich dieses Zertifikat ändern.
    X1 und X2 sind mittlerweile veraltet, X4 dient derzeit dem worst-case Szenario als Backup.


    Chain of Trust - Let's Encrypt - Free SSL/TLS Certificates


    Wir downloaden also das X3 Zertifikat von Letsencrypt und generieren hiermit den Hash:

    Code
    openssl x509 -in lets-encrypt-x3-cross-signed.pem -noout -pubkey | openssl rsa -pubin -outform DER | openssl dgst -sha256 -hex | awk '{print "le-ca TLSA 2 1 1", $NF}'


    Damit haben wir den Hash des aktuellen Letsencrypt CA Zertifikates.


    3. Schritt: TLSA RR erstellen
    Im CCP könnt Ihr nun die RR für TLSA erstellen für jede Domain, die sollten wie folgt aussehen:

    Code
    Host	Type	Destination
    *._tcp	TLSA	3 1 1 HASH_AUS_SCHRITT_1
    *._tcp	TLSA	2 1 1 HASH_AUS_SCHRITT_2


    *._tcp sorgt dafür, dass dieser TLSA Eintrag für jeden Port gilt, Ihr könnt es bei bedarf auch nur auf SMTP beschränken durch _25._tcp


    4. Schritt: Validierung
    Sobald die Änderung übernommen wurden könnt Ihr hier prüfen ob alles funktioniert hat:
    DANE SMTP Validator


    5. Schritt: Zertifikat Erneuerung
    Wenn Ihr euer Zertifikat erneuert muss auch der TLSA RR aktualisiert werden.
    Dazu führt die Schritte 1-4 erneut aus.
    Schritt 2 kann übersprungen werden, wenn sich das Letsencrypt CA Zertifikat nicht geändert hat (sollte die nächsten Jahre so sein).


    Da der Certbot automatisch die Zertifikate erneuert und keine Info E-Mail versendet, kann es leider sein, dass man den Tag verpasst.
    Das ist jedoch nicht weiter schlimm aus folgendem Grund:


    Wir verwenden oben "3 1 1" und "2 1 1" Einträge, den Grund findet man hier:
    Please avoid "3 0 1" and "3 0 2" DANE TLSA records with LE certificates - Server - Let's Encrypt Community Support
    Durch das Pinnen der Letsencrypt CA haben wir eine Art "fallback", wenn unser Zertifikat erneuert wurde ist weiterhin der TLSA RR von der Letsencrypt CA gültig.
    Sollte Letsencrypt jedoch das "Let’s Encrypt Authority X3" Zertifikat ändern gilt dies nicht mehr!
    Daher sollte man es dennoch nicht vernachlässigen die TLSA RR zu aktualisieren ;)



    Damit endet nun meine Anleitung, ich hoffe sie ist soweit verständlich.


    Mit freundlichen Grüßen,
    MrKrabat

  • Ich habe DANE Records für meine Let's Encrypt Domains erzeugt. Bei der Prüfung auf https://dane.sys4.de/ wird DNSSEC, TLSA und SMTP grün dargestellt. Gehe ich jedoch auf "Show Details", so erhalte ich die Meldung: 3, 1, 1 bafc737adac74c18[...]0efd0a1eb5c7e62d - certificate not trusted: (27) - certificate not trusted: (27)Der 2,1,1.... Record ist offenbar in Ordnung. Was kann ich tun?

  • Gehe ich jedoch auf "Show Details", so erhalte ich die Meldung: 3, 1, 1 bafc737adac74c18[...]0efd0a1eb5c7e62d - certificate not trusted: (27) - certificate not trusted: (27)Der 2,1,1.... Record ist offenbar in Ordnung. Was kann ich tun?

    was ergibt das

    openssl x509 -in ./sslcert.crt -noout -pubkey |openssl pkey -pubin -outform DER |openssl dgst -sha256 -binary |hexdump -ve '/1 "%02X"'

    und was hast im DNS definiert?

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Meinst du das Kommando aus Schritt 2 der Anleitung? Dort wird ja der 2.1.1 Satz erzeugt. Reklamiert wird der 3.1.1 Satz. Beide sind richtig im DNS eingetragen. Für meine anderen Domains klappt das auch.

  • ich mein das was ich geschrieben habe ...

    Ich habe keine Datei sslcert.crt. Ist das die cert.pem? Mit dieser Datei erhalte ich wieder den Record, der mit dem fingerprint Script erzeugt wurde und der mit

    *._tcp TLSA 3 1 1

    im DNS eingetragen wurde. Allerdings sind die hexadezimalen Buchstaben nun Großbuchstaben, das sollte keine Rolle spielen.

  • Ich habe DANE Records für meine Let's Encrypt Domains erzeugt. Bei der Prüfung auf https://dane.sys4.de/ wird DNSSEC, TLSA und SMTP grün dargestellt. Gehe ich jedoch auf "Show Details", so erhalte ich die Meldung: 3, 1, 1 bafc737adac74c18[...]0efd0a1eb5c7e62d - certificate not trusted: (27) - certificate not trusted: (27)Der 2,1,1.... Record ist offenbar in Ordnung. Was kann ich tun?

    Das bedeutet, dass das Zertifikat welches vom Server ausgeliefert wird nicht mit dem von dir im DNS hinterlegten Fingerprint übereinstimmt.


    Mögliche Ursachen:

    A) Das Zertifikat wurde erneuert und du musst den DNS Eintrag updaten, siehe Schritt 5.

    B) Dein Server liefert ein anderes Zertifikat aus als du in Schritt 1 verwendet hast. Prüfe deine Konfiguration, welches Zertifikat verwendet wird.

  • Hallo,


    vielen Dank für die Anleitung, hat mir definitiv weiter geholfen. Da Let's Encrypt in Kürze das X3 Zertifikat auslaufen lässt und auf das R3 umsteigt, habe ich die "2 1 1" Einträge bei mir entsprechend angepasst. Zusätzlich wird auch empfohlen die Backup Stammzertfikate ebenfalls im DNS zu hinterlegen. Ich habe daher bei mir jetzt alle "2 1 1" Einträge entsprechend folgender Seite überprüft und anschließend gesetzt:

    http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html


    Wenn ich diese DNS Einträge nun mit dem dane.sys4.de Tool validiere, werden mir nur das "2 1 1" basierend auf dem X3 und mein "3 1 1" basierend auf meinem Zertifikat als gültig angezeigt. Die Einträge sollten jedoch korrekt sein. Liegt das einfach daran, dass mein Zertifikat (noch) nicht mit dem E3 signiert wurde bzw. die restlichen Intermediates aktuell nicht verwendet werden und somit mein Zertifikat nicht signieren oder habe ich einen Fehler gemacht?


    Die Meldung auf dane.sys4.de für die anderen Intermediates ist immer "certificate not trusted: (27) - certificate not trusted: (27)"


    Danke und Grüße
    Matthias

  • Genau das liegt dran das die Zertifikate z. B. mit dem Intermediate X3 erstellt wurden und deshalb der Hash vom neu zu verwendenden R3 / E1 whatever nicht in der Zertifikatskette enthalten ist. Erst wenn sie von LE mit dem R3 /E1 whtatever erzeugt wurden steht beim X3 not trusted da es nicht mehr in der Zertifikatskette enthalten ist. Wichtig ist das mindesten 2 TLSA Record valide sind, ansonsten kann es z. B. bei Mailserver zu Problemen kommen, die man mit einen oder mehreren aktuellen und zukünftigen Records nicht bekommt.

  • Die Meldung auf dane.sys4.de für die anderen Intermediates ist immer "certificate not trusted: (27) - certificate not trusted: (27)"

    Es empfiehlt sich grundsätzlich, mehr als einen unabhängigen Test durchzuführen. Eine (ggf. im Fehlerfall aussagekräftigere) Alternative ist bspw. https://www.hardenize.com/

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Genau das liegt dran das die Zertifikate z. B. mit dem Intermediate X3 erstellt wurden und deshalb der Hash vom neu zu verwendenden R3 / E1 whatever nicht in der Zertifikatskette enthalten ist. Erst wenn sie von LE mit dem R3 /E1 whtatever erzeugt wurden steht beim X3 not trusted da es nicht mehr in der Zertifikatskette enthalten ist. Wichtig ist das mindesten 2 TLSA Record valide sind, ansonsten kann es z. B. bei Mailserver zu Problemen kommen, die man mit einen oder mehreren aktuellen und zukünftigen Records nicht bekommt.

    Danke, dann habe ich es richtig verstanden und korrekt eingetragen.


    Es empfiehlt sich grundsätzlich, mehr als einen unabhängigen Test durchzuführen. Eine (ggf. im Fehlerfall aussagekräftigere) Alternative ist bspw. https://www.hardenize.com/

    Hardenize ist natürlich auch ein guter Tipp, hatte ich schon wieder verdrängt. Sind einfach sehr viele Tools die alle irgendwelche Vor- und Nachteile haben um DNS-Records, Webserver-Header, Zertifikate, etc. pp. zu testen.

  • Hallo allerseits, bin auf diesen Thread gestoßen da er für mich gerade aktuell ist :)


    Habe selbst nen NginxProxyManager für meine ganzen Certs am laufen. Der holt u.a. auch über das Netcup Plugin ein wildcard ab.

    Ist es möglich mit irgendeinen certbot befehl in der CLI den TLSA Record neu zu setzen?


    Falls das geht, also alten 2-3 TLSA löschen und mit neuen überschreiben, wäre das mit dem reuse Key auch Vergangenheit :)