Letsencrypt Zertifikate teilweise abgelaufen; keine Erneuerung

[tf91]

Hallo,

seit einiger Zeit habe ich einen UCS mit Letsencrypt, was auch bisher sehr gut funktioniert hat.

Seit Ende August sind jedoch einige Zertifikate von Subdomains abgelaufen und werden einfach nicht aktualisiert. Ich habe bereits mehrfach eine manuelle Aktualisierung angestoßen und auch die App schon einmal komplett neu installiert.

Laut Log läuft das ganze auch problemlos durch jeweils mit dem status “verified” bei jeder Domain sowie “Certificate signed” am Ende.

Ich habe folgende Domains für Zertifikate eingetragen: www.domain.de domain.de admin.domain.de mail.domain.de cloud.domain.de.

Komischerweise ist das Zertifikat für admin.domain.de aktuell, alle anderen sind abgelaufen und werden nicht aktualisiert.

Hat hier jemand eventuell einen Hinweis?

[ahrnke]

Hallo,

wenn Sie Lets Encrypt auf einem System installiert haben, werden die zusätzlichen Domains im Zertifikat als subject alternative name (SAN) geführt. Ein Firefox auf Deutsch nennt das auch “Zertifikatsgegenstand-Alternativ-Name”. Lies: Sie haben nur ein Zertifikat.
Wenn “die anderen” abgelaufen sind, wäre meine erste Schlußfolgerung, dass die Konfiguration der zusätzlichen Hosts auf ein altes Zertifikat verweist.
Und das sieht verdächtig nach dem vom mir beschriebenen Problem aus:

Lets Encrypt expired

Just a quick heads-up for users of the Lets Encrypt app. At least those who have deployed it before May or have followed Mini-Howto: Kopano IMAP & Let's Encrypt We had 2 reports today that the certificate has expired. According to /var/log/univention/letsencrypt.log the automatic renewal was successfully executed on Aug 1st. A quick look into the /etc/univention/letsencrypt.log showed that former versions created a chained.pem while the new app now provides the certificate as signed_chain.crt. …

hth,
Dirk Ahrnke

[tf91]

Hallo,
vielen Dank für den Hinweis, das könnte es tatsächlich grundsätzlich sein, da ich in den Virtual Hosts entsprechende Verweise hatte. Da bin ich so nicht drauf gekommen.

Momentan habe ich jedoch das Problem, dass Apache abstürzt, bzw. sich aufgrund der Zertifikate offenbar nicht neu starten lässt. Und zwar sogar wenn die Virtual Hosts inaktiv sind und nur die “standardmäßige” Nutzung der Zeritifkate durch Letsencrypt im Apache aktiviert wird.

Im error.log steht “Certificate and private key domain.de:433:0 from /etc/univention/letsencrypt signed_chain.crt and /etc/univention/letsencrypt/domain.key do not match”. Und zwar dann für jede Domain, für die ich ein Zertifikat bei letsencrypt habe.

Anscheinend läuft da ja doch was bei der Aktualisierung falsch? Im Moment kann ich es leider aber auch nicht wirklich weiter testen, weil ich aufgrund der häufigen Neustarts und versuche gesperrt wurde (“too many certificates alreeady issued for exact set of domains”…)

Ich schätze jetzt muss ich erst wieder eine Woche warten.

[tf91]

Inzwischen konnte das Zeritifkat wieder aktualisiert werden.

Es besteht jedoch weiterhin das Problem, dass bei gesetztem Zertifikat der Apache nicht neu gestartet werden kann und sich dann auch nicht starten lässt.

Im error.log findet sich “Certificate and private key ucs.intra.domain.com:433:0 from /etc/univention/letsencrypt signed_chain.crt and /etc/univention/letsencrypt/domain.key do not match”

Dort wird also der Name des UCS angezeigt.

Apache lässt sich nur wieder neu starten, wenn ich die UCR-Variablen apache2/ssl/certificate und apache2/ssl/key zurücksetze.

Ich bin jetzt gerade etwas ratlos, weshalb das dort auf einmal nicht mehr zusammenpassen soll.

[fbartels]

/etc/univention/letsencrypt signed_chain.crt

Ist in der Logmeldung dort tatsächlich ein Leerzeichen? Oder handelt es sich hier im einen Copy & Paste Fehler?

Nur zum Vergleich, ich habe die folgenden Variablen gesetzt:

apache2/ssl/certificate: /etc/univention/letsencrypt/signed_chain.crt
apache2/ssl/certificatechain: /etc/univention/letsencrypt/intermediate.pem
apache2/ssl/key: /etc/univention/letsencrypt/domain.key
saml/apache2/ssl/certificate: /etc/univention/letsencrypt/signed_chain.crt
saml/apache2/ssl/certificatechain: /etc/univention/letsencrypt/intermediate.pem
saml/apache2/ssl/key: /etc/univention/letsencrypt/domain.key

[tf91]

Ist in der Logmeldung dort tatsächlich ein Leerzeichen? Oder handelt es sich hier im einen Copy & Paste Fehler?

Das ist nur ein Tippfehler von mir, sorry.

Hmm, das intermediate.pem wird von letsencrypt automatisch nicht (mehr?) gesetzt. Ich hatte auch irgendwo gelesen, dass sei nicht mehr erforderlich, aber werde es nochmal damit testen.

[ahrnke]

Hallo,

das intermediate wird nicht mehr benötigt, da es schon in der chain des Zertifikates enthalten ist. Das was Sie da ggf. noch haben, gehört vermutlich zu einem alten Zertifikat und passt daher nicht.

ucr unset apache2/ssl/certificatechain

Viele Grüße,
Dirk Ahrnke

[tf91]

das intermediate wird nicht mehr benötigt, da es schon in der chain des Zertifikates enthalten ist.

Danke für die Bestätigung.

Bei mir war/ist die Variable gar nicht gesetzt und es entsteht der o. g. Fehler.
Mir scheint als läuft da irgendwas falsch bei der Zertifikats Erstellung, aber mir ist nichts ersichtlich, da laut lets encrypt erfolgreich erstellt wurde. Oder Apache hat Probleme mit dem Zertifikat.

Edit:
Nachdem ich die signed_chain.crt und domain.key auch nochmal prüfte sah ich auch, dass die beiden nicht zusammengepasst haben.

Testweise habe ich dann einfach mal signed_chain.crt, domain.key, domain.csr und account.key aus dem Verzeichnis genommen und letsencrypt noch einmal erstellen lassen. Nun funktioniert es wieder.
Irgendwo scheint da etwas fehlerhaftes gewesen zu sein, was zu einer fehlerhaften Erstellung führte.