Einige Nutzer erhielten SSL-Warn-E-Mails mit einem negativen Restzeitwert wie -82 day(s) left. Ein abgelaufenes Zertifikat wurde dabei fälschlicherweise als „bald ablaufend“ behandelt statt als echter Fehler.
Einige Nutzer erhielten SSL-Warn-E-Mails mit einem negativen Restzeitwert wie -82 day(s) left. Ein abgelaufenes Zertifikat wurde dabei fälschlicherweise als „bald ablaufend“ behandelt statt als echter Fehler.
Das Problem hatte zwei Wurzeln:
diffInDays()-AufrufCarbons diffInDays() gibt ohne weiteres Argument immer einen absoluten, positiven Wert zurück – egal ob das Datum in der Vergangenheit oder Zukunft liegt. Ein vor 25 Tagen abgelaufenes Zertifikat lieferte daher denselben Wert wie eines, das noch in 25 Tagen abläuft. Durch den Vergleich mit dem Schwellenwert (ssl_expiry_warning_days, Standard: 30 Tage) wurde es fälschlicherweise als „bald ablaufend“ eingestuft – und der angezeigte Tageswert in der E-Mail konnte je nach Aufrufkontext negativ werden.
Wenn cURL den Verbindungsaufbau wegen eines abgelaufenen Zertifikats abbricht (Error 60), wurde der Status pauschal auf ssl_warning gesetzt. Korrekt wäre down, da ein abgelaufenes Zertifikat einen echten Fehler darstellt.
diffInDays() wird jetzt mit vorzeichenbehaftetem Ergebnis aufgerufen, sodass abgelaufene Zertifikate negative Werte liefern und damit sauber von zukünftigen unterschieden werden können.0 abgesichert – negative Werte können so nicht mehr auftauchen.down klassifiziert, nicht als ssl_warning.ssl_warning vs. down| Situation | Status |
|---|---|
| Zertifikat gültig, läuft in ≤ 30 Tagen ab | ssl_warning |
| Zertifikat abgelaufen | down |
| Zertifikat ungültig / nicht verifizierbar | down |
| Server nicht erreichbar, DNS-Fehler | down |
ssl_warningbedeutet: Die Domain ist erreichbar, das Zertifikat läuft aber bald ab. Handlungsbedarf, aber kein Ausfall.
