DANE mit eigener CA

Der Artikel hier hat ein geplantes Veröffentlichungsdatum vom März diesen Jahres, die ersten Entwürfe sind schon zwei Jahre als. Zur Sache: DNSSEC mache ich ja schon länger. Und über Zertifikate im DNS habe ich auch schon vor Jahren nachgedacht. Nun wird es endlich real.

Für das ICANN Meeting 2009 in Mexiko hatte ich zur Nutzung von DNSSEC als Ersatz für Zertifikatsinstanzen referiert. Allerdings bin ich mit vernichtender Kritik untergegangen. Also lag es auf Halde.

Im Laufe der Jahre hat die CA-Industrie sich einen Fehler nach dem anderen geleistet und so viel Vertrauen verspielt, daß es inzwischen sinnvoller erschien, lieber den Registrar-Strukturen des DNS zu vertrauen. Bis dato war man davon ausgegangen, daß die Beteiligten am DNS nicht in der Lage seien, die hohen Anforderungen zu erfüllen. Schließlich stellen Zertifikate die Grundlage für Verträge dar, indem die CA dafür haftet, eine ladungsfähige Adresse des Gegenübers bereitzustellen.

Indem man Zertifikate und DNS Delegation in die gleichen Hände gibt, wirkt sich jeder Fehler im DNS fatal auf die Zertifikatsstrukturen aus. Deswegen hatte der ursprüngliche Vorschlag zu TLSA nur die Abwehr von CA-Fehlern im Sinne: Man sollte erkennen können, wenn die vorgelegte Zertifikatskette von unzulässigen CAs oder für die falschen Schlüssel ausgestellt wurde.

Bei mir liegt der Fall aber anders. Wir haben hier eine CA, die nicht in den gängigen Browsern vorinstalliert ist. Man müßte also in den TLSA Angaben das komplette CA-Zertifikat hinterlegen und das als Trust-Anchor deklarieren. Damit könnte dann jemand extern die Zertifikate prüfen.

Ich möchte nur die CA bekannt geben, habe aber nicht die Möglichkeit, das Zertifikat komplett anzugeben. Durch das jährliche CA-Key-Rollover gibt es aber mehrere verwendete CA-Schlüssel: Die aktuelle Root-CA als Wurzel und die durch die des Vorjahres crosszertifizierte gleiche CA. Was aber konstant bleibt, ist das Paar aus Subject und Key.

Nachdem ich das ganze Spiel durchgeführt habe, sieht die DNS Struktur so aus:

_443._tcp.lutz.donnerhacke.de. CNAME ca.iks-jena.de.
ca.iks-jena.de.         CNAME   2014.ca.iks-jena.de.
2014.ca.iks-jena.de.    TLSA  2 1 0 30820...

Im Test https://www.had-pilot.com/dane/danelaw.html klappte es allerdings nicht.

Der Grund war allerdings simpel: Das Testtool vergleicht den kompletten Subject-String "/C=DE/L=Jena...." aus dem Zertifikat mit dem DNS Namen ... und scheitert.

Nach dem Einfügen eines SubjectAltName in das Zertifikat ist nun auch das Tool glücklich:

Getting URL: https://lutz.donnerhacke.de
Here is the Full Server Cert List 1 gnucall: certs in chain: 1
End Cert Common Name: CN=CA der IKS Service GmbH (SIGN) 2014/emailAddr...
End Cert SubjectAltName: DNS:lutz.donnerhacke.de
Target Domain Name: lutz.donnerhacke.de
Exact Match: Chain Length = 1
DNS Result = NOERROR, DNSSEC = DNSSEC Validated Response (Flags = qr r...
Server Name Indication: SubjectAltName matches target domain: lutz.don
TLSA Values: cu=2, sel=1, mt=0
depth=1 verify=1 err=0 subject=/C=DE/ST=Thuringia/L=Jena/O=IKS Service...
depth=0 verify=1 err=0 subject=/C=DE/ST=Thuringa/L=Jena/O=Lutz Donnerh...

Certificate Verification Status: (0) OK
tlsa=
30820122300D06092A864886F70D01010105000382010F003082010A0282010100CBBC...
Public Key of Verifying Root Cert from TLS handshake is:
30820122300D06092A864886F70D01010105000382010F003082010A0282010100CBBC...
DANE Matched.
lutz.donnerhacke.de authenticated.

Wunderbar.

Bleibt noch der Test mit dem Browser.

Unglücklicherweise gibt es das Plugin für den Firefox nicht für mein aktuellen Betriebssystem: FreeBSD. Deswegen habe ich es mir mal aus den Quellen gebaut:

Was allerdings noch nicht klappt, ist meine Seite damit zu validieren.

Einen Tag später

Nach dem Ausdruck meines Leidens auf der Mailingliste des Validator-Plugins bekam ich den Hinweis, daß der Client ja nur ein Bruchstück des CA-Keys habe.

Dies reiche zwar theoretisch zur Validierung aus, was ein Test zeigt. Ein anderer Test scheitert dagegen grandios. Ebenso auch das Plugin.

Der Trick besteht darin, den CA Key auch mitzuliefern.

SSLCertificateChainFile /etc/httpd/ssl/iksca.2014

Und nun sind beide Tests "grün". Wie schön.

Das Plugin selbst ist aber noch nicht in der Lage zu validieren. Das geht erst in einer Developer-Version.

Mal schauen, was sich da noch drehen läßt.

Avatar
Lutz Donnerhacke 28.08.2014 14:33
Und nun geht auch das Validator-Plugin korrekt, nachdem ich ihm zusätzlich einen Hash zur Authenisierung vorwerfe.
Wer selbst spielen will startet hier: https://www.huque.com/bin/gen_tlsa

1 Kommentare

Post a comment

Verwandter Inhalt