Let's Encrypt: kostenlose SSL-Zertifikate

[Frogman]

ACME Tiny: Python-basierter Client per Cronjob

Für all diejenigen, die auch ein wenig Spaß an mehr haben, ein kleiner Tipp: hier gibt es ACME Tiny, ein pythonbasiertes Skript, um Let's Encrypt-Zertifikate zu holen und zu installieren - was man dann per cron-Job auch automatisiert laufen lassen kann.
Ich für meinen Teil vertiefe mich gerade darin, das Skript noch ein wenig aufzubohren, um in regelmäßigen Abläufen nicht nur ein Zertifikat zu erneuern, sondern dabei auch immer schon einen zweiten Reserve-CSR zu erzeugen, der dann zusammen mit dem aktuellen Zertifikat gepinnt wird (vgl. Certificate Pinning). Im nächsten Durchlauf wird dann der Reserve-CSR vom letzten Durchlauf für den Let's Encrypt-Aufruf verwendet und ein neuer Reserve-CSR erzeugt - somit hat man vollautomatisiert immer ein aktuelles Zertifikat sowie einen Reserve-CSR, die beide per Pin gesichert sind.
Im Ergebnis könnte man das Ganze dann als Paket schnüren mit GUI, um die Häufigkeit und das Pinning optional auf DSM bzw. Webserver zu aktivieren.

 

[Nima]

Das wäre echt cool! Würdest du deine Lösung sharen, wenn das funktionieren sollte?
Ich habe es mit https://gethttpsforfree.com/ probiert bleibe aber bei verify owner hängen, da ich das Zertifikat für domain.de und www.domain.de brauche. Kann aber nur letzteres verifizieren lassen, da der webdienst nur Dateien und www bereit stellt und nicht unter Domain ohne www. Ein redirekt mit htaccess wird nicht akzeptiert.

 

[Frogman]

Mit der Domain an sich hast Du aktuell einen offenen Punkt. Üblicherweise wird die Erreichbarkeit eines privaten Servers, der keine feste öffentliche IPv4 besitzt, ja über einen CNAME-Record erreicht - diese ist allerdings weitgehend nur in Subdomains konfigurierbar. Die Domain an sich kannst Du also nicht einfach auf den heimischen Server leiten, so dass die Verification Challenge erfolgreich ist.
Das ACME-Protokoll erlaubt zudem aktuell (noch) keine Wildcard-Zertifikate, alle gewünschten Subdomains können allerdings über eine SAN-Liste gleichzeitig bearbeitet werden. Die Diskussion für den Wildcard-Support läuft allerdings schon in den Gremien, wenngleich das sicher nicht in Kürze entschieden wird.

 

[Nima]

Diese Einschränkung bezieht sich aber jetzt nur auf diese Methode, oder? Sonst nützt das ja nicht sonderlich viel.

 

[Frogman]

Es gibt diverse Clients und Plugins, die für die Validation verwendet werden können, und aktuell kommen immer noch neue hinzu, auch 3rdParty. Es geht gerade erst richtig los, da jetzt die öffentliche Beta gestartet ist.

 

[Nima]

Hier kann man einen SSL-Server-Test machen: https://www.ssllabs.com/ssltest/

 

[Nima]

So. Habe es nun ohne die DS mit gethttpsforfree.com gemacht. Hat auch alles funktioniert nur leider habe ich es nicht ganz verstanden!!!

1. Generate an account private key if you don't have one:
(KEEP ACCOUNT.KEY SECRET!)

Hier ist der öffentliche Schlüssel enthalten.

2. Generate a TLS private key if you don't have one:
(KEEP DOMAIN.KEY SECRET!)

Das ist der private Schlüssel.

3. If not done already, generate non-default dhparams.
openssl dhparam -out dhparam.pem 4096

4. Copy and paste both the below domain certificate and the below intermediate certificate into the same text file called "chained.pem".

Jetzt habe ich also 4 Dateien:
1 account.key
2 domain.key
3 chained.pem
4 dhparam.pem

Wozu sind diese gut? Ich habe jetzt domain.key und chained.pem importiert. Funktioniert auch. Aber wozu dieser dhparam.pem und der account.key, den man auch "secret" halten soll?

 

[Frogman]

Hier kann man einen SSL-Server-Test machen: https://www.ssllabs.com/ssltest/

Den kennen wir hier schon länger

 

[Frogman]

1. Generate an account private key if you don't have one:
(KEEP ACCOUNT.KEY SECRET!)

Hier ist der öffentliche Schlüssel enthalten.

Falsch - dieses Schlüsselpaar hat nichts mit dem späteren Serverzertifikat zu tun, sondern ist nur ein Key, der für eine Emailadresse/Domain registriert wird und mit dem Deine Nachrichten an den Zertifikatsserver von Let's Encrypt signiert werden.

2. Generate a TLS private key if you don't have one:
(KEEP DOMAIN.KEY SECRET!)

Das ist der private Schlüssel.

Das ist richtig - dieser domain.key ist Dein privater Schlüssel des eigentlichen Zertifikats. Die Datei enthält eigentlich zwei Schlüsselteile: einen privaten und einen öffentlichen. Dieser öffentliche Teil wird dann als CSR extrahiert und an Let's Encrypt zur Signierung geschickt.

4. Copy and paste both the below domain certificate and the below intermediate certificate into the same text file called "chained.pem".

Jetzt habe ich also 4 Dateien:
1 account.key
2 domain.key
3 chained.pem
4 dhparam.pem

Wozu sind diese gut? Ich habe jetzt domain.key und chained.pem importiert. Funktioniert auch. Aber wozu dieser dhparam.pem und der account.key, den man auch "secret" halten soll?

Dein Zertifikat für die DS besteht aus zwei Schlüsselhälften: einem privaten Schlüssel des domain.key und dem eigentlichen Serverzertifikat signed.crt (also der öffentlichen Hälfte des Schlüssels, der von Let's Encrypt über den CSR signiert wurde). Ähnlich wie StartCom setzt auch Let's Encrypt für die Signierung ein Intermediate-Zertifikat ein (standardmäßig das Let's Encrypt Authority X1), nicht ihr eigentliches Rootzertifikat. Die Intermediate-Zertifikate sind quersigniert von IdenTrust, die man in jedem aktuellen Betriebssystem unter den vertrauenswürdigen Root-CA findet.
In der DS musst Du dementsprechend neben dem Serverzertifikat signed.crt auch das Intermediate sowie den privaten Schlüssel domain.key importieren.
Die Endungen *.pem und *.crt müssen Dich nicht verwirren - wichtig ist das PEM-Format, in dem Schlüssel bzw. Zertifikat hier vorliegen müssen.

Für gewisse Anwendungen wird direkt eine chain.crt benötigt - d.h. eine Datei, die das öffentliche Serverzertifikat plus das Intermediate enthält.
Die dhparam.pem sind sogenannte Diffie-Hellmann-Parameter und werden für bestimmte Ciphren verwendet - immer wenn DH-Schlüsseltausch ohne Elliptische Kurven verwendet wird so wie zB. bei TLS_DHE_RSA_WITH_AES_256. Unter anderen bspw. beim OpenVPN-Server. Damit dann dort nicht Standardparameter verwendet werden (das sind Parameter mit 1024 bit), kann man dann diese Datei in den Ordner /volume1/@appstore/VPNCenter/etc/openvpn/keys/ kopieren und in der /var/packages/VPNCenter/etc/openvpn/openvpn.conf einbinden.

Den account.key sollte man auch geheim halten - wer diesen Schlüssel besitzt, kann damit natürlich genau wie Du Zertifikate von Let's Encrypt anfordern für Deine Domain.

 

[Nima]

Falsch - dieses Schlüsselpaar hat nichts mit dem späteren Serverzertifikat zu tun, sondern ist nur ein Key, der für eine Emailadresse/Domain registriert wird und mit dem Deine Nachrichten an den Zertifikatsserver von Let's Encrypt signiert werden.

Wieso?
openssl genrsa 4096 > account.key
openssl rsa -in account.key -pubout

Ergo: Public Key

Für gewisse Anwendungen wird direkt eine chain.crt benötigt - d.h. eine Datei, die das öffentliche Serverzertifikat plus das Intermediate enthält.

chained.pem enthält Signed Certificate UND Intermediate Certificate

Trotzdem bleibt's mir rätselhaft.
Ein einfacher public und private key hätten es mir (Laie) verständlicher gemacht.
Aber: es funktioniert ja!

 

[Frogman]

Wieso?
openssl genrsa 4096 > account.key
openssl rsa -in account.key -pubout

Ergo: Public Key

Eine asymmetrische Verschlüsselung funktioniert immer mit öffentlichem und privatem Schlüssel. Damit die Signatur Deiner Nachrichten an Let's Encrypt geprüft werden können, benötigen die den öffentlichen Teil des Schlüssels. Wie gesagt, hat mit dem eigentlichen Serverzertifikat nichts zu tun und dient nur der Kommunikation mit dem Signierserver.

chained.pem enthält Signed Certificate UND Intermediate Certificate

Was hab ich anderes geschrieben?

Für gewisse Anwendungen wird direkt eine chain.crt benötigt - d.h. eine Datei, die das öffentliche Serverzertifikat plus das Intermediate enthält.

 

[CptGambit]

Hallo

ich hab bei ifun.de einen beitrag über Lets Encrypt gelesen und da wird auch explizit ein eine URL erwähnt, die LE auf der Synology beschreibt.
http://linuxundich.de/gnu-linux/ssl-zertifikat-lets-encrypt-synology-nas/
Ich habs selbst noch nicht probiert, wollte es aber mal in den Ring werfen.

Wenn ich selbst mal bisschen Zeit hab, werd ich mal nach der Anleitung vorgehen.

 

[Frogman]

..., die LE auf der Synology beschreibt.

"LE auf der Synology" ist dann vielleicht missverständlich... dort wird auch - ähnlich wie etwas weiter oben bspw. von olli beschrieben - der LE-Client in einem separaten Linux im manuellen Modus betrieben und die Zertifikate anschließend in das DSM gespielt. Interessant wird LE ja besonders dadurch, dass man es vollautomatisiert betreiben kann - und dieses am besten direkt auf der DS, damit es bspw. auch für "Nicht-Virtualisierer" nutzbar wird.

 

[jahlives]

wenn man Pech hat werden alle Zertifikate nach diesem Wochenende "unvertrauenswürdig"
Denn das vorgeschriebene Audit liegt noch nicht vor und am Weekend läuft die 90-Tage Frist ab. 90-Tage nach Ausstellung des ersten Zertifikates muss ein komplettes Audit durchgeführt worden sein. Veröffentlicht werden kann es noch 30 Tage später, aber dieses Wochenende muss es abgeschlossen sein.
Sonst müsste das Intermediate Zertifikat bis zum Abschluss des Audits widerrufen werden, was zur Folge hätte, dass die Browser diesem und allen damit signierten Certs nicht mehr trauen dürften
http://www.heise.de/security/meldun...tifizierungsstelle-Let-s-Encrypt-3031849.html

 

[Frogman]

Mmh, der eigentliche Blogeintrag von Fefe ist deutlich entspannter - wobei die Kritik aus der Ecke eines etablierten Anbieters, der damit Geld verdient (und das ist die PSW Group ja) durchaus auch zu erwarten war...

 

[jahlives]

Mmh, der eigentliche Blogeintrag von Fefe ist deutlich entspannter

also wenn du damit den meinst: http://blog.fefe.de/?ts=a89f4ed6 kann ich dir nicht ganz folgen. So wie ich den lese stirbt der gute Mann nächstens an einem Herzkaspar, so wie der sich aufregt

 

[dil88]

Danke für den Link, da pocht jemandem definitiv zumindest die Halsschlagader sichtbar.

 

[Frogman]

...So wie ich den lese stirbt der gute Mann nächstens an einem Herzkaspar, so wie der sich aufregt

Naja, den Herzkasper hat er sicher - aber den hat er immer, wenn er anderem Code vertrauen und auf seinem Server installieren soll. Gerade Python hat es ihm nicht erst jetzt angetan, erst recht, wenn dazu ein kleiner Mini-Webserver kommt... Muss jeder wissen - aber wenn ich einem recht übersichtlichen OpenSource-Client (und da gibt's ja nun nicht nur welche auf Python-Basis) für das Herunterladen eines Zertifikats nicht vertraue, dann darf ich auch einem OpenSSL oder kommerziell eingesetztem Linux-Derivat kleiner Dosen nicht vertrauen

 

[jahlives]

mittlerweile hat man ja (vielleicht auf Grund dieser Kriitik) einen Webservice für letsEncrypt ins Leben gerufen (https://gethttpsforfree.com/). Ganz ehrlich habe ich auch so meine Probleme mit diesem ganzen Python Webserver Gedöns nur für ein SSL-Zertifikat

 

[magick]

Ich sag mal, für den ersten Wurf ist das Paket von letsencrypt ok, es erlaubt es selbst unbedarften sich so ein Zertifikat zusammenzubauen, was ja das Ziel der Aktion ist. Das das nicht auf Fefes handgelöppelten System läuft, oder ers nicht laufen lassen will, geschenkt. Die Aufregung ist ein bisschen künstlich. Ich denke wenn sich das Ganze verbreitet, wird es etwas schlankere Clients geben. Soll ja irgendwann auch mal automatisiert auf der DS laufen