Benutzer-Werkzeuge

Webseiten-Werkzeuge


tachtler:let_s_encrypt_-_tlsa-record_-_dane

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.

Weitere Informationen zum Einsatz von TLSA in Verwendung mit Let's Encrypt-Zertifikaten sind unter nachfolgendem externen Link verfügbar:

Grundlagen TLSA-Record

Der TLSA-Record ist wie folgt aufgebaut:

_[Port]._[Protokoll].[SUBDOMAIN].[DOMAIN].[TLD] [TTL] IN TLSA (DATEN = [Zahl] [Zahl] [Zahl] [HASH])

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:

([Zahl] [Zahl] [Zahl] [HASH])

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 !!!

:!: HINWEIS - Ein aktuell generiertes Zertifikat muss bereits vorhanden sein !!!

Nachfolgend wird in dieser Anleitung davon ausgegangen, dass ein

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:

# 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

Parameter für den Aufruf:

  1. Die DANE-EE(3) Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
    3 1 1
  2. Die Domäne muss entsprechend angepasst werden, hier verwendet:
    mx1.tachtler.net
  3. 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:

_25._tcp.mx1.tachtler.net. IN TLSA 3 1 1 e9bc354eaffcf2751f847a22fd6d021cb94a9a015e1d64f76673e41f9f0b8f88

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:

# 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]

Ob das Herunterladen auch durchgeführt wurde, kann mit nachfolgendem Befehl überprüft werden:

# 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

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:

# 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

Parameter für den Aufruf:

  1. Die DANE-TA(2) Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
    2 1 1
  2. Die Domäne muss entsprechend angepasst werden, hier verwendet:
    mx1.tachtler.net
  3. 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:

_25._tcp.mx1.tachtler.net. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

Enrichtung DNS (SMTP)

Nachfolgend wird dargestellt, wie die DNS-Records entsprechend im jeweiligen DNS-Server hinterlegt werden können:

_25._tcp.mx1.tachtler.net. 600  IN  TLSA  3 1 1 e9bc354eaffcf2751f847a22fd6d021cb94a9a015e1d64f76673e41f9f0b8f88
_25._tcp.mx1.tachtler.net. 600  IN  TLSA  2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

Ein Abfrage, mittels des Befehls dig, sollte dann wie nachfolgend dargestellt aussehen:

# 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

Ü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:

oder

oder

 https://dane.sys4.de/

Generierung TLSA-Records (IMAP)

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 (IMAP)

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-dovecot/certs/imap.tachtler.net/

liegt, verwendet werden.

Nachfolgender Aufruf des einzeiligen Befehls sollte nachfolgende Ausgabe erzeugen:

# printf '_993._tcp.%s. IN TLSA 3 1 1 %s\n' imap.tachtler.net $(openssl x509 -in /opt/dehydrated-master-dovecot/certs/imap.tachtler.net/cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"')
_993._tcp.imap.tachtler.net. IN TLSA 3 1 1 2192f81a9bcc98e86158a261470a83c6cbbd878ebf47993696ab5d30df13789f
und
# printf '_143._tcp.%s. IN TLSA 3 1 1 %s\n' imap.tachtler.net $(openssl x509 -in /opt/dehydrated-master-dovecot/certs/imap.tachtler.net/cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | hexdump -ve '/1 "%02x"')
_143._tcp.imap.tachtler.net. IN TLSA 3 1 1 2192f81a9bcc98e86158a261470a83c6cbbd878ebf47993696ab5d30df13789f

Parameter für den Aufruf:

  1. Die DANE-EE(3) Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
    3 1 1
  2. Die Domäne muss entsprechend angepasst werden, hier verwendet:
    imap.tachtler.net
  3. Der Speicherort und der Dateiname des Zertifikats muss entsprechend angepasst werden. hier verwendet:
    /opt/dehydrated-master-dovecot/certs/imap.tachtler.net/cert.pem

Das Ergebnis sind die fertigen TLSA-Records:

_143._tcp.imap.tachtler.net. IN TLSA 3 1 1 2192f81a9bcc98e86158a261470a83c6cbbd878ebf47993696ab5d30df13789f
_993._tcp.imap.tachtler.net. IN TLSA 3 1 1 2192f81a9bcc98e86158a261470a83c6cbbd878ebf47993696ab5d30df13789f

TLSA-Record - Let's Encrypt Root CA Zertifikat (IMAP)

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:

# 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]

Ob das Herunterladen auch durchgeführt wurde, kann mit nachfolgendem Befehl überprüft werden:

# 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

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:

# printf '_993._tcp.%s. IN TLSA 2 1 1 %s\n' imap.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"')
_993._tcp.imap.tachtler.net. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
und
# printf '_143._tcp.%s. IN TLSA 2 1 1 %s\n' imap.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"')
_143._tcp.imap.tachtler.net. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

Parameter für den Aufruf:

  1. Die DANE-TA(2) Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
    2 1 1
  2. Die Domäne muss entsprechend angepasst werden, hier verwendet:
    mx1.tachtler.net
  3. Der Speicherort und der Dateiname des Zertifikats muss entsprechend angepasst werden. hier verwendet:
    /tmp/lets-encrypt-x3-cross-signed.pem.txt

Das Ergebnis sind die fertigen TLSA-Records:

_143._tcp.imap.tachtler.net. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
_993._tcp.imap.tachtler.net. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

Enrichtung DNS (IMAP)

Nachfolgend wird dargestellt, wie die DNS-Records entsprechend im jeweiligen DNS-Server hinterlegt werden können:

_993._tcp.imap.tachtler.net. 600  IN  TLSA  3 1 1 2192f81a9bcc98e86158a261470a83c6cbbd878ebf47993696ab5d30df13789f
_993._tcp.imap.tachtler.net. 600  IN  TLSA  2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
und
_143._tcp.imap.tachtler.net. 600  IN  TLSA  3 1 1 2192f81a9bcc98e86158a261470a83c6cbbd878ebf47993696ab5d30df13789f
_143._tcp.imap.tachtler.net. 600  IN  TLSA  2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

Ein Abfrage, mittels des Befehls dig, sollte dann wie nachfolgend dargestellt aussehen:

# dig _993._tcp.imap.tachtler.net IN TLSA

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> _993._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:
_993._tcp.imap.tachtler.net. 600  IN TLSA 3 1 1 2192F81A9BCC98E86158A261470A83C6CBBD878EBF47993696AB5D30 DF13789F
_993._tcp.imap.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: Sat Sep 01 06:29:49 CEST 2018
;; MSG SIZE  rcvd: 142
und

Ein Abfrage, mittels des Befehls dig, sollte dann wie nachfolgend dargestellt aussehen:

# dig _143._tcp.imap.tachtler.net IN TLSA

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> _143._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:
_143._tcp.imap.tachtler.net. 600  IN TLSA 3 1 1 2192F81A9BCC98E86158A261470A83C6CBBD878EBF47993696AB5D30 DF13789F
_143._tcp.imap.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: Sat Sep 01 06:30:45 CEST 2018
;; MSG SIZE  rcvd: 142

Überprüfung (IMAP)

Zur Überprüfung, ob die TLSA-Records auch korrekt gesetzt sind und auch zum jeweiligen, hier MDA passen, kann nachfolgender externer Link verwendet werden:

https://www.huque.com/bin/danecheck - imap.tachtler.net und https://www.huque.com/bin/danecheck - imap.tachtler.net - STARTTLS

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:

# 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

Parameter für den Aufruf:

  1. Die PKIX-EE: Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
    1 1 1
  2. Die Domäne muss entsprechend angepasst werden, hier verwendet:
    tachtler.net
  3. 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:

_443._tcp.tachtler.net. IN TLSA 1 1 1 adea18bbacb8a8f1370659bd3cc0a3a209bc27bfef82942c3ade758622ca0a5f

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:

# 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]

Ob das Herunterladen auch durchgeführt wurde, kann mit nachfolgendem Befehl überprüft werden:

# 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

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:

# 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

Parameter für den Aufruf:

  1. Die DANE-TA(2) Zertifikats-Nutzung muss entsprechend gesetzt sein, hier verwendet:
    2 1 1
  2. Die Domäne muss entsprechend angepasst werden, hier verwendet:
    tachtler.net
  3. 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:

_443._tcp.tachtler.net. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

Enrichtung DNS (HTTPS)

Nachfolgend wird dargestellt, wie die DNS-Records entsprechend im jeweiligen DNS-Server hinterlegt werden können:

_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

Ein Abfrage, mittels des Befehls dig, sollte dann wie nachfolgend dargestellt aussehen:

# 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

Ü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:

oder

https://de.ssl-tools.net/webservers/tachtler.net

Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
tachtler/let_s_encrypt_-_tlsa-record_-_dane.txt · Zuletzt geändert: 2018/09/01 07:04 von klaus