Von nun an ausschliesslich verschlüsselt - Letsencrypt-Client unter Windows stellt für alle Domains oder Subdomains, die von Server-Daten-Kunden genutzt werden, Zertifikate bereit

27.05.2018 23:52:17, Jürgen Auer, keine Kommentare

So, gestern zuckte das noch gewaltig. Aber nun ist es tatsächlich so weit:

Kunden von Server-Daten, die ihre eigene Domain oder eine Subdomain per Nameserver-Eintrag auf Server-Daten zeigen lassen, um ihre Datenbank unter der Domainadresse nutzen zu können, machen das ab sofort ausschließlich verschlüsselt.

Das gab es - nicht allzu häufig. In dem Maße, in dem sich die Verschlüsselung im Internet ausbreitete und Browser immer heftigere Warnungen anzeigen, wenn ein Nutzer auf einer unverschlüsselten Seite etwas eingibt, wechselten Kunden lieber zur verschlüsselten Server-Daten - Subdomain. Bei der ein Sternzertifikat *.server-daten.de dafür sorgt, daß der Zugriff auf jede beliebige Subdomain verschlüsselt erfolgt.

Aber Ende 2015 gab es mit Letsencrypt

https://letsencrypt.org/

die Möglichkeit, kostenlose Zertifikate zu bekommen. Und - viel wichtiger: Diese über das ACME-Protokoll automatisch zu beantragen, die Inhaberschaft über die Domain nachzuweisen und ein Zertifikat herunterzuladen. ACME steht für "Automatic Certificate Management Environment".

https://de.wikipedia.org/wiki/Automatic_Certificate_Management_Environment

Die Inhaberschaft über die Domain wird nicht (wie beim manuellen Beantragen von Zertifikaten) darüber nachgewiesen, daß eine Mail an webmaster@example.com oder eine ähnliche Adresse geschickt wird und der Antragsteller auf diesen Link klickt. Stattdessen wird unter

/.well-known/acme-challenge/

eine Datei mit einem von Letsencrypt vorgegebenen zufälligen und sehr langen Namen angelegt, deren Inhalt ebenfalls vorgegeben ist. Diese Datei holt sich Letsencrypt, wenn man mitgeteilt hat, daß man die zugeordnete Challenge durch das Zur-Verfügung-Stellen dieser Datei (http-01-Challenge) erfüllt hat.

Die Version 1 hatte noch gewisse Einschränkungen. U.a. wurden noch keine Wildcard-Zertifikate unterstützt, wie hier eines für *.server-daten.de verwendet wird.

Die Version 2 unterstützt auch Wildcard-Zertifikate. Für die Version 2 gab es ab Januar eine Testmöglichkeit, seit Ende März 2018 ist das bei Letsencrypt auch auf dem Produktivsystem drauf.

Einen Client hatte ich größtenteils schon im Februar entwickelt. Im April und Anfang Mai gab es aber andere Arbeiten. Nun folgte der Rest. Der Client hat inzwischen den Vorteil, daß die Aktionen nach Position gehen und alle Ergebnisse in eine Datei geschrieben werden. Gibt es irgendwo einen Abbruch, wird der Status in der Datei genutzt, um den letzten Schritt zu wiederholen.

Über Letsencrypt laufen inzwischen mehr als die Hälfte aller aktiven Zertifikate.

Meine längerfristige Vermutung ist, daß der Markt für kostenpflichtige Zertifikate größtenteils zusammenbrechen wird. Technisch ist ein langer Schlüssel notwendig, so laufen auf Server-Daten nur Zertifikate mit RSA-Schlüsseln mit einer Länge von 4096 Bit. Aber ob ein Zertifikat domainvalidiert oder per Extended Validation abgesichert ist, spielt für die technische Sicherheit der Verschlüsselung keine Rolle. Damit dürften den allermeisten Nutzern domainvalidierte Zertifikate genügen.

Die beiden derzeit noch genutzten Zertifikate für die www.sql-und-xml.de und *.server-daten.de sind noch bis zum Spätsommer 2019 gültig. Mal sehen, ob ich bis dahin auch mit diesen beiden Zertifikaten umziehen werde.

Der letzte Schritt der Zertifikatszuordnung zur Bindung ist aktuell noch nicht automatisiert. Da muß ich erst noch austüfteln, wie das am besten erledigt werden kann.

Die merkwürdigen Probleme, die es gestern noch gegeben hatte, ließen sich inzwischen auch lösen.

Wenn man per RSACryptoServiceProvider-Objekt ein neues Schlüsselpaar erstellt, das man für die Erstellung eines CertificateRequest-Objekts benötigt und das man beim zurückgegebenen Zertifikat bsp. aus einer Datei lädt und dem privaten Schlüssel zuordnet, dann speichert Windows den privaten Schlüssel gleich in einem nur für diesen Nutzer gedachten Sicherheitsbereich ab. Damit hat dieser Nutzer einen privaten Schlüssel. Aber der ist nicht für Zertifikate unter "Webhosting" verwendbar.

Man kann das lösen, indem man nach der Erzeugung des CertificateRequest-Objekts und dessen Wegsenden zu Letsencrypt diesen privat gespeicherten privaten Schlüssel explizit löscht:

> _RSA_DomainKey.PersistKeyInCsp = False
> _RSA_DomainKey.Clear()

Wirkung: Das Problem mit dem "Reparieren-Müssen" per

> Certutil -repairstore Webhosting Zertifikatsfingerabdruck

entfiel damit. Beim Import wurde angezeigt, daß der private Schlüssel bekannt ist. Und dieser ließ sich auch exportieren.

Die "berüchtigte Fehlermeldung" tauchte allerdings weiterhin auf. Die kann man dadurch lösen, daß man das Zertifikat nach der Zuordnung des privaten Schlüssels mit

> _byteArray = _x509.Export(X509ContentType.Pfx, "meinSupergeheimesPasswort")
> Speichern des _byteArray in einen FileStream
> Laden per New X509Certificate2(FileName, "meinSupergeheimesPasswort", X509KeyStorageFlags.Exportable Or X509KeyStorageFlags.MachineKeySet Or X509KeyStorageFlags.PersistKeySet)

einmal ausspeichert und wieder lädt. Das Flag X509KeyStorageFlags.Exportable scheint dem Anhaken von

> Allow this certificate to be exported

beim manuellen Import zu entsprechen. Beide Schritte zusammengenommen sorgen dafür, daß ein grade neu von Letsencrypt bereitgestelltes Zertifikat so unter Webhosting abgelegt wird, daß es ohne Fehlermeldung einer Bindung zugeordnet werden kann.

Man soll zwar eigentlich kein hartcodiertes Passwort im Code nutzen. Das ist hier aber irrelevant, da man die gespeicherte Datei auch sofort löschen kann. Es geht nicht um einen "richtigen Export" (bsp. für eine Sicherung), sondern darum, daß man eine .pfx-Datei so wieder importieren und das Exportable-Flag setzen kann.

*
* (wird nicht angezeigt)
Die Erläuterungen zum Datenschutz habe ich gelesen und stimme diesen zu.