CentOS 8 certbot-auto

  • 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.


    • Zur Verwendung von dehydrated muss /opt/pdadmin/bin/certbot-auto geloescht werden, falls vorhanden.
    • dehydrated muss unter /opt/pdadmin/bin/dehydrated abgelegt werden.
    • Bereits vorhandene Zertifikate koennen mit "/opt/pdadmin/bin/letsencrypt --import" uebernommen werden.
    • Die Verlaengerung der Zertifikate erfolgt mit "/opt/pdadmin/bin/letsencrypt --renew"
      "/opt/pdadmin/bin/certbot-auto renew" muss in der crontab durch diesen Befehl ersetzt werden.
  • Ich erhalte beim Import Versuch immer folgende Meldung:

    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.

  • 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 ...

  • 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?

  • 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:

    EC PRIVATE KEY not recognized


    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

  • 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.

  • 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?