Hosted-by-discourse verwendet abgelaufene SSL-Zertifikate, obwohl die Statusseite grün ist

Unterstützung
1

Dies führt derzeit zu Fehlern auf unserer Website; alle Beiträge hier scheinen sich auf selbst gehostete Sites zu beziehen.

❯ openssl s_client -connect (removed).com:443 -servername (removed).com
CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
 0 s:/CN=(removed).com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

Die API-Endpunkte melden für uns einen Fehler wegen eines abgelaufenen Zertifikats, was wir auch über Postman überprüft haben.

2

@team bitte hier helfen

3

Hmm. Das wirkt seltsam.

4

Das klingt nach einem Problem auf Ihrer Seite (also der Seite Ihrer Website).
Das vom Server bereitgestellte Zertifikat ist in Ordnung und wird von fast allen Browsern akzeptiert – das Problem ist, dass viele ältere Server das (relativ) neue Stammzertifikat nicht in ihrem Trust-Store haben, sodass derzeit viele automatisierte Prozesse Fehler melden.

Ich kenne Ihre genaue Website nicht, daher habe ich eine beliebige hosted-by-discourse.com-Seite ausgewählt und sie über den Qualys SSL Server Test laufen lassen.

image
image854×760 37.7 KB

Wie Sie sehen können, ist die Root-Zertifizierung des zweiten Zertifizierungspfads tatsächlich abgelaufen. Dies wird jedoch durch das ISRG Root X1-Zertifikat abgemildert, das sich im Trust-Store befindet (also in Ihrem Browser und/oder Betriebssystem enthalten ist) für den ersten Zertifizierungspfad.

Server aktualisieren ihren Trust-Store in der Regel nicht häufig, sodass Ihr Server das ISRG Root X1-Zertifikat wahrscheinlich nicht in seinem Trust-Store hat. (Das ist auch beim Mail-Empfänger-Docker-Image passiert).

Sie können ein aktuelles Bundle beispielsweise unter https://curl.se/ca/cacert.pem finden. Auf CentOS wird diese Datei nach /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem kopiert. Auf Ubuntu können Sie den Befehl update-ca-certificates verwenden, der /etc/ssl/certs/ca-certificates.crt aktualisiert.

Alternativ könnten Sie die SSL-Zertifikatsüberprüfung in Ihrem Servercode vorübergehend deaktivieren.

5

Ich habe die Ausgabe von OpenSSL gepostet, um zu beweisen, dass dies nichts mit unserer Website zu tun hat, und Postman wird von einer lokalen Windows-Maschine ausgeführt.

Edit: Ich bin mit den verschiedenen Ebenen der Trust Stores nicht so vertraut, ich werde mich noch etwas damit beschäftigen. Es tritt einfach auf jedem Gerät auf, das wir versuchen.

6

Es schlägt nicht fehl, wenn Sie einen echten Browser verwenden, oder?

EDIT: Immer mehr Leute haben Probleme mit Postman, also ist das wohl kein gültiger Test… :thinking:

7

das ist eine Antwort, die ich von unserem DevOps-Mitarbeiter erhalten habe.

Das Problem besteht darin, dass es zwei Kopien von ISRG Root X1 gibt: Eine davon wurde vor langer Zeit von DST Root CA X3 ausgestellt, während die neuere von der ISRG (der Gruppe, die unter anderem Let’s Encrypt verwaltet) selbst signiert wurde. Diese selbstsignierte Root CA wird mittlerweile auf den meisten Systemen als vertrauenswürdige Root CA akzeptiert.

Es handelt sich um dasselbe Signaturzertifikat, sodass Sie alles, was als von „ISRG Root X1“ ausgestellt beansprucht wird, gegen beide Versionen validieren können. Das von DST signierte Zertifikat ist jedoch nicht mehr als Zertifizierungspfad gültig, da das DST-Zertifikat, das es signiert hat, mittlerweile abgelaufen ist.

Wenn der Server korrekt agieren würde und die neuere, selbstsignierte ISRG Root X1 bereitstellen würde, würde der Client das bereitgestellte Zertifikat mit seinem eigenen Vertrauensspeicher vergleichen, feststellen, dass es sich um dasselbe Zertifikat handelt, und die Verbindung akzeptieren. Stattdessen erkennt der Client das bereitgestellte Zertifikat, denkt: „Okay, ich muss dies gegen DST Root CA X3 validieren, die ich gespeichert habe … oh, das ist abgelaufen“ und scheitert bei der Verifizierung.

8

Ein Zertifikat in der Zertifikatskette anzubieten, das ohnehin im vertrauenswürdigen Root-CA-Speicher erwartet wird, ist keineswegs „das Richtige tun".

Schauen wir uns die Zertifikatskette von letsencrypt.org selbst an: SSL Server Test: letsencrypt.org (Powered by Qualys SSL Labs)

Hey, schau mal. Sie machen dasselbe; die Zertifikatskette ist identisch (natürlich mit Ausnahme des Serverzertifikats).

image
image812×744 33.1 KB

Entweder liegt dein DevOps-Mitarbeiter falsch, oder CDCK, LetsEncrypt und Qualys liegen alle falsch.
Sag ihm, er soll den Root-CA-Speicher aktualisieren. Das wird das Problem beheben. Glaub mir.

9

Hallo @bpaterson2000 – es tut uns leid zu hören, dass du Probleme bei der Verbindung zu unserem gehosteten Dienst hast. Wie @RGJ bereits erwähnt hat, liegt das Problem nicht auf Seite von Discourse – es muss auf deiner Client-Seite behoben werden. (Unsere Server stellen das Stammzertifikat nicht bereit; dieses wird von deinem Client verwaltet.)

Weitere Details zu dieser Änderung findest du bei Let’s Encrypt hier:

10

Vielen Dank für die Informationen. Für uns ist dies ein unerwartetes Problem, da die Fehler anscheinend vom gehosteten Server zurückkamen.

Wir nutzen Heroku, das die von dir erwähnten Komponenten offenbar über Node/Packages mitliefert. Es sieht so aus, als wäre das Aktualisieren von Node der Schlüssel gewesen, um die Verbindung zur Discourse REST-API wieder erfolgreich herzustellen.

Danke für deine Hilfe.