Neue SSL-Zertifikate

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
Aus gegebenem Anlass habe ich die SSL-Zertifikate neu generiert. Es gibt daher neue Fingerprints:
Code: 
www.bsdforen.de:
SHA-256: 37 90 01 D2 9E C5 B9 F5 6F BD 4E 5A F4 E7 DD A8 E2 0F 3E 63 12 BC 96 FF 5F CB BC 39 D7 8A 16 3F
SHA-1: 7B B0 05 3F 50 7C DC AA CE F6 13 E8 1F 1B E5 45 9D 50 25 86

wiki.bsdforen.de:
SHA-256: 41 8C 7F 63 44 1C 7A 26 30 A6 27 8C 4C D3 18 07 FC 04 9D 73 71 7D F0 EB 0F B7 77 5C EE D7 7F 81
SHA-1: B7 BD BF 4F 99 46 20 E3 37 94 7F 0B D5 70 5D 92 81 C7 D8 34

Sie werden später wie immer auf Twitter veröffentlicht werden.
 
Wäre es vielleicht auch möglich öffentlich signierte zu nutzen? Sowas gibts bei startssl kostenlos...
 
KobRheTilla schrieb:
Und du vertraust StartSSL mehr als dir selbst?

Rob
Zum Vergrößern anklicken....
Wem ich vertraue ist egal, es geht um den Browser. Standard-Browser erlauben garnicht mehr ohne weiteres manuelle Ausnahmen hinzuzufügen. Und wenn man nicht jedes Mal das selber überprüfen will, dann bringt einem ein self-signed cert nichts.
 
h^2 schrieb:
Wem ich vertraue ist egal, es geht um den Browser. Standard-Browser erlauben garnicht mehr ohne weiteres manuelle Ausnahmen hinzuzufügen. Und wenn man nicht jedes Mal das selber überprüfen will, dann bringt einem ein self-signed cert nichts.
Zum Vergrößern anklicken....

Ist StartSSL denn bei den gängigen Browsern als CA hinterlegt?
 
Ich verwende StartSSL-Zertifikate und hatte (zumindest bisher) noch keinen Browser der sie angemahnt hätte.
 
Kith und ich haben schon darüber gesprochen. Wir werden allerdings noch einige Wochen warten, bis wirklich klar ist, ob die Zertifikate tatsächlich nur 30 Tage gültig sind und bis die Kritik am (per Cronjob reinzutüddelnden) Client entweder angegangen oder widerlegt wurde.
 
Die Zertifikate sind tatsächlich nur 90 Tage gültig. Danach muss mit dem Client ein neues Zertifkat erstellt werden, am besten hinterlegt man einen Webserver Alias von domain.tld/.well-known/ nach /tmp/irgendwas. Man kann den Client dann anweisen, diesen Pfad zu nutzen um eine Datei abzulegen die der Letsencrypt Server dann abruft um zu prüfen, dass dir die Domain auch tatsächlich dir gehört. Die Zertifikate werden immer in den selben Pfad verlinkt, sodass die Webserver Konfiguration nicht angepasst werden braucht. Soweit ich das sehen kann wird das alte Zertifikat für ungültig erklärt, sobald man sich ein neues ausstellen lässt. Der Client lässt sich ganz gut verscripten - schön ist anders aber so schlimm wie er momentan allerorten gemacht wird ist er auch wieder nicht :-)
 
Schau dir acme_tiny.py an. Das ist für mich das praktikabelste. Den offiziellen Client kann man in die Tonne treten.

Edit: Das erfordert allerdings, dass du deine Keys und .csr selbst generierst. So sollte es aber auch sein. Das kleine Script braucht nur Lesezugriff auf den .csr und Schreibzugriff auf ein Verzeichnis, das man auf /.well-known/acme-challenge mappt.
 
Wow, das war aber ne schwere Geburt mit lighttpd :eek: Immerhin, jetzt habe ich A bei ssllabs.com
 
Vielleicht mal meine Erfahrung zu Let's Encrypt:

Ich habe jetzt mal auf meinem Server den Kram in einer Jail installiert. Geholfen hat mir dabei der Beitrag, den ich per Google gefunden habe: http://savagedlight.me/2015/11/24/lets-encrypt-on-a-freebsd-nginx-reverse-proxy/
Ich nutze halt einen Reverseproxy und finde das auch überaus praktisch :D Naja, ich habe LetsEncrypt in einer separaten Jail installiert, weil die Abhängigkeitenliste des offiziellen Clients doch schon ziemlich lang ist. Python 2.7 und ein Rattenschwanz an Python-Modulen.

Der Client legt dann die Zertifikate nach /usr/local/etc/letsencrypt/live/<domain>. Diesen letsencrypt-Ordner habe ich dann mittels nullfs in die Reverseproxy Jail eingebunden. Dann nur noch die Pfade in der nginx Config anpassen und alles funktioniert.

Was mir aufgefallen ist:
- Wenn man Zertifikate haben will, braucht es gerne mal so 4-5 Versuche. Er bricht schon sehr oft mit einer Fehlermeldung ab. Steht auch schon in deren Issue-Tracker: https://github.com/letsencrypt/boulder/issues/1217

- Jeder Aufruf liefert einem _ein_ Zertifikat. D.h. letsencrypt ... -d <domain> -d www.<domain> -d sub.<domain> holt _ein_ Zertifikat für alle angegebenen (Sub-)Domains. D.h. rufe ich das pro (Sub-)Domain auf, dann kriege ich auch pro Subdomain Zertifikate.

- wie oben schon zu entnehmen ist, ein Zertifikat für domain.org ist nicht gültig für www.domain.org. Man muss beides angeben. Kann sein, dass das total logisch ist, aber der Zertifikatskram ist schon recht unübersichtlich :D

- hat man ein Zertifikat für domain.org beantragt, dann kann man problemlos das Zertifikat auf sub.domain.org erweitern lassen.

Ansonsten gibt's nichts weiter zu meckern, von meiner Seite aus. Die Zertifikate sind 90 Tage gültig und können aber zu einem beliebigen Zeitpunkt erneuert werden. Empfohlen wird alle 60 Tage, damit noch Zeit ist einzugreifen, wenn der Cronjob mal nicht will oder es wie oben erwähnt mal Schwierigkeiten gibt
 
Hallo @-Nuke- , danke für Deine Erfahrungen. Meine sehen ähnlich aus. Auch wenn viel gemeckert wird über den letsencrypt-Client, bin ich mit dem Ergebnis zufrieden. Zertifikats-Erneuerung klappte bisher reibungslos und mir gefällt, dass die alten Zertifikate gespeichert bleiben - falls mal was schief geht, kann man zurück (vorausgesetzt das alte ist noch nicht abgelaufen).

Die vielen Abhängigkeiten haben mir ebenfalls nicht gefallen - aber die Nullfs-Lösung mag ich auch nicht so sehr. Ein anderer Weg könnte ein Cron-Job auf dem Host-System system sein: Der könnte zunächst in der letsencrypt-Jail das neue Zertifikat generieren und dieses dann - bei Erfolg - an die eigentlich benötigte Stelle kopieren.

Ich will demnächst auf einem Test-System einmal das simplerere letsencrypt.sh von Lukas Schauer ausprobieren. Den Hinweis darauf hatte ich bei calomel.org gesehen. Ist allerdings Bash.

Welches Letsencrypt-Verfahren hast Du eigentlich genutzt: Webroot kommt ja wohl nicht in Frage, wenn Dein Webserver in einer anderen Jail läuft als Dein Letsencrypt?
 
-Nuke- schrieb:
- Wenn man Zertifikate haben will, braucht es gerne mal so 4-5 Versuche. Er bricht schon sehr oft mit einer Fehlermeldung ab.
Zum Vergrößern anklicken....

Also sowas in Verbindung damit, dass er bei jedem Start sich und die kompletten Abhängigkeiten aktualisiert, machen den offiziellen Client für mich absolut untauglich. Das mag für Leute OK sein, die wirklich absolut keine Ahnung haben, aber jeder halbwegs fitte Admin scriptet sich doch da was mit acme_tiny.py o.ä. und ordentlicher Zugriffskontrolle zusammen. Bei mir hat z.B. kein fremdes Script Zugriff auf private keys, und auf den ACME-Account-Key hat auch nur acme_tiny.py Zugriff.

Shotgun-style einfach so oft starten, bis es durchläuft, WTF? Das hätte genau andersrum sein müssen, vom Projekt kommt ein minimaler Client, der das API bedient, und alles darüber hinaus wird von Dritten bereitgestellt.

Bei mir sieht die selbstgebastelte Struktur z.B. so aus, wobei der Zugriff auf die Zertifikate auch nicht direkt erfolgt, sondern das Script diese extern "wegbundlet", damit ich nicht die chain certs doppelt und dreifach rumliegen habe. Das Script läuft als Benutzer certmgmt, acme_tiny.py läuft als Benutzer acme.

Code: 
$ id acme
uid=10004(acme) gid=10004(acme) groups=10004(acme), 10005(certmgmt)
$ id certmgmt
uid=10005(certmgmt) gid=10005(certmgmt) groups=10005(certmgmt)

Code: 
drwxr-x---  4 root      certmgmt   512 Jan 14 02:14 /etc/ssl/le
-r--r-----  1 root      acme      3243 Dec  5 20:48 /etc/ssl/le/account.pem
-r--------  1 root      wheel     3243 Dec  5 20:48 /etc/ssl/le/account.pem.bak
-rwxr-x---  1 root      certmgmt  4523 Jan 14 02:28 /etc/ssl/le/certs.sh
-rw-r-----  1 root      certmgmt   769 Dec 25 00:21 /etc/ssl/le/dh4096.pem
drwxr-x---  4 certmgmt  certmgmt   512 Dec 29 01:33 /etc/ssl/le/domains
drwxr-x---  6 certmgmt  certmgmt   512 Jan 27 08:52 /etc/ssl/le/domains/[...]
drwxr-x---  2 certmgmt  certmgmt   512 Dec 31 07:09 /etc/ssl/le/domains/[...]/20151231-070445
-r--r-----  1 certmgmt  certmgmt  1594 Dec 31 07:04 /etc/ssl/le/domains/[...]/20151231-070445/csr.pem
-r--------  1 certmgmt  certmgmt  3243 Dec 31 07:04 /etc/ssl/le/domains/[...]/20151231-070445/privkey.pem
drwxr-x---  2 certmgmt  certmgmt   512 Dec 31 07:11 /etc/ssl/le/domains/[...]/20151231-071001
-rw-------  1 certmgmt  certmgmt  2151 Dec 31 07:10 /etc/ssl/le/domains/[...]/20151231-071001/cert.pem
-r--r-----  1 certmgmt  certmgmt  1594 Dec 31 07:10 /etc/ssl/le/domains/[...]/20151231-071001/csr.pem
-r--------  1 certmgmt  certmgmt  3243 Dec 31 07:10 /etc/ssl/le/domains/[...]/20151231-071001/privkey.pem
lrwxr-xr-x  1 certmgmt  certmgmt    24 Jan 10 12:48 /etc/ssl/le/domains/[...]/cert.pem -> 20151231-071001/cert.pem
lrw-------  1 certmgmt  certmgmt    24 Jan 27 08:52 /etc/ssl/le/domains/[...]/ocsp.der -> ocsp_20160127-085219.der
-rw-------  1 certmgmt  certmgmt   532 Dec 31 07:19 /etc/ssl/le/domains/[...]/ocsp_20151231-071934.der
-rw-------  1 certmgmt  certmgmt   532 Jan  7 16:24 /etc/ssl/le/domains/[...]/ocsp_20160107-162401.der
-rw-------  1 certmgmt  certmgmt   532 Jan  8 12:53 /etc/ssl/le/domains/[...]/ocsp_20160108-125347.der
-rw-------  1 certmgmt  certmgmt   532 Jan 10 12:34 /etc/ssl/le/domains/[...]/ocsp_20160110-123437.der
-rw-------  1 certmgmt  certmgmt   532 Jan 10 12:49 /etc/ssl/le/domains/[...]/ocsp_20160110-124924.der
-rw-------  1 certmgmt  certmgmt   532 Jan 12 20:10 /etc/ssl/le/domains/[...]/ocsp_20160112-201003.der
-rw-------  1 certmgmt  certmgmt   532 Jan 17 16:16 /etc/ssl/le/domains/[...]/ocsp_20160117-161626.der
-rw-------  1 certmgmt  certmgmt   532 Jan 21 23:36 /etc/ssl/le/domains/[...]/ocsp_20160121-233625.der
-rw-------  1 certmgmt  certmgmt   532 Jan 27 08:52 /etc/ssl/le/domains/[...]/ocsp_20160127-085219.der
lrwxr-xr-x  1 certmgmt  certmgmt    27 Jan 10 12:48 /etc/ssl/le/domains/[...]/privkey.pem -> 20151231-071001/privkey.pem
drwxr-x---  4 certmgmt  certmgmt   512 Jan 27 08:52 /etc/ssl/le/domains/[...]
drwxr-x---  2 certmgmt  certmgmt   512 Dec 25 20:08 /etc/ssl/le/domains/[...]/20151225-200841
-r--------  1 certmgmt  certmgmt  2147 Dec 25 20:08 /etc/ssl/le/domains/[...]/20151225-200841/cert.pem
-r--r-----  1 certmgmt  certmgmt  1594 Dec 25 20:08 /etc/ssl/le/domains/[...]/20151225-200841/csr.pem
-r--------  1 certmgmt  certmgmt  3243 Dec 25 20:08 /etc/ssl/le/domains/[...]/20151225-200841/privkey.pem
lrw-------  1 certmgmt  certmgmt    24 Dec 25 20:08 /etc/ssl/le/domains/[...]/cert.pem -> 20151225-200841/cert.pem
lrw-------  1 certmgmt  certmgmt    24 Jan 27 08:52 /etc/ssl/le/domains/[...]/ocsp.der -> ocsp_20160127-085219.der
-rw-------  1 certmgmt  certmgmt   532 Dec 31 07:19 /etc/ssl/le/domains/[...]/ocsp_20151231-071934.der
-rw-------  1 certmgmt  certmgmt   532 Jan  3 00:21 /etc/ssl/le/domains/[...]/ocsp_20160103-002148.der
-rw-------  1 certmgmt  certmgmt   532 Jan  7 16:24 /etc/ssl/le/domains/[...]/ocsp_20160107-162401.der
-rw-------  1 certmgmt  certmgmt   532 Jan 11 02:30 /etc/ssl/le/domains/[...]/ocsp_20160111-023056.der
-rw-------  1 certmgmt  certmgmt   532 Jan 15 19:34 /etc/ssl/le/domains/[...]/ocsp_20160115-193416.der
-rw-------  1 certmgmt  certmgmt   532 Jan 19 04:06 /etc/ssl/le/domains/[...]/ocsp_20160119-040627.der
-rw-------  1 certmgmt  certmgmt   532 Jan 27 08:52 /etc/ssl/le/domains/[...]/ocsp_20160127-085219.der
lrw-------  1 certmgmt  certmgmt    27 Dec 25 20:08 /etc/ssl/le/domains/[...]/privkey.pem -> 20151225-200841/privkey.pem
-rwxr-x---  1 root      certmgmt   172 Jan 10 12:28 /etc/ssl/le/hpkp.sh
-rw-r-----  1 root      certmgmt  1967 Jan 10 11:03 /etc/ssl/le/isrgrootx1.pem
-rw-r-----  1 root      certmgmt  1675 Dec 23 16:58 /etc/ssl/le/lets-encrypt-x1-cross-signed.pem
-rw-r-----  1 root      certmgmt  1675 Dec 23 16:58 /etc/ssl/le/lets-encrypt-x2-cross-signed.pem
-rw-r-----  1 root      certmgmt  2015 Jan 10 10:42 /etc/ssl/le/letsencryptauthorityx1.pem
-rw-r-----  1 root      certmgmt  2014 Jan 10 10:42 /etc/ssl/le/letsencryptauthorityx2.pem
-rwxr-x---  1 root      acme        73 Jan  1 09:12 /etc/ssl/le/rm.sh
drwx------  2 certmgmt  certmgmt   512 Jan 27 08:52 /etc/ssl/le/tmp

So o.ä. hätte ich das per default erwartet und nicht, dass der Client in den Webserver-Configs rummalen will und man sich da ein selbstaktualisierendes Monster auf produktive Systeme ziehen soll.
 
@SolarCatcher
Ich habe die Parameter so gewählt wie es in der Anleitung steht. Also Webroot. Dazu müsste ich vielleicht noch mal meine Config erklären.

Ich habe eine Jail mit einem nginx-Reverseproxy. Mittels pf leite ich alle Anfragen an Port 80 und 443 zu dieser Jail um. In dieser Jail läuft ein nginx mit Reverseproxy-Config, welcher die Anfragen je nach Domain wieder auf andere Jails verteilt (je nachdem wem die Domain gehört muss sie in die entsprechende Jail des Nutzers). Und eben Port 80 mit der entsprechenden URL letsencrypt URL landet dann eben beim nginx in der LetsEncrypt Jail. D.h. letsencrypt kriegt gar nicht mit, dass er da vorher durch ne andere Jail gewandert ist.

Dauerndes hin- und herkopieren wäre mir zu lästig. So muss ich per Skript am Ende gar nichts tun. Per nullfs ist ja alles aktuell.
 
@TCM

Zu den Fehlern muss man aber auch sagen, dass nicht umsonst gesagt wird, dass es gerade noch BETA ist.

Und ja, es gibt ja durchaus weitere Möglichkeiten sich den Kram zu holen. LetsEncrypt soll ja nichts "nur für fitte Admins" sein, sondern es möglichst einfach gestalten, auch für den weniger fitten der sich seine Apache-Config zusammengooglet. Mir ist das im Endeffekt egal. LetsEncrypt hat sein eigenes Universum in der Jail und ich hole mir das raus was ich brauche.
 
Stichwort reverse proxy: Da kann ich HAProxy nur wärmstens empfehlen, falls der noch nicht bekannt ist. Damit kann man z.B. so Spielereien machen wie: 1) SSH und TLS (und ggf. noch OpenVPN) gemischt auf Port 443 2) TLS je nach SNI entweder direkt terminieren und Klartext-HTTP an die Webserver leiten oder 3) TLS je nach SNI direkt "roh" an Webserver leiten, die das selbst terminieren, wodurch man z.B. auch die TLSSNI-Challenge von ACME bedienen kann. 4) Unbekannte SNI komplett droppen, so dass der Client nicht ein Byte gesendet kriegt.

Edit: Und schlank isser
Code: 
_haproxy 17905  0.0  0.9  6208  2216 ??  Ss     8:52AM    0:00.05 /usr/local/sbin/haproxy -f /etc/haproxy/haproxy.cfg -sf 13984
 
-Nuke- schrieb:
LetsEncrypt soll ja nichts "nur für fitte Admins" sein, sondern es möglichst einfach gestalten, auch für den weniger fitten der sich seine Apache-Config zusammengooglet.
Zum Vergrößern anklicken....

Da sind Bauchschmerzen IMHO vorprogrammiert. Je "einfacher" es für den Benutzer sein soll, umso weniger "simpel" muss ja der Client sein, damit er möglichst jeden corner case abdeckt und sich an jede Umgebung anpasst. Der alte Unterschied zwischen "easy" und "simple", und es heißt ja KISS und nicht KIES. :>
 
Und je schwieriger es ist, desto mehr Leute geben auf und nutzen weiterhin keine Verschlüsselung. ;) Es wird in Zukunft noch genug andere Clients geben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben