Let's Encrypt Probleme 2025-05?

Grüß euch,

Diese Woche hat mein Server - wie so viele Male davor - per ACMEv2 seinen Let's Encrypt Certificate Signing Request übermittelt, und dementsprechend sein neues Zertifikat ausgestellt bekommen. Seitdem gibt's Probleme, und ich habe auch aus der Industrie in zumindest einem Fall von ähnlichen Troubles gehört.

Manche Netzwerkclients droppen jetzt Connections, weil sie meinen sie könnten das Endpunktzertifikat nicht zertifizieren. So als würde das Intermediate ned passen. Andere liefern Fehler wie "Error: Server sent unsorted certificate chain in violation of the TLS specifications". Wieder andere regen sich gar nicht auf. Ich habe mir die Chain angeschaut, aber die Sortierung paßt.

Die Chain of Trust auf meinem Server schaut den Files zufolge so aus: ISRG Root X1 --signs--> Let’s Encrypt R11 --signs--> End-Entity Server Certificate.

Stimmt da grade irgendwas ned? In manchen Clients wird jetzt das R10 anstatt des R11 als Intermediate Certificate gelistet, ist das eventuell der Grund? Hams R11 weggeschmissen und zertifizieren jetzt nur mehr per R10 oder wie?

testssl.sh sagt bei mir u.a.:

Code:

 Issuer                       R10 (Let's Encrypt from US)
 Trust (hostname)             Ok via SAN (same w/o SNI)
 Chain of trust               NOT ok (chain incomplete)

In den News kann ich nichts finden, und die Infos zur Chain of Trust bei Let's Encrypt sind eigentlich unverändert.

Muß ich jetzt R11 durch R10 tauschen?

Meine sind von April und alle über R10

Okay, danke euch. Nachdem meine Chain X1 => R11 => Server ist, wird das das Problem sein. Ich schicke R10 vom Server aus nämlich ned mit. Und wenn der Client R10 ned schon in seiner Trust Chain hat, dann kracht's natürlich.

Jetzt check' ich das. Vor'm nächsten Renewal also R11 durch R10 austauschen.

Danke!

Edit: SSL/TLS suxx. Kann ich bitte Crypto ohne Identitätsverifikation haben? Hah...

Okay, saublöde Frage: Wie automatisiert man das?! Ich habe keinen Link zwischen meiner Server Software (die nutzt rein OpenSSL) und dem Certificate Store des Hostbetriebssystems (Windows; also SChannel / WinSSL).

Jetzt müßte ich ja eine Cert Chain haben, in der R10 und R11 cross-signed eingebunden sind, zusätzlich zum Clientzert und ebem dem CA Root Cert. Aber sowas geht ja ned, erstens weil sich R10 und R11 auf der selben Ebene befinden (Cert Ordering ned lösbar?) und halt auch einfach ned cross-signed sind.

Also, das Problem das ich grad ned check ist:

• ACMEv2 Client schickt neuen Signing Request zu Let's Encrypt
• ACMEv2 Client bekommt ein neues Client Certificate zurück
• Mein Updateskript assembliert einen Certificate Stack in Form eines sortierten PEM Chainfiles (Client -> Intermediate -> Root)
• Wie kann der Client entscheiden welches Intermediate er zum Bau des Chainfiles nehmen soll?

Soll ich da jetzt z.B. mit OpenSSL im Skript (welches die Zert Chains ausrollt und alle Server neustartet) auslesen welches Intermediate mein Client Certificate gezeichnet hat, und dann das entsprechende per Fallentscheidung in die Chain stopfen? Ein bissl sinnlos verkompliziert käme mir das schon vor...

Oder gibt es da einen eleganteren Weg?

Ich habe hier eh ein super "testssl" Skript, das alles mögliche an Lücken und Problemen auf einem laufenden TLS Socket prüft. Und der schreit eh sofort, also der Fall ist mittlerweile sonnenklar.

Und jo, ich muß das Intermediate vom Server an den Client mitschicken. Logisch. Klar. Mache ich eh, weil ich die komplette Chain schicke. Wie bereits gesagt: Client -> Intermediate -> Root. Diese Chain liegt bei jedem meiner Serverdienste als PEM Datei dabei und ist per Konfiguration entsprechend in selbige eingebunden.

Das ist ned mein Problem!

Mein Problem ist: Wie stelle ich sicher, daß wenn Let's Encrypt mein Clientzertifikat mit dem R11 Intermediate zeichnet, daß ich dann auch das R11 Intermediate in die Chain einpflege? Weiters: Wie stelle ich sicher, daß wenn Let's Encrypt mein Clientzertifikat mit dem R10 Intermediate zeichnet, daß ich dann auch das R10 Intermediate in die Chain einpflege, und ned das R11?

Simpler: Wie stelle ich sicher daß immer das korrekte Intermediate in meine PEM Dateien eingepflegt wird, sodaß die Chain of Trust intakt bleibt?

Muß ich da jetzt echt selber Branches programmieren? Ich meine, kann ich wohl schon machen, aber die Frage war eben: "Geht es eleganter?". Also gibt's da schon was fertiges, z.B. beim ACMEv2 Client selber? Ich habe Crypt::LE von ZeroSSL.

Zitat aus einem Post von davebastard

Afaik müsste das rotieren der intermediates auch der ACME client

this, hab da selber noch nie was herumgewerkelt

Ist jetzt ned extrem dringend, es geht ja nur um meinen Homeserver, also nix wirklich kritisches. Sind zwar öffentliche Dienste dabei, aber letzten Endes isses maximal "lästig".

Aber dann werde ich mir Mal die Dokumentation von Crypt::LE durchlesen. Vielleicht hat der Bot ja ein Mittel bzw. um gleich das korrekte Intermediate mitzuladen.

So einfach isses leider nicht. Kannst dich noch erinnern, als wir Mal über Backportmöglichkeiten in Bezug auf Apache auf eine gewisse ETWAS unfrische Windows Version gesprochen haben? ;p

Wahrscheinlich ned, aber jo, einen ACMEv2 Client der auf einem uuuuralten NT rennt ist ned ganz so easy anzufinden. Ich betreibe immer noch den selben Monsterserver aus dem Jahre 1996. Da kriegst einfach kein modernes Betriebssystem mehr drauf, wurscht ob das Windows, Linux oder *BSD heißt. Der Support für die Hardware ist verständlicherweise schon vor Uuurzeiten aus sämtlichen Kerneln geflogen.

Ich weigere mich aber den Betrieb einzustellen! Nur mehr 1 Jahr, dann hat er seine 30 Jahre Betrieb geschafft.

Crypt::LE habe ich also ned weil's so geil ist, sondern weil man es weit genug zuückgehacked bekommt. Sonst hätte ich wohl einfach das erstbeste genommen das Let's Encrypt selber empfiehlt.

Ich schau's mir halt Mal an. Und wenn's der Client echt nicht können sollte, dann skripte ich mir das halt selber zusammen.