[Ursprünglichgepostet auf Slack Overflow, aber im Kommentarthread wurde über unangemessenen Veranstaltungsort geklagt.]
Wir arbeiten daran, von StartCom SSL-Zertifikaten auf Let’s Encrypt umzusteigen und versuchen, es so einzurichten, dass es automatisch mit macOS Server + Apache HTTPD funktioniert. Vom Befehlszeilentool ( security import) aus akzeptiert macOS Server die reinen Dateien nicht .pem– Sie müssen ihm eine .p12Datei geben, aus der es .pemDateien extrahiert, die in Apache konfiguriert werden sollen. Ärgerlich und sinnlos, aber damit müssen wir vorerst leben.
Um diese .p12Datei zu erstellen, müssen wir diesen Befehl ausführen:
openssl pkcs12 -export \
-inkey /etc/letsencrypt/live/example.com/privkey.pem \
-in /etc/letsencrypt/live/example.com/cert.pem \
-certfile /etc/letsencrypt/live/example.com/chain.pem \
-out /etc/letsencrypt/live/example.com/example.com.p12
Und hier wird es seltsam. Die Ausgabedatei example.com.p12enthält das example.comZertifikatzweimal, gefolgt vom Zwischen-CA-Zertifikat von Let's Encrypt, gefolgt vom unnötigen selbstsignierten DST Root CA X3-Ankerzertifikat (das in allen Browsern standardmäßig installiert ist) und schließlich gefolgt vom privaten Schlüssel. Das Ergebnis ist, dass der Apache SSL-Handshake das Serverzertifikat zweimal sowie das Zwischen-CA-Zertifikat und das Stammzertifikat (das nicht gesendet werden sollte) enthält, was zu Warnungen beim Qualys SSL Labs-Tester führt.
Wir haben hineingeschaut cert.pemund es enthält nur das Serverzertifikat (und nur einmal). Es chain.pementhält nur das Zwischen-CA-Zertifikat (nicht den Root-Anker oder das Server-Zertifikat). privkey.pemEs enthält nur den privaten Schlüssel. openssl pkcs12 -exportDas Serverzertifikat muss also dupliziert werden und dann muss der zusätzliche Schritt ausgeführt werden, das Root-Anker-Zertifikat zu suchen und hinzuzufügen.
Wenn wir denselben Befehl unter openSUSE Linux ausführen, .p12enthält die Ausgabedatei nur das Serverzertifikat (einmal), das Zwischen-CA-Zertifikat und den privaten Schlüssel. Kein Root-Anker.
Wir haben die folgenden Varianten ausprobiert und keinen Unterschied in der Ausgabe festgestellt:
openssl pkcs12 -export \
-inkey /etc/letsencrypt/live/example.com/privkey.pem \
-in /etc/letsencrypt/live/example.com/fullchain.pem \
-out /etc/letsencrypt/live/example.com/example.com.p12
openssl pkcs12 -export \
-inkey /etc/letsencrypt/live/example.com/privkey.pem \
-certfile /etc/letsencrypt/live/example.com/fullchain.pem \
-out /etc/letsencrypt/live/example.com/example.com.p12
Die einzige Möglichkeit, das falsche Verhalten des doppelten Serverzertifikats auf einem Linux-Rechner zu reproduzieren, besteht darin, Folgendes zu tun (der Root-Anker ist dabei allerdings immer noch nicht enthalten):
openssl pkcs12 -export \
-inkey /etc/letsencrypt/live/example.com/privkey.pem \
-in /etc/letsencrypt/live/example.com/cert.pem \
-certfile /etc/letsencrypt/live/example.com/fullchain.pem \
-out /etc/letsencrypt/live/example.com/example.com.p12
(Beachten Sie, dass die Verwendung von fullchain.pemanstelle von chain.pemin Verbindung mit der Verwendung von cert.pem... vollkommen Sinn ergibt, warum das Serverzertifikat dupliziert würde, aber das ist nicht der Befehl, den wir unter Mac OS X verwenden.)
Irgendeine Idee, wie man openssl pkcs12 -exporthier das Richtige tut?