Benutzer-Werkzeuge

Webseiten-Werkzeuge


tachtler:let_s_encrypt_-_tlsa-record_-_dane

Dies ist eine alte Version des Dokuments!


Let's Encrypt - TLSA-Record - DANE

Let's Encrypt ist eine kostenlose, automatisierte und offene Zertifizierungsstelle (CA), welche offiziell dem Nutzen der Öffentlichkeit dienen soll. Let's Encrypt ist ein Service der von der Internet Security Research Group (ISRG) zur Verfügung gestellt wird.

Let's Encrypt bietet öffentlich, jederman digitalen Zertifikate an, um HTTPS (SSL / TLS) Verschlüsselung für Websites zu ermöglichen. Dies wird kostenlos und in einer möglichst benutzerfreundlichen Art und Weise angeboten. Let's Encrypt tut dies, weil Let's Encrypt offiziell ein sichereres und die Privatsphäre respektierendes Internet fördern möchte.

===== Grundlagen TLSA-Record ===== Der TLSA-Record ist wie folgt aufgebaut: <code ini> _[Port]._[Protokoll].[SUBDOMAIN].[DOMAIN].[TLD] [TTL] IN TLSA (DATEN = [Zahl] [Zahl] [Zahl] [HASH]) </code> Für einen Standard SMTP Server wäre das z.B. das der Port 25 und das TCP Protokoll. Im Feld Record wird daher folgendes eingegeben: _25._tcp Wenn das Zertifikat für einen Host einer Subdomain gültig ist muss der Record z.B. für die bekannte mx Subdomain wie folgt aussehen: _25._tcp.mx Das Daten Feld enthält 4 Informationen getrennt von Leerzeichen und optional von einer Klammer umschlossen: <code ini> ([Zahl] [Zahl] [Zahl] [HASH]) </code> Die erste Zahl ist ein Wert von 0 bis 3: * 0: Der Hash gehört der Zertifizierungsstelle die Zertifikate für diesen Host ausstellen darf. Der Client muss die Zertifizierungsstelle kennen oder diese muss von einer vertrauten Zertifizierungsstelle unterschrieben sein. * 1: Der Hash gehört dem Serverzertifikat. Es muss von einer Zertifizierungsstelle unterschrieben sein der vom Client vertraut wird. * 2: Der Hash gehört einer Zertifizierungsstelle die Zertifikate für diesen Host ausstellen darf. Der Client soll Ihr Vertrauen auch wenn sie ihm Unbekannt und von keiner bekannten Zertifizierungsstelle unterschrieben ist. * 3: Der Hash gehört dem Serverzertifikat und der Client soll diesem ohne weitere Prüfung der Vertrauenskette trauen. Die Zweite Zahl kann 0 oder 1 sein und gibt an wie der Hash überprüft wird: * 0: Es wird ein Hash vom kompletten Zertifikat erstellt. * 1: Es wird nur ein Hash vom Public Key und des Algorithmus erstellt. Die Dritte Zahl enthält einen wert von 0 bis 2: * 0: Der Hash enthält das komplette Zertifikat (nicht empfohlen). * 1: Der Hash enthält einen SHA-256 Hash. * 2: Der Hash enthält einen SHA-512 Hash. ===== Vorbereitung ===== Nachfolgende Anleitung aus dem internen Link, zeigt wie Zertifikate generell durch die Verwendung von Let's Encrypt erstellt werden und muss zwingend bereits erfolgreich durchgeführt worden sein !!! * Let's Encrypt :!: HINWEIS - Ein aktuell generiertes Zertifikat muss bereits vorhanden sein !!! Nachfolgend wird in dieser Anleitung davon ausgegangen, dass ein * Let's Encrypt-Zertifikat in nachfolgendem Verzeichnis liegt: * /opt/dehydrated-master/certs/[DOMAIN] bzw. eigene Let's Encrypt-Zertifikats-Generierung für den MTA-Postfix unter: * /opt/dehydrated-master-postfix/certs/[DOMAIN] * [DOMAIN] steht hier für den Verzeichnisnamen z.B. mx1.tachtler.net ===== Generierung TLSA-Records (SMTP) ===== Nachfolgend sollen zwei TLSA-Records erstellt werden. Der Grund dafür liegt in der Erneuerung des eigentlichen Let's Encrypt-Zertifikats, welche nach aktuellem Stand nur Zertifikate für 90 Tage ausstellt. Dies macht es erforderlich, auch den TLSA-Record alle 90 Tage zu erneuern. Damit nun, wenn einmal die Erstellung eines neuen Zertifikats nicht rechtzeitig erfolgt, eine Art „Fallback“-Szenario existiert, soll auch ein TLSA-Record für das Root-Zertifikat der Let's Encrypt CA zusätzlich erstellt werden. Durch die Erstellung eines TLSA-Records für das Root-Zertifikat der Let's Encrypt CA ist dies eben das „Fallback“-Szenario. Das bedeutet, dass so lange bis das eigentliche Let's Encrypt-Zertifikat erneuert wurde, weiterhin der TLSA-Record der Let's Encrypt-CA (Root-Zertifikat) gültig ist und zur Validierung verwendet werden kann. :!: WICHTIG - Sollte sich jedoch das Let's Encrypt-Root-Zertifikat „Let’s Encrypt Authority X3“ Zertifikat einmal ändern, muss auch dieser TLSA-Record erneuert werden! ==== TLSA-Record - Let's Encrypt Zertifikat (SMTP) ==== Nachfolgend soll auf Basis des TLSAGEN-Script der [*] sys4 AG der FINGERPRINT des eigentlichen Let's Encrypt-Zertifikats erstellt werden. Dazu soll der FINGERPRINT des eigentlichen Let's Encrypt-Zertifikats, welches hier im Verzeichnis * /opt/dehydrated-master-postfix/certs/mx1.tachtler.net/ liegt, verwendet werden. Nachfolgender Aufruf des einzeiligen Befehls sollte nachfolgende Ausgabe erzeugen: <code> # printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' mx1.tachtler.net $(openssl x509 -in /opt/dehydrated-master-postfix/certs/mx1.tachtler.net/cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 „%02x“') _25._tcp.mx1.tachtler.net. IN TLSA 3 1 1 e9bc354eaffcf2751f847a22fd6d021cb94a9a015e1d64f76673e41f9f0b8f88 </code> Parameter für den Aufruf: - Die DANE-EE(3) Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
3 1 1 - Die Domäne muss entsprechend angepasst werden, hier verwendet:
mx1.tachtler.net - Der Speicherort und der Dateiname des Zertifikats muss entsprechend angepasst werden. hier verwendet:
/opt/dehydrated-master-postfix/certs/mx1.tachtler.net/cert.pem Das Ergebnis ist der fertige TLSA-Record: <code> _25._tcp.mx1.tachtler.net. IN TLSA 3 1 1 e9bc354eaffcf2751f847a22fd6d021cb94a9a015e1d64f76673e41f9f0b8f88 </code> ==== TLSA-Record - Let's Encrypt Root CA Zertifikat (SMTP) ==== Bevor mit der Erstellung des TLSA-Records aus dem Let's Encrypt-Root-Zertifikat der Let's Encrypt-CA begonnen werden soll, muss dieses erst einmal heruntergeladen werden, was mit nachfolgendem Befehl durchgeführt werden kann: :!: HINWEIS - Nachfolgende Links/URLs sind zum Zeitpunkt der Erstellung dieses Eintrags aktuell gewesen: * https://letsencrypt.org/certificates/ * https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt <code> # wget -P /tmp https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt –2018-08-29 09:05:17– https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt Resolving letsencrypt.org (letsencrypt.org)… 104.108.65.96, 2a02:26f0:7b:282::ce0, 2a02:26f0:7b:28c::ce0 Connecting to letsencrypt.org (letsencrypt.org)|104.108.65.96|:443… connected. HTTP request sent, awaiting response… 200 OK Length: 1647 (1.6K) [text/plain] Saving to: ‘/tmp/lets-encrypt-x3-cross-signed.pem.txt’ 100%[=====================================⇒] 1,647 –.-K/s in 0s 2018-08-29 09:05:18 (128 MB/s) - ‘/tmp/lets-encrypt-x3-cross-signed.pem.txt’ saved [1647/1647] </code> Ob das Herunterladen auch durchgeführt wurde, kann mit nachfolgendem Befehl überprüft werden: <code> # ls -la /tmp/lets-encrypt-x3-cross-signed.pem.txt -rw-r–r– 1 root root 1647 Jan 20 2018 /tmp/lets-encrypt-x3-cross-signed.pem.txt </code> Nachfolgend soll auf Basis des TLSAGEN-Script der [*] sys4 AG der FINGERPRINT des Let's Encrypt-Root–Zertifikats aus der Let's Encrypt-CA erstellt werden. Jetzt kann der FINGERPRINT des Let's Encrypt-Root–Zertifikats aus der Let's Encrypt-CA, welches hier im Verzeichnis * /tmp/ liegt, verwendet werden. Nachfolgender Aufruf des einzeiligen Befehls sollte nachfolgende Ausgabe erzeugen: <code> # printf '_25._tcp.%s. IN TLSA 2 1 1 %s\n' mx1.tachtler.net $(openssl x509 -in /tmp/lets-encrypt-x3-cross-signed.pem.txt -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 „%02x“') _25._tcp.mx1.tachtler.net. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 </code> Parameter für den Aufruf: - Die DANE-TA(2) Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
2 1 1 - Die Domäne muss entsprechend angepasst werden, hier verwendet:
mx1.tachtler.net - Der Speicherort und der Dateiname des Zertifikats muss entsprechend angepasst werden. hier verwendet:
/tmp/lets-encrypt-x3-cross-signed.pem.txt Das Ergebnis ist der fertige TLSA-Record: <code> _25._tcp.mx1.tachtler.net. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 </code> ===== Enrichtung DNS (SMTP) ===== Nachfolgend wird dargestellt, wie die DNS-Records entsprechend im jeweiligen DNS-Server hinterlegt werden können: <code> _25._tcp.mx1.tachtler.net. 600 IN TLSA 3 1 1 e9bc354eaffcf2751f847a22fd6d021cb94a9a015e1d64f76673e41f9f0b8f88 _25._tcp.mx1.tachtler.net. 600 IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 </code> Ein Abfrage, mittels des Befehls dig, sollte dann wie nachfolgend dargestellt aussehen: <code> # dig _25._tcp.mx1.tachtler.net IN TLSA ; «» DiG 9.9.4-RedHat-9.9.4-61.el7 «» _25._tcp.mx1.tachtler.net IN TLSA ;; global options: +cmd ;; Got answer: ;; →>HEADER«- opcode: QUERY, status: NOERROR, id: 32428 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_25._tcp.mx1.tachtler.net. IN TLSA ;; ANSWER SECTION: _25._tcp.mx1.tachtler.net. 600 IN TLSA 3 1 1 E9BC354EAFFCF2751F847A22FD6D021CB94A9A015E1D64F76673E41F 9F0B8F88 _25._tcp.mx1.tachtler.net. 600 IN TLSA 2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18 ;; AUTHORITY SECTION: tachtler.net. 10800 IN NS ns1.tachtler.net. ;; ADDITIONAL SECTION: ns1.tachtler.net. 10800 IN A 192.168.0.20 ;; Query time: 0 msec ;; SERVER: 192.168.0.20#53(192.168.0.20) ;; WHEN: Wed Aug 29 09:53:19 CEST 2018 ;; MSG SIZE rcvd: 187 </code> ===== Überprüfung (SMTP) ===== Zur Überprüfung, ob die TLSA-Records auch korrekt gesetzt sind und auch zum jeweiligen, hier MTA passen, kann nachfolgender externer Link der [*] sys4 AG verwendet werden: * https://dane.sys4.de/  https://dane.sys4.de/ ===== Generierung TLSA-Records (HTTPS) ===== Nachfolgend sollen zwei TLSA-Records erstellt werden. Der Grund dafür liegt in der Erneuerung des eigentlichen Let's Encrypt-Zertifikats, welche nach aktuellem Stand nur Zertifikate für 90 Tage ausstellt. Dies macht es erforderlich, auch den TLSA-Record alle 90 Tage zu erneuern. Damit nun, wenn einmal die Erstellung eines neuen Zertifikats nicht rechtzeitig erfolgt, eine Art „Fallback“-Szenario existiert, soll auch ein TLSA-Record für das Root-Zertifikat der Let's Encrypt CA zusätzlich erstellt werden. Durch die Erstellung eines TLSA-Records für das Root-Zertifikat der Let's Encrypt CA ist dies eben das „Fallback“-Szenario. Das bedeutet, dass so lange bis das eigentliche Let's Encrypt-Zertifikat erneuert wurde, weiterhin der TLSA-Record der Let's Encrypt-CA (Root-Zertifikat) gültig ist und zur Validierung verwendet werden kann. :!: WICHTIG - Sollte sich jedoch das Let's Encrypt-Root-Zertifikat „Let’s Encrypt Authority X3“ Zertifikat einmal ändern, muss auch dieser TLSA-Record erneuert werden! ==== TLSA-Record - Let's Encrypt Zertifikat (HTTPS) ==== Nachfolgend soll auf Basis des TLSAGEN-Script der [*] sys4 AG der FINGERPRINT des eigentlichen Let's Encrypt-Zertifikats erstellt werden. Dazu soll der FINGERPRINT des eigentlichen Let's Encrypt-Zertifikats, welches hier im Verzeichnis * /opt/dehydrated-master/certs/tachtler.net/ liegt, verwendet werden. Nachfolgender Aufruf des einzeiligen Befehls sollte nachfolgende Ausgabe erzeugen: <code> # printf '_443._tcp.%s. IN TLSA 1 1 1 %s\n' tachtler.net $(openssl x509 -in /opt/dehydrated-master/certs/tachtler.net/cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 „%02x“') _443._tcp.tachtler.net. IN TLSA 1 1 1 adea18bbacb8a8f1370659bd3cc0a3a209bc27bfef82942c3ade758622ca0a5f </code> Parameter für den Aufruf: - Die DANE-EE(3) Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
1 1 1 - Die Domäne muss entsprechend angepasst werden, hier verwendet:
tachtler.net - Der Speicherort und der Dateiname des Zertifikats muss entsprechend angepasst werden. hier verwendet:
/opt/dehydrated-master/certs/tachtler.net/cert.pem Das Ergebnis ist der fertige TLSA-Record: <code> _443._tcp.tachtler.net. IN TLSA 1 1 1 adea18bbacb8a8f1370659bd3cc0a3a209bc27bfef82942c3ade758622ca0a5f </code> ==== TLSA-Record - Let's Encrypt Root CA Zertifikat (HTTPS) ==== Bevor mit der Erstellung des TLSA-Records aus dem Let's Encrypt-Root-Zertifikat der Let's Encrypt-CA begonnen werden soll, muss dieses erst einmal heruntergeladen werden, was mit nachfolgendem Befehl durchgeführt werden kann: :!: HINWEIS - Nachfolgende Links/URLs sind zum Zeitpunkt der Erstellung dieses Eintrags aktuell gewesen: * https://letsencrypt.org/certificates/ * https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt <code> # wget -P /tmp https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt –2018-08-29 09:05:17– https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt Resolving letsencrypt.org (letsencrypt.org)… 104.108.65.96, 2a02:26f0:7b:282::ce0, 2a02:26f0:7b:28c::ce0 Connecting to letsencrypt.org (letsencrypt.org)|104.108.65.96|:443… connected. HTTP request sent, awaiting response… 200 OK Length: 1647 (1.6K) [text/plain] Saving to: ‘/tmp/lets-encrypt-x3-cross-signed.pem.txt’ 100%[=====================================⇒] 1,647 –.-K/s in 0s 2018-08-29 09:05:18 (128 MB/s) - ‘/tmp/lets-encrypt-x3-cross-signed.pem.txt’ saved [1647/1647] </code> Ob das Herunterladen auch durchgeführt wurde, kann mit nachfolgendem Befehl überprüft werden: <code> # ls -la /tmp/lets-encrypt-x3-cross-signed.pem.txt -rw-r–r– 1 root root 1647 Jan 20 2018 /tmp/lets-encrypt-x3-cross-signed.pem.txt </code> Nachfolgend soll auf Basis des TLSAGEN-Script der [*] sys4 AG der FINGERPRINT des Let's Encrypt-Root–Zertifikats aus der Let's Encrypt-CA erstellt werden. Jetzt kann der FINGERPRINT des Let's Encrypt-Root–Zertifikats aus der Let's Encrypt-CA, welches hier im Verzeichnis * /tmp/ liegt, verwendet werden. Nachfolgender Aufruf des einzeiligen Befehls sollte nachfolgende Ausgabe erzeugen: <code> # printf '_443._tcp.%s. IN TLSA 2 1 1 %s\n' tachtler.net $(openssl x509 -in /tmp/lets-encrypt-x3-cross-signed.pem.txt -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 „%02x“') _443._tcp.tachtler.net. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 </code> Parameter für den Aufruf: - Die DANE-TA(2) Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
2 1 1 - Die Domäne muss entsprechend angepasst werden, hier verwendet:
tachtler.net - Der Speicherort und der Dateiname des Zertifikats muss entsprechend angepasst werden. hier verwendet:
/tmp/lets-encrypt-x3-cross-signed.pem.txt Das Ergebnis ist der fertige TLSA-Record: <code> _443._tcp.tachtler.net. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 </code> ===== Enrichtung DNS (HTTPS) ===== Nachfolgend wird dargestellt, wie die DNS-Records entsprechend im jeweiligen DNS-Server hinterlegt werden können: <code> _443._tcp.tachtler.net. 600 IN TLSA 1 1 1 adea18bbacb8a8f1370659bd3cc0a3a209bc27bfef82942c3ade758622ca0a5f _443._tcp.tachtler.net. 600 IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 _443._tcp.www.tachtler.net. 600 IN TLSA 1 1 1 adea18bbacb8a8f1370659bd3cc0a3a209bc27bfef82942c3ade758622ca0a5f _443._tcp.www.tachtler.net. 600 IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 </code> Ein Abfrage, mittels des Befehls dig, sollte dann wie nachfolgend dargestellt aussehen: <code> # dig _443._tcp.tachtler.net IN TLSA ; «» DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 «» _443._tcp.tachtler.net IN TLSA ;; global options: +cmd ;; Got answer: ;; →>HEADER«- opcode: QUERY, status: NOERROR, id: 30095 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_443._tcp.tachtler.net. IN TLSA ;; ANSWER SECTION: _443._tcp.tachtler.net. 600 IN TLSA 2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18 _443._tcp.tachtler.net. 600 IN TLSA 1 1 1 ADEA18BBACB8A8F1370659BD3CC0A3A209BC27BFEF82942C3ADE7586 22CA0A5F ;; AUTHORITY SECTION: tachtler.net. 10800 IN NS ns1.tachtler.net. ;; ADDITIONAL SECTION: ns1.tachtler.net. 10800 IN A 192.168.0.20 ;; Query time: 0 msec ;; SERVER: 192.168.0.20#53(192.168.0.20) ;; WHEN: Wed Aug 29 14:59:31 CEST 2018 ;; MSG SIZE rcvd: 184 </code> ===== Überprüfung (HTTPS) ===== Zur Überprüfung, ob die TLSA-Records auch korrekt gesetzt sind und auch zum jeweiligen, hier Webserver passen, kann nachfolgender externer Link verwendet werden: * https://de.ssl-tools.net/webservers/ https://de.ssl-tools.net/webservers/tachtler.net

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
tachtler/let_s_encrypt_-_tlsa-record_-_dane.1535548456.txt.gz · Zuletzt geändert: 2018/08/29 15:14 von klaus