Gerade ist mir bei CentOS 8 diese Meldung aufgefallen
Your system is not supported by certbot-auto anymore.
Certbot will no longer receive updates.
Ich dachte nur Debian würde nicht mehr supported.
Gerade ist mir bei CentOS 8 diese Meldung aufgefallen
Your system is not supported by certbot-auto anymore.
Certbot will no longer receive updates.
Ich dachte nur Debian würde nicht mehr supported.
Die EFF möchte den certbot wohl zukünftig nur über snap anbieten. Bei snap seien wohl alle notwendigen Pakete enthalten. Die je Distribution bereit zu stellen scheint wohl schwieriger/aufwändiger ?
Unter http://download.pd-admin.de/letsencrypt liegt eine neue 64bit-Version des Skripts /opt/pdadmin/bin/letsencrypt, die neben certbot-auto auch dehydrated unterstuetzt.
EDIT 28.4.2021: Das Skript ist seit einiger Zeit Bestandteil von pd-admin und unter dem o.g. URL nicht mehr verfuegbar.
Ich erhalte beim Import Versuch immer folgende Meldung:
###############################
Domains -d <FQDN>
###############################
# INFO: Using main config file /opt/pdadmin/etc/dehydrated.conf
To use dehydrated with this certificate authority you have to agree to their terms of service which you can find here: https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
To accept these terms of service run `/opt/pdadmin/bin/dehydrated --register --accept-terms`.
Alles anzeigen
Dies erscheint auch, wenn der dehydrated Registrierungsbefehl schon ausgeführt wurde.
Gibt es da noch einen weiteren zu berücksichtigenden Schritt oder ist das nur informativ während des Imports und nachher funktioniert trotzdem alles?
Nachtrag:
In der /opt/pdadmin/etc/dehydrated.conf steht
CERTDIR=/opt/pdadmin/sslcerts/__dehydrated
WELLKNOWN=/opt/pdadmin/etc/ssl-validation/.well-known/acme-challenge
CONTACT_EMAIL=<meine email adresse>
Das Verzeichnis __dehydrated ist aber nicht existent.
Ich habe eine neue Version abgelegt, bei der die Registrierung automatisch ausgefuehrt wird, wenn Sie die Konfigurationsdatei noch einmal loeschen.
Die ist wohl nicht ganz korrekt (wahrscheinlich nicht alle Klassen einkompiliert?):
Can't load '/opt/pdadmin/lib/DBI.so' for module DBI: /opt/pdadmin/lib/DBI.so: falsche ELF-Klasse: ELFCLASS64 at PERL2EXE_STORAGE/DynaLoader.pm line 230.
at PERL2EXE_STORAGE/DBI.pm line 261
BEGIN failed--compilation aborted at PERL2EXE_STORAGE/DBI.pm line 261.
Compilation failed in require at /opt/pdadmin/bin/letsencrypt line 11.
BEGIN failed--compilation aborted at /opt/pdadmin/bin/letsencrypt line 11.
Die letsencrypt Datei ist auch wesentlich kleiner ...
Ich hatte versehentlich die 32bit-Version hochgeladen. Das ist jetzt korrigiert.
Also ich habe jetzt gerade erst letsencrypt heruntergeladen und trotzdem kommt noch
To accept these terms of service run `/opt/pdadmin/bin/dehydrated --register --accept-terms'
Wenn ich das ausführe, dann kommt aber trotzdem immer wieder die gleiche Meldung bei letsencrypt.
Wenn ich es dann wieder ausführe, dann kommt
+ Account already registered!
Am Ende des Tages ist das Rätsel einfach zu lösen.
Der dehydrated Aufruf für die Registrierung braucht noch die Angabe des Config-Pfades für die Registrierung.
Sonst legt er den Accounts Ordner standardmäßig unterhalb des Aufrufpfades ab (also /opt/pdadmin/bin statt /opt/pdadmin/etc).
Mit Angabe des Config-Pfades klappt auch der nachgelagerte letsencrypt --import Befehl reibungslos.
Also zur Registrierung von dehydrated folgenden Befehl ausführen:
/opt/pdadmin/bin/dehydrated --config /opt/pdadmin/etc/dehydrated.conf --register --accept-terms
Den Import hätte ich mir allerdings ein wenig anders vorgestellt.
Der hat faktisch einfach alle Zertifikate bei letsencrypt komplett neu beantragt.
Ob das so im Sinne des Erfinders ist oder man nicht einfach die bestehenden Zertifikate übernehmen hätte können?
Danke. So funktioniert es jetzt .
Ich bin mir nicht sicher, ob es eine Nebenwirkung der Umstellung auf dehydrated ist, aber seit ich das umgestellt habe, bekommen Anwender beim Versand von Mails per smtp mit TLS immer folgende Meldung:
Fehler bei der Verbindung:
454 TLS no valid RSA private key: error: 02001002:system library:fopen:No such file or directory (#4.3.0).
Die Datei /var/qmail/control/servercert.pem existiert aber.
Einziger Unterschied zu früher:
Statt ein Block "Beginn Private Key" sind jetzt die folgenden zwei Blöche enthalten
-----BEGIN EC PARAMETERS-----
<Inhalt entfernt>
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
<Inhalt entfernt)
-----END EC PRIVATE KEY-----
Kann es sein, das der qmail Patch ggfs. das neue Format noch nicht unterstützt?
Nachtrag:
Alte Datei nochmal eingespielt (das letsencrypt Zertifikat ist Gott sei Dank noch gültig). Damit geht es.
Der QMAIL Patch hat also noch keine Unterstützung für elliptische Kurven bzw. den neuen Format.
Hoffentlich gibt es da bald einen Patch für
Das ist insofern interessant, als dass ich ja seit 5 Jahren meine Zertis mit dehydrated generiere, und meine key Files haben nur eine Sektion mit "Beginn" und "End".
Ich setze derzeit dehydrated in der Version 0.6.5 ein.
Hmm,
ich habe dehydrated in der aktuellen Version runtergeladen. Das ist soweit ich weiss die 0.7
Nach Recherche im Internet:
Demzufolge kann man wohl mit der Option KEY_ALGO=RSA das Verhalten ändern.
Ausprobiert habe ich es allerdings noch nicht und weiß auch nicht, ob das beim Verlängern der Zertifikate so angewendet wird. Das sehe ich dann in 3 Monaten.
Unabhängig hiervon scheint ja KEY_ALGO=SECP384R1 wohl sicherere Keys zu erzeugen, so das es natürlich sinnwohl wäre, alle Produkte so anzupassen, das sie es unterstützen.
Hallo an alle!
Ich muss euch leider um eure Hilfe bitten und denke ich bin hier richtig.
Gestern sind all meine letsencrypt Zertifikate abgelaufen und das Renew haut auch nicht mehr hin (certbot-auto)
Ich habe jetz mal alles wie oben beschrieben auf dehydrate umgestellt. Jetzt komm ich auf keine Seite mehr rauf (Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG)
Ich denke ich hab da irgendetwas falsch gemacht.
dehydrated muss unter /opt/pdadmin/bin/dehydrated abgelegt werden.
Woher nehmt ir dieses file dehydrate? ich habe es von /usr/local/pd-admin2/bin/ nach /opt/pdadmin/bin/ kopiert - ist das richtig so?
Auch dieser Ordner /opt/pdadmin/sslcerts/__dehydrated der im /opt/pdadmin/etc/dehydrated.conf steht ist nicht existent (auch nach löschen und erneutem import)
Beim Import /opt/pdadmin/bin/letsencrypt --import bekomme ich keine Fehler.
vielen Dank schon mal für eure Hilfe
Ich habe es hier
wget https://github.com/lukas2511/d…ted/archive/master.tar.gz
heruntergeladen und auf dem Testserver hat es ohne Probleme funktioniert.
TLS no valid RSA private key
Ich habe unter http://download.pd-admin.de/letsencrypt eine aktualisierte Version abgelegt, die RSA -Keys erzeugt.
Woher nehmt ir dieses file dehydrate?
Sie koennen die Version aus der Serverumgebung verwendet oder https://raw.githubusercontent.…ydrated/master/dehydrated verwenden.
Wow, vielen Dank - jetzt hat es geklappt!
Könnte mir vielleicht noch jemand mitteilen, wie der Cronjob aussehen soll/muss?
Ich habe bei mir keinen Eintrag für certbot-auto den ich ändern könnte.
Also wenn sich sonst nichts geändert hat, dann würde ich sagen:
35 4 * * * /opt/pdadmin/bin/letsencrypt --all
38 5 * * 2 /opt/pdadmin/bin/letsencrypt --renew
Werden mit diesen Einträgen auch die Zertifikate für den Mailserver erneuert?
Ich habe den Mailserver bei der Installation mit /opt/pdadmin/bin/update_host_certificate.sh abgesichert.
Dieses Skript musste ich heute wieder ausführen, damit die Mailfunktionen keine SSL Fehler mehr bringen.
Muss der auch in die Crontab?
Ich habe unter http://download.pd-admin.de/letsencrypt eine aktualisierte Version abgelegt, die RSA -Keys erzeugt.
Sie koennen die Version aus der Serverumgebung verwendet oder https://raw.githubusercontent.…ydrated/master/dehydrated verwenden.
Works perfect for me ......