Hallo NSP-Team,
ich habe den Beitrag zu SwissSign aufmerksam und interessiert verfolgt.
https://forum.nospamproxy.com/threads/swisssign-bestimmte-zertifikate-widerrufen-und-erneuern.1739/
Nachdem der Höhepunkt der aktuellen Situation offenbar erreicht bzw. überschritten ist, möchte ich einige Gedanken und Fragen dazu teilen.
Vor weniger als vier Wochen gab es bereits einen Vorfall bei D-Trust. Damals waren ausschließlich TLS-Zertifikate betroffen. Auslöser war letztlich eine vergleichsweise kleine Abweichung – die Zertifikatslaufzeit betrug 203 statt der erlaubten 200 Tage. Dennoch wurde vorsorglich ein Issue im Mozilla Bugtracker (Link) erstellt, was innerhalb kürzester Zeit zu einem größeren Problem (aktueller Linter Prozess entspricht nicht den Baseline Requirements) geführt hat. Mich hatte damals ehrlich gesagt gewundert, dass es im Forum kaum Rückfragen dazu gab. Wobei der Zeitpunkt (Freitag, ca. 17:30 Uhr) sicherlich auch eine Rolle gespielt haben dürfte.
Nun, keine vier Wochen später, erleben wir mit SwissSign den nächsten Vorfall. Dieses Mal bei einem größeren Anbieter und im Bereich S/MIME statt TLS. Auch hier liegt die Ursache in einem Compliance-Thema, und erneut wurde ein Issue im Mozilla Bugtracker (Link) erstellt.
Aus meiner Sicht ist die genaue Ursache für die betroffenen Kunden zweitrangig. Entscheidend ist: Die Baseline Requirements definieren klar, innerhalb welcher Fristen betroffene Zertifikate widerrufen werden müssen – unabhängig von Wochenenden, Feiertagen oder anderen Umständen.
Was mich nachdenklich stimmt, ist die Einschätzung des Risikos solcher Szenarien. Offenbar wurde dieses zwar grundsätzlich betrachtet, aber eher als unwahrscheinlich eingestuft oder im Worst Case nicht ausreichend berücksichtigt. Zu dieser Einschätzung komme ich unter anderem aufgrund des kurzfristig bereitgestellten PowerShell-Skripts, das offensichtlich unter hohem Zeitdruck entstanden ist. Möglicherweise basierte es auf früheren, internen Tests – dennoch wirkte die Lösung eher reaktiv als vorbereitet.
In beiden Fällen lag die Vorlaufzeit bis zum Sperren bzw. Zurückziehen der Zertifikate bei maximal fünf Tagen. Allerdings gibt es Rahmenbedingungen, unter denen sich dieser Zeitraum auf 24 Stunden verkürzen kann. Das ist dann eine ganz andere Hausnummer. Im Vergleich dazu wirken fünf Tage fast komfortabel.
Positiv hervorheben möchte ich an dieser Stelle, dass zeitnah ein Workaround zur Verfügung gestellt wurde. Herzliches Dankeschön dafür an dieser Stelle! Dennoch würde ich mir als Kunde perspektivisch eine nachhaltigere Lösung wünschen. Eine entsprechende Funktionalität sollte aus meiner Sicht direkt im Produkt und vollständig über die UI abbildbar sein, ohne auf Skripte zurückgreifen zu müssen.
Mich würde daher interessieren:
Vielen Dank vorab und viele Grüße,
Daniel
ich habe den Beitrag zu SwissSign aufmerksam und interessiert verfolgt.
https://forum.nospamproxy.com/threads/swisssign-bestimmte-zertifikate-widerrufen-und-erneuern.1739/
Nachdem der Höhepunkt der aktuellen Situation offenbar erreicht bzw. überschritten ist, möchte ich einige Gedanken und Fragen dazu teilen.
Vor weniger als vier Wochen gab es bereits einen Vorfall bei D-Trust. Damals waren ausschließlich TLS-Zertifikate betroffen. Auslöser war letztlich eine vergleichsweise kleine Abweichung – die Zertifikatslaufzeit betrug 203 statt der erlaubten 200 Tage. Dennoch wurde vorsorglich ein Issue im Mozilla Bugtracker (Link) erstellt, was innerhalb kürzester Zeit zu einem größeren Problem (aktueller Linter Prozess entspricht nicht den Baseline Requirements) geführt hat. Mich hatte damals ehrlich gesagt gewundert, dass es im Forum kaum Rückfragen dazu gab. Wobei der Zeitpunkt (Freitag, ca. 17:30 Uhr) sicherlich auch eine Rolle gespielt haben dürfte.
Nun, keine vier Wochen später, erleben wir mit SwissSign den nächsten Vorfall. Dieses Mal bei einem größeren Anbieter und im Bereich S/MIME statt TLS. Auch hier liegt die Ursache in einem Compliance-Thema, und erneut wurde ein Issue im Mozilla Bugtracker (Link) erstellt.
Aus meiner Sicht ist die genaue Ursache für die betroffenen Kunden zweitrangig. Entscheidend ist: Die Baseline Requirements definieren klar, innerhalb welcher Fristen betroffene Zertifikate widerrufen werden müssen – unabhängig von Wochenenden, Feiertagen oder anderen Umständen.
Was mich nachdenklich stimmt, ist die Einschätzung des Risikos solcher Szenarien. Offenbar wurde dieses zwar grundsätzlich betrachtet, aber eher als unwahrscheinlich eingestuft oder im Worst Case nicht ausreichend berücksichtigt. Zu dieser Einschätzung komme ich unter anderem aufgrund des kurzfristig bereitgestellten PowerShell-Skripts, das offensichtlich unter hohem Zeitdruck entstanden ist. Möglicherweise basierte es auf früheren, internen Tests – dennoch wirkte die Lösung eher reaktiv als vorbereitet.
In beiden Fällen lag die Vorlaufzeit bis zum Sperren bzw. Zurückziehen der Zertifikate bei maximal fünf Tagen. Allerdings gibt es Rahmenbedingungen, unter denen sich dieser Zeitraum auf 24 Stunden verkürzen kann. Das ist dann eine ganz andere Hausnummer. Im Vergleich dazu wirken fünf Tage fast komfortabel.
Positiv hervorheben möchte ich an dieser Stelle, dass zeitnah ein Workaround zur Verfügung gestellt wurde. Herzliches Dankeschön dafür an dieser Stelle! Dennoch würde ich mir als Kunde perspektivisch eine nachhaltigere Lösung wünschen. Eine entsprechende Funktionalität sollte aus meiner Sicht direkt im Produkt und vollständig über die UI abbildbar sein, ohne auf Skripte zurückgreifen zu müssen.
Mich würde daher interessieren:
- Wie bewertet ihr intern aktuell das Risiko solcher kurzfristigen Widerrufs-Szenarien?
- Gibt es Planungen, entsprechende Prozesse bzw. Funktionen künftig fest in das Produkt zu integrieren?
- Welche Lehren wurden aus den Vorfällen (D-Trust und SwissSign) gezogen?
Vielen Dank vorab und viele Grüße,
Daniel
