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:
- MF-dnssec-tlsa_validator-2.1.1-freebsd-x64.xpi für Firefox auf FreeBSD 10
- CR-dnssec_validator-2.1.1-freebsd-x64.tar.gz für Chrome auf FreeBSD 10
- CR-tlsa_validator-2.1.1-freebsd-x64.tar.gz für Chrome auf FreeBSD 10
- OP-dnssec_validator-2.1.1-freebsd-x64.tar.gz für Opera auf FreeBSD 10
- OP-tlsa_validator-2.1.1-freebsd-x64.tar.gz für Opera auf FreeBSD 10
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.
Wer selbst spielen will startet hier: https://www.huque.com/bin/gen_tlsa
1 Kommentare