SSL-Zertifikate von CAcert

This article is from 2014 and has been archived. It's old and probably outdated.

Meine Domains verwenden nun SSL-Zertifikate von CAcert. Zuvor wurde das Standard-Zertifikat meines Hosters für den Server verwendet, dies führte aufgrund des abweichenden Domain-Namens jedoch zwangsläufig zu Common-Name-Warnmeldungen. In meinem Standard-Browser hatte ich damals nach dem Umzug zu Uberspace die SSL-Warnung dauerhaft unterbunden, was zugegebenermaßen kurzsichtig war. Eine Fehler- oder Warnmeldung zu ignorieren behebt nunmal nicht das zugrundeliegende Problem. Dank eines Winks über Twitter wurde mir dies wieder gewahr und ich habe kurzerhand eigene Zertifikate erstellt. Eine Anleitung zur Integration eigener SSL-Zertifikate bei Uberspace findet man in deren Doku. Die Einrichtung der Wildcard-Zertifikate im Server durch den Support war bereits ein paar Stunden nach meiner Mail erledigt. Klasse! Montag Früh folgten noch die Hauptdomains ohne Wildcard, die ich übersehen hatte. Ich erhielt noch den Tipp mit dem x.509-Feature subjectAltName. Damit können *.domain.tld, domain.tld sowie bei Bedarf weitere Domains in einem Certificate Signing Request (CSR) untergebracht werden, mit einem einzigen Zertifikat als Ergebnis. Das werde ich bei der nächsten Erneuerung ausprobieren.

Browserunterstützung für CAcert

In vielen Browsern ist CAcert nicht als Zertifizierungsstelle hinterlegt, sodass beim Aufruf einer Website mit einem entsprechend ausgestellten Zertifikat eine Warnmeldung erscheint. Zur regulären Aufnahme in die Browser wird unter anderem eine teils jährliche Auditierung vorausgesetzt, die für den nichtkommerziellen gemeinnützigen Verein aus finanziellen Gründen keine Option ist. CAcert arbeitet jedoch seit einiger Zeit daran, den Richtlinien von Mozilla zur Aufnahme als Root-CA in deren Produkten nachzukommen.

Auf den Seiten von CAcert findet man Anleitungen zum Import des Root-Zertifikats für viele Browser und Plattformen. Über den Stand der Einbindung der CA kann man sich auf dieser Seite informieren.

Perfect Forward Secrecy

Der Server unterstützt aktuell TLS 1.2 mit Perfect Forward Secrecy (PFS) durch einen flüchtigen (Ephemeral) Diffie-Hellman Schlüsselaustausch (DHE), allerdings noch ohne elliptische Kurven (ECDHE), was wesentlich schneller wäre. Das E kennzeichnet PFS. Aufgezeichneter SSL-Netzwerkverkehr zu dieser Website kann somit nach Beendigung der Sitzung nicht mehr entschlüsselt werden, auch nicht mit dem privaten Schlüssel des Servers, denn bislang wurde noch kein effizienter Algorithmus gefunden, mit dem man das zugrundeliegende Diffie-Hellman-Problem lösen könnte.

Update 13.03.2014:

Testen per OpenSSL s_client

$ openssl s_client -connect blog.jotbe-fx.de:443 -servername blog.jotbe-fx.de

Die Angabe des Parameters -servername wird wegen der beim Hoster eingesetzten Server Name Indication (SNI) benötigt. SSL-Clients ohne Unterstützung für SNI erhalten das Standard-Zertifikat des Servers und damit wieder die ursprüngliche SSL-Warnung.

Mehr:

Jan Beilicke

About the author

Jan Beilicke is a long-time IT professional and full-time nerd. Open source enthusiast, advocating security and privacy. Sees the cloud as other people's computers. Find him on Mastodon.