Ich habe mich aufgrund dieses Artikels auch mit LetsEncrypt versucht. Danke für den Hinweis. :) Es gibt für die Windows-Umgebung https://github.com/Lone-Coder/letsencrypt-win-simple (https://github.com/Lone-Coder/letsencrypt-win-simple). Hat damit schon jemand Erfahrungen?
Die Idee ist letztlich die Zertifizierung zu automatisieren, wie bei Tode. Da ich aber kein SSL-Experte bin, tue ich mich aber schon mit dem Start schwer.
Mein Aufruf lautet:
letsencrypt.exe --emailaddress adresse@somewhere.de --usedefaulttaskuser --accepttos --manualhost host.de --webroot "D:\Domino\Data\html"
Dies erzeugt folgende Dateien:
host.de-all.pfx
host.de-chain.pem
host.de-crt.der
host.de-crt.pem
host.de-csr.pem
host.de-gen-csr.json
host.de-gen-key.json
host.de-key.pem
ca-C70C419800000154857B6A0B85ECA718-crt.pem
Es werden sicher nur die .pem-Dateien benötigt.
-key.pem ist wohl mein privatekey;
-chain.pem ist wohl mein chain.pem;
-crt.pem ist wohl mein cert.pem;
für die -crt.pem habe ich keine Idee. - Die .pfx, .der und .json- Dateien sind wohl für IIS oder sonst etwas.
Ich habe auch die Root- und Intermediate-Zertifikate von https://letsencrypt.org/certificates/ runter geladen:
"SRG Root X1 (self-signed)", "Let’s Encrypt Authority X3 (IdenTrust cross-signed)" und "Let’s Encrypt Authority X3 (Signed by ISRG Root X1)".
Dann alle Zertifikate in eine Datei kopiert und geprüft:
kyrtool.exe ="C:\Program Files\IBM\Domino\notes.ini" verify "server.txt"
Das liefert:
KyrTool v1.1
Successfully read 2048 bit RSA private key
INFO: Successfully read 4 certificates
INFO: Private key matches leaf certificate
INFO: IssuerName of cert 0 matches the SubjectName of cert 1
ERROR: IssuerName of cert 1 does NOT match the SubjectName of cert 2
INFO: IssuerName of cert 2 matches the SubjectName of cert 3
INFO: Final certificate in chain is self-signed
Der ERROR kommt aus der -chain.pem, die zwei Zertifikate enthält. Wenn ich das zweite Zertifikat entferne, läuft das ohne ERROR durch. Komisch.
Wenn ich dies dann in meinen Keyring installiere (kein Fehler) und die HTTP-Task neu starte, habe ich folgende Ergebnisse:
In Firefox:
https://host.de/ -> Kein Problem! Zertifikat ist OK
https://www.host.de/ -> SSL_ERROR_BAD_CERT_DOMAIN
In Chrome:
https://host.de/ -> meldet das Zertifikat der Seite als unsicher
https://www.host.de/ -> meldet das Zertifikat der Seite als unsicher
In IE:
https://host.de/ -> meldet das Zertifikat der Seite als unsicher, erlaubt dann das aber zu ignorieren
https://www.host.de/ -> meldet das Zertifikat der Seite als unsicher, erlaubt dann das aber zu ignorieren
Hat jemand eine Idee? Ist wahrscheinlich nur eine Kleinigkeit, aber ich probiere schon eine gefühlte Ewigkeit rum; lasse mal dieses, mal jenes Zertifikat weg.
Leider tut's immer noch nicht, vielleicht kannst Du ja nochmal Klarheit bringen. Der Aufruf von letsencrypt-win-simple erzeugt diese fünf .pem-Dateien:
host.de-chain.pem <- ca-bundle? Enthält zwei Zertifikate, beginnen mit BEGIN CERTIFICATE
host.de-crt.pem <- mein Zertifikat? Startet mit BEGIN CERTIFICATE
host.de-csr.pem <- weiß nicht was das ist, beginnt mit BEGIN CERTIFICATE REQUEST, wird wohl nicht benötigt
host.de-key.pem <- private key, BEGIN RSA PRIVATE KEY
ca-0C0142490000B4B38A72640585ECF408-crt.pem <- dies ist das Issuer-Zertifikat; BEGIN CERTIFICATE
Außerdem habe ich mir noch diese Root- und Intermediate-Zertifikate von Let's Encrypt runter geladen:
isrgrootx1.pem
lets-encrypt-x3-cross-signed.pem
letsencryptauthorityx3.pem
Das ganze habe ich dann zusammen kopiert mit
TYPE host.de-key.pem host.de-crt.pem host.de-chain.pem letsencryptauthorityx3.pem isrgrootx1.pem > "F:\Cert\server.txt"
Die Prüfung mittels
kyrtool ="C:\Program Files\IBM\Domino\notes.ini" verify "F:\Cert\server.txt"
liefert dann diverse Fehlermeldungen
Successfully read 2048 bit RSA private key
INFO: Successfully read 5 certificates
INFO: Private key matches leaf certificate
ERROR: IssuerName of cert 0 does NOT match the SubjectName of cert 1
INFO: IssuerName of cert 1 matches the SubjectName of cert 2
ERROR: IssuerName of cert 2 does NOT match the SubjectName of cert 3
INFO: IssuerName of cert 3 matches the SubjectName of cert 4
INFO: Final certificate in chain is self-signed
Ich habe schon verschiedene Reihenfolgen probiert, komme aber auf keine Kombination, die nur INFO-Meldungen erzeugt.
Wie kann man denn feststellen, welche Zertifikate fehlen bzw. wo die Reihenfolge klemmt (nerv)?
Ich bin inzwischen auch etwas weiter gekommen und Deine Vermutung ist wohl korrekt! Mit kyrtool show certs -i <pem-Datei>
kann man so nach und nach die Zertifikatsinformationen anzeigen (wusste ich zuvor nicht):
Using PEM file path 'isrgrootx1.pem'
Subject: CN=ISRG Root X1/O=Internet Security Research Group/C=US
Issuer: CN=ISRG Root X1/O=Internet Security Research Group/C=US
Using PEM file path 'letsencryptauthorityx3.pem'
Subject: CN=Let's Encrypt Authority X3/O=Let's Encrypt/C=US
Issuer: CN=ISRG Root X1/O=Internet Security Research Group/C=US
Using PEM file path 'IdenTrust_root.pem'
Subject: CN=DST Root CA X3/O=Digital Signature Trust Co.
Issuer: CN=DST Root CA X3/O=Digital Signature Trust Co.
Using PEM file path 'lets-encrypt-x3-cross-signed.pem'
Subject: CN=Let's Encrypt Authority X3/O=Let's Encrypt/C=US
Issuer: CN=DST Root CA X3/O=Digital Signature Trust Co.
Using PEM file path 'host.de-crt.pem'
Subject: CN=host.de
Issuer: CN=Let's Encrypt Authority X3/O=Let's Encrypt/C=US
Using PEM file path 'host.de-chain.pem'
Subject: CN=host.de
Issuer: CN=Let's Encrypt Authority X3/O=Let's Encrypt/C=US
Subject: CN=Let's Encrypt Authority X3/O=Let's Encrypt/C=US
Issuer: CN=DST Root CA X3/O=Digital Signature Trust Co.
Using PEM file path 'ca-0C0142490000B4B38A72640585ECF408-crt.pem'
Subject: CN=Let's Encrypt Authority X3/O=Let's Encrypt/C=US
Issuer: CN=DST Root CA X3/O=Digital Signature Trust Co.
Vor privaten Key abgesehen baut sich die Kette (umgekehrt) dann so auf:
isrgrootx1.pem - als Root ISRG Root X1
letsencryptauthorityx3.pem - als Intermediate Let's Encrypt Authority X3
host.de-crt.pem - mit meinem Host-Zertifikat host.de
Nach Import und Neustart der HTTP-Task ist FF absolut zufrieden (!), IE und Chrome nicht, weil das Root-Zertifikat nicht akzeptiert wird. Aber immerhin habe ich eine Menge gelernt, "kyrtool verify" ist zufrieden und die Kette ist nun komplett. :D
Jetzt müsste ich noch wissen, wie man gleichzeitig auch den zweiten Zertifizierungspfad über DST Root CA X3 einbindet.
Wir haben gestern eine neue Version veröffentlicht. https://midpoints.de/de-solutions-LE4D (https://midpoints.de/de-solutions-LE4D) Alle die, die LE4D seinerzeit über unsere Webseite angefordert hatten, sollten eine Benachrichtigung per Mail erhalten haben.
Ein Update auf die neue Version ist wichtig, da Let's Encrypt Änderungen an der Endpoint API vorgenommen hat. Der in LE4D 1.x verwendete Code kann sich nicht mehr mit der CA verbinden. Das Anfordern neuer, bzw das Verlängern bestehender Zertifikate schlägt daher fehl. Auf der KOnsole sieht man die folgende Fehlermeldung
org.shredzone.acme4j.exception.AcmeNetworkException: Network error
...
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: No trusted certificate found
Darüber hinaus wurde das Handling vereinfacht. Die "interne" HTTP / HTTPS Verbindung fällt weg. Der gesamte Code ist jetzt in einem Java Agenten enthalten. LE4D 2.0 verwendet Java 8. LE4D 2.0, und benötigt daher min. FP8. In der Version 1.x hatte ich den kompletten Code von acme4j und anderen .jar noch nach Java 1.6 zurück portiert.