SSL-Bugfix: Falsche Warn-E-Mails bei abgelaufenen Zertifikaten

Das Problem

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.

Ursache

Das Problem hatte zwei Wurzeln:

1. Falscher diffInDays()-Aufruf

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

2. Falscher Status im Exception-Handler

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.

Der Fix

• diffInDays() wird jetzt mit vorzeichenbehaftetem Ergebnis aufgerufen, sodass abgelaufene Zertifikate negative Werte liefern und damit sauber von zukünftigen unterschieden werden können.
• Die Darstellung in E-Mail und Fehlermeldung ist zusätzlich nach unten auf 0 abgesichert – negative Werte können so nicht mehr auftauchen.
• Abgelaufene Zertifikate werden nun konsequent als down klassifiziert, nicht als ssl_warning.

Semantik: ssl_warning vs. down

ssl_warning bedeutet: Die Domain ist erreichbar, das Zertifikat läuft aber bald ab. Handlungsbedarf, aber kein Ausfall.

Betroffene Bereiche

• Statusberechnung im Domain-Check-Service
• Tagesberechnung in der SSL-Warn-Benachrichtigung
• Hilfsmethode zur SSL-Ablaufprüfung im Check-Modell
• Integrationstest für abgelaufene Zertifikate