Der SwissSign-S/MIME-Fall

Wenn Dokumentation widerruft. PKI-Sanktionslogik.

Der SwissSign-S/MIME-Silver-Fall des Frühjahrs 2026 ist weder ein blosses Betriebsgeräusch noch ein Sicherheitsbeben. Er ist ein präziser Testfall dafür, wie die Public PKI mit Abweichungen umgeht, die kryptografisch wenig und governance-seitig sehr viel bedeuten. Wer daraus nur eine Support-Meldung macht, unterschätzt die Sache. Wer daraus einen Sicherheits-GAU schnitzt, überschätzt sie. Tragfähig ist nur die nüchterne Analyse.1

Hintergrund: Eine grosse Zahl von Zertifikaten wurde ersetzt oder widerrufen, obwohl die öffentlich zugängliche Primärquellenlage gerade nicht belegt, dass die real ausgestellten End-Entity-Zertifikate materiell von den S/MIME Baseline Requirements abwichen. Öffentlich belegt ist: eine Kollision zwischen öffentlicher Profildokumentation und dem normativen Profil für Mailbox-Validated-S/MIME-Zertifikate. Das genügte, um einen Incident auszulösen, einen engen Zeitkorridor für den Austausch zu erzwingen und Kunden wie Betreiber in operative Bewegung zu versetzen. Gerade weil die materielle Sicherheitslage relativ unspektakulär wirkt, tritt die eigentliche Architektur des Problems hervor. Sie liegt in Dokumentation, Auditierbarkeit, Revokationslogik und globalem Vertrauensmanagement.2

Am 17. April 2026 veröffentlichte SwissSign in Mozilla Bugzilla einen Preliminary Incident Report unter dem Titel „SwissSign: Certificate Profile error for S/MIME MV“. Darin erklärte SwissSign, Auditoren hätten am selben Tag einen Fehler in Kapitel 3.3.1.7 der öffentlichen CPR für S/MIME beanstandet. Betroffen war das Mailbox-Validated-Multipurpose-Profil. Die ältere CPR-Fassung beschrieb dort das Feld subject:commonName sinngemäss als „GivenName Surname or pseudo: Pseudonym“. Genau das ist für Mailbox-Validated nach den S/MIME Baseline Requirements falsch. Dort darf der commonName, sofern er überhaupt gesetzt wird, nur eine Mailbox Address enthalten. givenName, surname und pseudonym sind für dieses Profil als Subject-DN-Attribute gerade nicht zulässig.3

Gesichert ist die fehlerhafte Beschreibung in der CPR. Gesichert ist auch, dass SwissSign dieselbe öffentliche CPR am 17. April 2026 in Version 15 ergänzte und dort ausdrücklich festhielt, die CN-Definition werde zwar aus dem Template generiert, der tatsächliche CN im Endzertifikat werde aber stets aus dem Feld Email kopiert und enthalte deshalb immer die E-Mail-Adresse des Subjects. Gesichert ist ferner, dass SwissSign im Incident Report erklärte, stichprobenartig geprüfte betroffene Zertifikate seien „fully compliant with the S/MIME BR“. Das ist der entscheidende Punkt. Nicht bewiesen ist damit, dass alle betroffenen Leaf-Zertifikate materiell korrekt waren. Aber die öffentliche Primärquelle trägt klar die These, dass das Problem zunächst in der öffentlichen Profilbeschreibung lag und nicht in einer bereits nachgewiesenen technischen Fehlprofilierung der real ausgestellten Leafs.4

Ergänzende Partnerhinweise konkretisierten den operativen Radius. NoSpamProxy und SEPPmail nannten als betroffen die „SwissSign Personal S/MIME E-Mail ID Silver“-Zertifikate, ausgestellt zwischen dem 15. Juli 2025 und dem 17. April 2026. Als automatischer Widerrufstermin wurde der 22. April 2026 um 15:00 Uhr kommuniziert. Man kann diese Mitteilungen als Sekundärmaterial behandeln, nicht als tragende Primärquelle. Für die Rekonstruktion des Austauschdrucks sind sie dennoch nützlich, weil sie zeigen, wie die CA-seitige Governance-Entscheidung in den realen Betrieb hineinwirkte. Binnen weniger Tage wurde aus einem Dokumentations- und Profilkonflikt ein konkreter Handlungszwang für Kunden, Betreiber und Administratoren.5

Damit ist die erste grobe Fehlwahrnehmung erledigt. Wer hier von „nur einem Dokumentationsfehler“ spricht und das Wort „nur“ betont, redet mMn an der Public PKI vorbei. Öffentliche CP-, CPS- und CPR-Dokumente sind in diesem System keine dekorative Pose, kein PDF-Schmuck und kein juristisches Lametta für Auditoren. Sie sind öffentliche Zusicherung, historisiertes Auditobjekt und normativer Teil des Vertrauensvertrags. Die Mozilla Root Store Policy verlangt nicht bloss, dass diese Dokumente öffentlich und zugänglich sind. Sie verlangt auch Detailtiefe, Aktualisierung, Versionierung und operative Übereinstimmung. Die CCADB Incident Reporting Rules behandeln bereits Audit Findings und Verstösse gegen eigene CA-Dokumente als meldepflichtige Incidents. Wer also meint, ein Widerspruch zwischen realer Issuance und öffentlicher Profildokumentation sei schlicht ein redaktioneller Schönheitsfehler, hat das Regime nicht verstanden, in dem diese CAs operieren.6

Ebenso unerfreulich ist die gegenteilige Übertreibung, die aus jeder harten Revokationswelle sofort einen tiefen kryptografischen Vertrauensbruch ableiten will. Dafür trägt die öffentliche Aktenlage bislang nichts. Das betroffene CPR-Profil 3.3.1.7 nennt für subjectAltName eine obligatorische RFC822-E-Mail-Adresse, für certificatePolicies die OID 2.23.140.1.5.1.2 für Mailbox-Validated Multipurpose, für Extended Key Usage id-kp-emailProtection und für Key Usage die Kombination digitalSignature und keyEncipherment. Der Incident Report beanstandet diese Felder nicht. Die SwissSign-Produktseite zum E-Mail ID Silver beschreibt denselben Zertifikatstyp mit CN = common name: e-mail address, SAN-Eintrag mit der E-Mail-Adresse und dem ausdrücklichen Ausschluss weiterer antragstellerspezifischer Einträge. Die SwissSign-FAQ ergänzt, die Platzierung der E-Mail-Adresse im emailAddress-Attribut des Subject Distinguished Name sei veraltet und werde von SwissSign nicht mehr genutzt. Der öffentlich greifbare technische Konflikt konzentriert sich deshalb auf die dokumentierte commonName-Beschreibung. Für SAN, EKU, KeyUsage oder Policy OID liegt bislang kein öffentlich belegter materieller Leaf-Fehler vor.7

Ganz so sauber, wie SwissSigns Preliminary Report es nahelegt, ist die Sache indessen nicht. Die öffentlich auffindbare CP LCP enthält Formulierungen, die das Problem breiter erscheinen lassen als eine einzige verrutschte Tabellenzeile. Dort ist von S/MIME-Zertifikaten „with additional attributes in the CN besides e-mail address“ die Rede. Für Mailbox-Validated/LCP-Konstellationen ist das mindestens erklärungsbedürftig. Denn der normative Kern des MV-Profils besteht gerade darin, dass keine natürlichen Personenattribute als DN-Inhalt hineingemischt werden. Das ist kein Beweis dafür, dass SwissSign real falsche Zertifikate ausgestellt hat. Es ist aber ein klarer Hinweis darauf, dass das Dokumentationsproblem tiefer in die öffentliche Policy-Schicht reicht. Wer die Sache auf ein einzelnes redaktionelles Versehen schrumpft, glättet zu viel.8

Die regulatorische Logik, aus der heraus SwissSign konservativ reagieren musste, lässt sich Schritt für Schritt herleiten. Die S/MIME Baseline Requirements verlangen in Abschnitt 2.2, dass die CA ihre CP und oder CPS öffentlich offenlegt, diesen Requirements öffentlich Wirkung verleiht und ihre Praktiken darin korrekt beschreibt. Abschnitt 2.3 verlangt eine mindestens jährliche Überprüfung und Aktualisierung. Abschnitt 4.9.1.1 statuiert sodann die Revokationspflicht. Ein Subscriber-Zertifikat muss innerhalb von fünf Tagen widerrufen werden, wenn die Issuing CA erkennt, dass das Zertifikat nicht in Übereinstimmung mit dem Dokument selbst oder mit der anwendbaren CP und oder CPS ausgestellt wurde, oder wenn die CP und oder CPS den Widerruf verlangt. Liest man diesen Normtext streng, dann ist SwissSigns Reaktion nachvollziehbar. Sobald die CA den Konflikt zwischen öffentlichem Profil und tatsächlicher Issuance als relevanten Non-Compliance-Fall bewertet, läuft der Fünf-Tage-Mechanismus an.9

Man kann diese Lesart für hart halten. Man kann sie für bürokratisch halten. Man kann sie für governance-seitig überkalibriert halten. Man kann sie aber nicht einfach als willkürlich abtun. Gerade weil die Public PKI global, transitive und asymmetrisch vertrauensförmig organisiert ist, hängen Root Stores und relying parties an öffentlichen, prüfbaren Zusicherungen. Der relying party fragt die CA nicht täglich freundlich an, was sie diesmal eigentlich gemeint habe. Er sieht Zertifikat, Policy-OID, öffentliche CP/CPS/CPR, Revokationsstatus und gegebenenfalls einen Incident Report. Mehr hat er nicht. Die Strenge der Dokumentationsbindung ist also kein metaphysischer Fetisch, sondern eine Reaktion auf die Tatsache, dass Milliarden relying parties weder Cure Periods aushandeln noch individuelle Abweichungsgenehmigungen erteilen können. Die Public PKI lebt davon, dass öffentliche Zusicherungen nicht bloss Prospekte sind.10

Hier beginnt nun aber die eigentliche Verhältnismässigkeitsfrage. Denn die formale Nachvollziehbarkeit einer Massnahme beantwortet noch nicht, ob sie materiell überzeugend ist. Nimmt man SwissSigns eigene Aussage ernst, wonach stichprobenartig geprüfte betroffene Zertifikate vollständig BR-konform waren, dann ist der kryptografische Sicherheitsgewinn des Massenwiderrufs sehr gering. Es werden in diesem Modell keine kompromittierten Schlüssel aus dem Verkehr gezogen. Es werden keine missbräuchlich validierten Mailboxen bereinigt. Es werden keine inhaltlich falschen SAN-Einträge korrigiert. Es werden keine unzulässigen EKUs entfernt. Es werden vielmehr Zertifikate widerrufen, die nach materieller Lesart genau so hätten weiter existieren können, sofern man den Konflikt auf Dokumentation und nicht auf Leaf-Inhalt lokalisiert. Der Nutzen liegt dann fast vollständig in Governance-Disziplin, nicht in technischer Gefahrenabwehr.11

Dagegen stehen reale operative Kosten. Genau das zeigen die Partnerhinweise. Zertifikate müssen unter Zeitdruck erneuert, verteilt, installiert und in Mail- oder Gateway-Workflows sauber nachgezogen werden. Alte verschlüsselte Inhalte dürfen nicht unrettbar werden, also muss der private Schlüssel für frühere Verschlüsselungsvorgänge gegebenenfalls weiter aufgehoben bleiben. Signaturpfade, Automatisierungen, Benutzerkommunikation und Support eskalieren in kürzester Zeit. Die Kosten dieses Governance-Fehlers werden damit weitgehend an Kunden und Betreiber externalisiert. Die CA wahrt ihre Compliance-Position gegenüber Root Stores, während der betriebliche Schaden in den Infrastrukturen Dritter anfällt.12

Die stärksten Argumente für harte Disziplin auch bei reinen Dokumentationsverstössen sind dennoch substanziell und keineswegs bloss eine Strohpuppe aus Formalismus. Erstens schützt die Strenge die Integrität des Regimes. Wer nachträglich zu grosszügig zwischen „wirklich problematisch“ und „nur redaktionell“ unterscheidet, öffnet Tür und Tor für Ex-post-Ausreden. Jede CA wird dann ihren Fall als harmlos verkaufen. Zweitens schafft die harte Linie Vergleichbarkeit. CAs und Auditoren bewegen sich in einem globalen Feld; eine Bright-Line-Regel ist grob, aber für alle gleich. Drittens erzwingt sie Dokumentations- und Automatisierungsdisziplin. Gerade SwissSign selbst hat in einem früheren Incident nach einer CPR-Abweichung als Abhilfe beschrieben, öffentliche Profile und CA-System aus einer gemeinsamen Quelle zu generieren, damit genau solche Divergenzen künftig nicht mehr entstehen. Viertens bewahrt die Strenge die normative Funktion von CP und CPS. Wenn diese Dokumente im Ernstfall nie operative Konsequenzen auslösen, degenerieren sie tatsächlich zu Dekoration.13

Die Gegenargumente sind allerdings ebenfalls stark und verdienen mehr als ritualisierte Abfertigung. Der erste Einwand betrifft den Sicherheitsgewinn. Ist der Leaf materiell korrekt, bleibt die reale Risikoreduktion marginal. Der zweite betrifft den Betriebsnutzen des Systems. Ein Massenwiderruf, der technisch identische Neu-Ausstellung erzwingt, produziert Kosten, Reibung und potenzielle Ausfälle, ohne eine inhaltliche Fehlfunktion der Zertifikate zu beheben. Der dritte Einwand betrifft die Anreizökonomie. Wenn präzise CP/CPS/CPR-Texte bei jeder kleineren Inkonsistenz sofort eine Widerrufskeule auslösen, wächst der Anreiz, diese Dokumente absichtlich vage, weich oder generisch zu formulieren. Das System würde dann gerade dort Undurchsichtigkeit belohnen, wo es Transparenz zu fördern behauptet. Der vierte Einwand betrifft die fehlende Granularität des Sanktionsarsenals. Zwischen „nichts passiert“ und „Massenwiderruf binnen Tagen“ liegt erstaunlich wenig. Für Governance-verletzende, aber sicherheitsneutral wirkende Abweichungen ist das eine grobe Maschine.14

Diese Kritik ist nicht bloss private Gereiztheit genervter Administratoren. Sie wurde im Root-Store-Umfeld selbst explizit formuliert. In der Mozilla-CA-Program-Roundtable-Diskussion vom Mai 2025 wurde gerade das Problem benannt, dass kleinere CPS- oder Dokumentationsfehler trotz voller technischer BR-Konformität zu unnötigen und disruptiven Massenwiderrufen führen können. Im Diskussionsverlauf taucht sinngemäss genau das Bild auf, das hier passt: Ein gutgläubiger, trivialer Fehler in einem CPS kann dazu führen, dass hundert Prozent der betroffenen Zertifikate widerrufen und mit inhaltlich identischen Zertifikaten ersetzt werden müssen. Andere Stimmen hielten dagegen, gerade die Nichtverfügbarkeit eines individuellen Aushandlungsverhältnisses mit Milliarden relying parties rechtfertige die harte Bindung an CPS und Revokation. Der Streit ist also real, intern und systematisch. Er ist kein Jammern von aussen.15

Lehrreich ist hier besonders der Entrust-Fall von 2024. Dort ging es um 6’008 OV-TLS-Zertifikate, die technisch mit dem intendierten Profil und den Baseline Requirements übereinstimmten, während eine typographische und textplatzierungsbedingte CPS-Inkonsistenz im Raum stand. Entrust entschied sich zunächst gegen den Widerruf und argumentierte später sogar weitergehend, die Zertifikate seien bei Lektüre des CPS als Ganzes überhaupt nicht misissued gewesen, weil das Dokument selbst die BR priorisiere und andere CPS-Abschnitte die BR-konforme Ausstellung trugen. Dagegen wurde im Verfahren ausdrücklich eingewandt, ein Zertifikat, das den BRs, nicht aber der zur Ausstellungszeit offenbarten CPS-Praxis entspreche, bleibe dennoch non-compliant. Genau dieser Gegensatz macht sichtbar, wo die Bruchlinie verläuft. Nicht zwischen Sicherheit und Unsicherheit, sondern zwischen materialer Zertifikatskonformität und der normativen Verbindlichkeit öffentlicher CA-Selbstbeschreibung.16

SwissSign selbst ist in dieser Debatte kein unbeschriebenes Blatt. Bereits 2023 und 2024 trat SwissSign mit mehreren S/MIME-Incidents in Erscheinung, darunter falsch konfigurierte Key Usage, nicht erlaubte Key Usage bei LCP-Zertifikaten und ein Fall, in dem ausgestellte S/MIME-Zertifikate von der CPR abwichen, weil eine Kommentarlogik im Profiltext die tatsächlich zulässige Kombination von Key Usage-Bits unvollständig abbildete. Im Incident 1929189 widerrief SwissSign 30’967 Sponsor-Validated-S/MIME-Zertifikate und formulierte als Lehre gerade den Übergang zu einer Automatisierung, bei der die Quelle für die CPR identisch mit der Quelle für die CA-Konfiguration sein soll. Das ist relevant, weil es zeigt: SwissSign hatte das Grundproblem bereits erkannt, nämlich die Gefährlichkeit menschlich gepflegter, von der realen Issuance entkoppelter Dokumente. Umso interessanter ist, dass nun erneut eine öffentliche Profilabweichung aufschlägt.17

Damit weitet sich der Blick fast zwangsläufig auf die grössere PKI-Frage. Die populäre Nutzerthese lautet, wenn das ganze PKI-System strukturell kaputt sei, nütze auch die hunderttausendste Laufzeitverkürzung nichts. Diese These ist in ihrer rohen Form zu grob, trifft aber einen wahren Nerv. Sie trifft ihn dort, wo Governance-, Dokumentations- und Auditfehler in Rede stehen. Kürzere Zertifikatslaufzeiten verhindern keine falsche CPR-Zeile. Sie heilen keine schlechte CP. Sie zwingen keine bessere Synchronisierung von Systemkonfiguration und Policy-Text. Sie beseitigen keine global asymmetrische Trust-Topologie, in der wenige Root-Programme faktisch die Betriebsbedingungen des Marktes setzen. Der SwissSign-Fall ist dafür exemplarisch. Ob die betroffenen Zertifikate 825 Tage, 398 Tage oder 47 Tage gültig gewesen wären, hätte an der Existenz des Dokumentationskonflikts nichts geändert.18

Die Gegenthese, kürzere Laufzeiten seien deshalb nutzlos, geht aber zu weit. Laufzeitverkürzungen begrenzen sehr wohl andere Risikoklassen. Sie reduzieren die Wirkdauer veralteter Validierungsdaten, verkleinern das Fenster für unentdeckte Zustandsänderungen bei Mailbox- oder Identitätskontrolle und erleichtern die Durchsetzung neuer Profile, neuer Kryptografie und neuer Validierungsstandards. Die aktuelle S/MIME-BR-Architektur selbst lebt von solchen Zeitgrenzen für Wiederverwendung und Gültigkeit. Auch die TLS-Debatte um weitere Laufzeitverkürzungen baut auf genau dieser Logik auf. Man kann darüber streiten, wie gross der Sicherheitsgewinn im Verhältnis zum Betriebsaufwand ist. Man kann nicht redlich behaupten, die Verkürzung ändere nie irgendetwas. Sie ändert nur nicht die Art von Problem, die der SwissSign-Fall offenlegt.19

Noch steiler ist die Behauptung, in einer funktionierenden PKI könne man Zertifikate auch für tausend Jahre ausstellen. Für die öffentliche Public-Trust-PKI ist das schlicht falsch. Ein Zertifikat ist dort nicht bloss ein Container für einen mathematisch brauchbaren öffentlichen Schlüssel. Es ist ein zeitgebundener, regulatorisch gerahmter Tatsachenbefund über Mailbox-Kontrolle, Identität, Organisation, zulässige Profile und Betriebspraktiken. Diese Tatsachen altern. Menschen wechseln die Mailbox, Organisationen verschwinden, Merkmalsräume ändern sich, Policy-Standards entwickeln sich, Algorithmen werden obsolet, Root Stores verschieben ihre Anforderungen. Lange Laufzeiten würden in einem solchen Regime nicht Souveränität beweisen, sondern Trägheit zementieren. Für interne Enterprise- oder Closed-PKIs liegt die Sache anders, weil Vertrauensanker, relying parties und Durchsetzung in einer Hand liegen. Dort kann man längere Laufzeiten rational anders bewerten.20

Was also ist am kaputten PKI-System sachlich richtig, und was ist überzeichnet? Richtig ist, dass die Public PKI an mehreren Stellen systemisch grob arbeitet. Ihre Revokationsarchitektur ist schwerfällig und operativ teuer. Ihre Sanktionslogik kennt bei policy- und dokumentationsbezogenen Abweichungen oft nur die Wahl zwischen folgenlosem Hinnehmen und raschem Widerruf. Ihre Audit- und Dokumentationslogik zwingt zu Recht Präzision, hat aber zu wenig fein abgestufte Reaktionsformen für Fälle, in denen die materielle Sicherheitslage schwach betroffen ist. Ihre globale Trust-Topologie delegiert enorme normative Macht an wenige Root-Store-Programme und das sie umgebende Compliance-Ökosystem. Überzeichnet ist nur die Behauptung, deshalb sei die asymmetrische Kryptografie oder die Zertifikatsidee als solche wertlos. Der Defekt liegt nicht primär im mathematischen Kern, sondern in der Governance-Maschine, die ihn sozial und regulatorisch operationalisiert.21

Gerade deshalb wäre eine feinere Sanktionsarchitektur sinnvoll. Für Fälle wie diesen wäre ein Modell denkbar, das sofortige öffentliche Incident-Meldung, unverzügliche Dokumentkorrektur mit historischer Annotation, verschärftes Audit und gegebenenfalls einen obligatorischen Austausch beim nächsten Renewal kombiniert, sofern die materielle BR-Konformität der Leaf-Zertifikate belastbar belegt ist. Für wirklich materiell abweichende Zertifikate bliebe der schnelle Widerruf unberührt. Ein solches Modell würde den Governance-Zweck nicht aufgeben, aber die Kosten besser auf den tatsächlichen Sicherheitsgehalt der Abweichung abstimmen. Dagegen lässt sich einwenden, dies eröffne neue Grauzonen und damit neue Ausweichrhetorik. Das stimmt. Doch ein Regime, das auf sicherheitsneutrale Dokumentationsinkonsistenzen mit derselben Grundgeste reagiert wie auf substanzielle Fehlissuance, bezahlt seine Klarheit mit schlechter Proportionalität.22

Das Urteil über den SwissSign-S/MIME-Silver-Fall lässt sich deshalb nur zweistufig formulieren. Unter dem heutigen Regime war der Widerruf formal und governance-seitig nachvollziehbar. SwissSign entschied sich für die defensivste Linie, also für jene, die gegenüber Mozilla, CCADB, Auditoren und dem weiteren Root-Store-Umfeld am wenigsten Angriffsfläche bietet. Das ist aus Sicht einer CA rational. Materiell sicherheitlich wirkt die Massnahme, sofern die betroffenen Leaf-Zertifikate tatsächlich BR-konform waren, jedoch nur begrenzt verhältnismässig. Der Governance-Gewinn ist real. Der kryptografische Sicherheitsgewinn ist gering. Der betriebliche Schaden ist real und trägt sich nicht von selbst.23

Die eigentliche Lehre liegt deshalb nicht im alten Reflex, Public PKI entweder fromm zu verteidigen oder wütend zu verwerfen. Sie liegt in einer nüchternen Einsicht: Dieses System ist dort am schwächsten, wo es Governance und Technik ineinander verschraubt, aber seine Sanktionsformen nur grob moduliert. Ein Konflikt, der kryptografisch kaum und dokumentationsseitig stark brennt, wird dann mit einer Massnahme beantwortet, die technisch wenig rettet, governance-seitig aber Härte demonstriert. Das ist kein Sicherheits-GAU. Es ist aber auch kein belangloser Betriebsunfall. Es ist ein Lehrstück über eine Public PKI, deren Vertrauensvertrag an der Oberfläche oft viel präziser klingt, als ihre Reaktionsformen es tatsächlich sind.

In eigener Sache

Diese Arbeit entsteht nicht im luftleeren Raum. Sie kostet Zeit, Geld, Infrastruktur und sie läuft seit langem unter den Bedingungen eines dokumentierten Rechtsstreits, den ich öffentlich offengelegt habe. Wer dazu beitragen will, dass meine publizistischen Texte, meine technischen Projekte und diese Form unabhängiger Arbeit fortbestehen, kann meine Spendenseite teilen oder mich direkt unterstützen.

Unterstützungsmöglichkeiten:

https://www.gofundme.com/f/rechtsverteidigung-existenzsicherung-arbeitsgericht-lisbon

Oder direkt hier:

Spenden

Mille fois an alle Spender.

Quellen

  1. SwissSign Preliminary Incident Report in Mozilla Bugzilla, Bug 2033000 „SwissSign: Certificate Profile error for S/MIME MV“, angelegt am 17.04.2026; dazu die aktuellen S/MIME Baseline Requirements in Version 1.0.13. https://cabforum.org/working-groups/smime/requirements/ ↩︎
  2. SwissSign CPR S/MIME Version 14 und Version 15, insbesondere Profil 3.3.1.7, sowie Produktdokumentation zu E-Mail ID Silver.
    https://www.swisssign.com/en/certificate-webshop/email-id-silver.html ↩︎
  3. NoSpamProxy-Hinweis zum Austausch der betroffenen Zertifikate und SEPPmail-Statusmeldung mit Zeitraum 15.07.2025 bis 17.04.2026 und automatischem Widerruf am 22.04.2026. https://seppmail.statuspal.eu/ ↩︎
  4. Mozilla Root Store Policy, insbesondere zu öffentlicher Dokumentation, Aktualisierung und Bindung der CA-Operationen an CP/CPS. https://www.mozilla.org/about/governance/policies/security-group/certs/policy/ ↩︎
  5. CCADB Incident Report Guidance, insbesondere zur 72-Stunden-Offenlegung bei Incidents oder Audit Findings. https://www.ccadb.org/cas/incident-report ↩︎
  6. SwissSign FAQ zu S/MIME-Zertifikaten, insbesondere zur veralteten emailAddress-Platzierung im Subject Distinguished Name und zur Aufbewahrung privater Schlüssel für alte Verschlüsselungsvorgänge. https://www.swisssign.com/support/faq/zertifikate ↩︎
  7. SwissSign CP LCP, Version 4.0, mit der Formulierung zu Zertifikaten „with additional attributes in the CN besides e-mail address“. https://repository.swisssign.com/SwissSign_CP_LCP_R04.pdf ↩︎
  8. SwissSign Incident 1929189 „S/MIME certificates deviate from CPR“ mit 30’967 betroffenen Zertifikaten und der Remediation über eine gemeinsame Quelle für CPR und CA-Konfiguration. https://bugzilla.mozilla.org/show_bug.cgi?id=1929189 ↩︎
  9. SwissSign Incident 1851164 „S/MIME wrong key Usage“ sowie SwissSign Incident 1914023 „S/MIME LCP not-permitted key usage“ als weitere Vergleichsfälle profil- und compliancebezogener S/MIME-Fehler. https://bugzilla.mozilla.org/show_bug.cgi?id=1851164 ↩︎
  10. Entrust Incident 1890898 „Failure to revoke OV TLS – CPS typographical (text placement) error“ als Gegenfall technischer Zertifikatskorrektheit bei CPS-Konflikt. https://bugzilla.mozilla.org/show_bug.cgi?id=1890898 ↩︎
  11. Mozilla CA Program Roundtable „Results of 2025 Roundtable Discussion“ samt Folgekommentaren zur Problematik kleiner CPS-Fehler und daraus resultierender Massenwiderrufe. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/TqTpdOtOxfs ↩︎
  12. CA/Browser Forum zur aktuellen S/MIME-BR-Fassung und zur breiteren Debatte um Laufzeitverkürzungen im Zertifikatswesen. https://cabforum.org/working-groups/smime/requirements/ ↩︎
  13. SwissSign Incident 1929189 „S/MIME certificates deviate from CPR“, insbesondere zur Remediation über eine gemeinsame Quelle für CPR und CA-Konfiguration; ergänzend Mozilla Root Store Policy zur normativen Funktion öffentlicher CP/CPS-Dokumentation. https://bugzilla.mozilla.org/show_bug.cgi?id=1929189 ↩︎
  14. Mozilla CA Program Roundtable „Results of 2025 Roundtable Discussion“ samt Folgekommentaren zur Problematik kleiner CPS- bzw. Dokumentationsfehler und daraus resultierender Massenwiderrufe ohne nennenswerten materiellen Sicherheitsgewinn. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/TqTpdOtOxfs ↩︎
  15. Mozilla CA Program Roundtable „Results of 2025 Roundtable Discussion“, insbesondere die dort dokumentierte Debatte über triviale CPS-Fehler, identische Neu-Ausstellung und die Gefahr unnötiger Revokationswellen. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/TqTpdOtOxfs ↩︎
  16. Entrust Incident 1890898 „Failure to revoke OV TLS – CPS typographical (text placement) error“, einschliesslich der Argumentation zur technischen Korrektheit der Zertifikate trotz CPS-Konflikt und der Gegenposition im Mozilla-Verfahren. https://bugzilla.mozilla.org/show_bug.cgi?id=1890898 ↩︎
  17. SwissSign Incident 1929189 „S/MIME certificates deviate from CPR“; ergänzend SwissSign Incident 1851164 „S/MIME wrong key Usage“ und SwissSign Incident 1914023 „S/MIME LCP not-permitted key usage“ als Vergleichsfälle profil- und compliancebezogener S/MIME-Fehler. https://bugzilla.mozilla.org/show_bug.cgi?id=1929189 ↩︎
  18. CA/Browser Forum, S/MIME Baseline Requirements Version 1.0.13, insbesondere zu Offenlegungspflichten, Profilbindung und Laufzeit-/Validierungslogik; herangezogen für die Einordnung, dass Laufzeitverkürzungen Dokumentations- und Governancefehler nicht beheben. https://cabforum.org/working-groups/smime/requirements/ ↩︎
  19. CA/Browser Forum, S/MIME Baseline Requirements Version 1.0.13, insbesondere zu Gültigkeitsdauer, Wiederverwendung von Validierungsinformationen und dem sicherheitlichen Zweck zeitlicher Begrenzungen. https://cabforum.org/working-groups/smime/requirements/ ↩︎
  20. Mozilla Root Store Policy zur öffentlichen Vertrauensarchitektur und den Bindungen öffentlich vertrauender CAs. https://www.mozilla.org/about/governance/policies/security-group/certs/policy/ ↩︎
  21. Mozilla Root Store Policy; CCADB Incident Report Guidance; Mozilla CA Program Roundtable 2025. Zusammen herangezogen für die Einordnung der strukturellen Schwächen der Public PKI in Dokumentationsbindung, Auditlogik, Revokationsmechanik und Trust-Topologie. https://www.ccadb.org/cas/incident-report ↩︎
  22. Mozilla CA Program Roundtable „Results of 2025 Roundtable Discussion“, insbesondere die Diskussion möglicher differenzierterer Reaktionsformen auf dokumentationsbezogene Non-Compliance ohne unmittelbaren materiellen Zertifikatsfehler. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/TqTpdOtOxfs ↩︎
  23. CA/Browser Forum, S/MIME Baseline Requirements Version 1.0.13, insbesondere Abschnitt 4.9.1.1 zur Revokationspflicht; ergänzend Partnerhinweise von NoSpamProxy und SEPPmail zum operativen Austauschdruck und automatischen Widerruf am 22.04.2026. https://seppmail.statuspal.eu/ ↩︎

Deep Research Prompt

AUFGABE

Führe eine methodisch strenge Deep Research zum SwissSign-/S/MIME-Silver-Vorfall 2026 durch. Ausgangspunkt ist die Behauptung, dass SwissSign eine grosse Zahl von S/MIME-Silver-Zertifikaten wegen eines Dokumentations- bzw. CPR/CP/CPS-Fehlers widerrufen musste, obwohl die real ausgestellten Zertifikate nach materiellem Inhalt wohl den S/MIME Baseline Requirements entsprachen.

ARBEITSZIEL

1. Rekonstruiere den Vorfall so präzise wie möglich.
2. Identifiziere und beantworte die wesentlichen technischen, regulatorischen und governance-bezogenen Fragen.
3. Prüfe streng, ob es sich wirklich um einen blossen Dokumentationsfehler handelte oder ob doch materielle Profilabweichungen vorlagen.
4. Bewerte die Verhältnismässigkeit der Massenwiderrufe: pro und contra.
5. Beantworte die Grundsatzfrage, ob solche Vorfälle primär ein Symptom eines strukturell defekten Public-PKI-Systems sind und ob Laufzeitverkürzungen daran substantiell etwas ändern.

QUELLENHIERARCHIE

Arbeite streng primärquellenbasiert. Bevorzuge in dieser Reihenfolge:
A. CA/Browser Forum Baseline Requirements für S/MIME, einschlägige Ballots, Minutes, offizielle Working-Group-Dokumente.
B. Mozilla Root Store Policy, CCADB Incident Reporting Guidelines, Bugzilla-Incident-Reports, Mozilla-Wiki- oder Root-Store-Diskussionen.
C. Offizielle SwissSign-Dokumente: CPR, CPS, CP, System-Status, FAQ, Produktseiten, Change- oder Incident-Mitteilungen.
D. Technische Partnerhinweise nur ergänzend, z.B. NoSpamProxy, SEPPmail, Secardeo, andere Integrationspartner.
E. Sekundärquellen, Blogs und Foren nur zur Hypothesengewinnung, nicht als tragende Belegbasis.

ZITIERSTANDARD

- Belege jede tragende Tatsachenbehauptung direkt an der Aussage.
- Trenne strikt zwischen:
  a) gesicherten Fakten,
  b) plausiblen Schlussfolgerungen,
  c) offenen Punkten / nicht verifizierbaren Behauptungen,
  d) normativen Bewertungen.
- Wenn eine Primärquelle nicht öffentlich abrufbar ist, benenne das offen.
- Keine unbelegten Vermutungen.

KONKRETE PRÜFFRAGEN

I. REKONSTRUKTION DES VORFALLS
1. Welche Zertifikatstypen waren betroffen?
2. Welcher Ausstellungszeitraum war betroffen?
3. Wann wurde der Fehler entdeckt?
4. Welche Frist für Widerruf oder Austausch wurde gesetzt?
5. Gab es eine offizielle Incident-Meldung in Bugzilla / CCADB? Falls ja: genaue Bug-ID, Titel, Timeline, Root Cause, Action Items.
6. Welche Aussagen machte SwissSign selbst, welche Partner, welche Root-Store-Akteure?

II. TECHNISCHE MATERIALLAGE
7. Was genau stand in der CPR/CP/CPS bzw. im Certificate Profile?
8. Welche Felder waren problematisch? Insbesondere subject:commonName, subject:emailAddress, subjectAltName, givenName, surname, pseudonym, certificatePolicies, EKU, KeyUsage.
9. Enthielt die Dokumentation widersprüchliche Angaben zwischen Template-Definition und tatsächlicher Zertifikatserzeugung?
10. Gibt es Belege dafür, dass die realen End-Entity-Zertifikate tatsächlich BR-konform waren?
11. Falls möglich: anhand offizieller Beispielzertifikate oder dokumentierter Profile exakt herausarbeiten, ob der materielle Zertifikatsinhalt korrekt war.

III. RECHTLICH-REGULATORISCHE FRAGEN
12. Welche Normen greifen genau?
   - S/MIME Baseline Requirements
   - ggf. Mozilla Root Store Policy
   - ggf. CCADB Incident Reporting Guidelines
13. Reicht bereits eine Abweichung zwischen realer Issuance und CP/CPS/CPR für die Annahme von Misissuance?
14. Lösen rein dokumentarische Fehler nach geltendem Regelwerk zwingend einen Widerruf aus?
15. Gibt es Spielräume, Ausnahmen oder bekannte Streitstände in Root-Store-Diskussionen?
16. Welche Rolle spielt die öffentliche Dokumentation einer CA normativ: blosse Beschreibung, bindende Zusicherung, Auditobjekt oder alles zugleich?

IV. VERHÄLTNISMÄSSIGKEIT
17. Formuliere die stärksten Argumente FÜR harte Massenwiderrufe auch bei bloss dokumentarischen Fehlern.
18. Formuliere die stärksten Argumente GEGEN harte Massenwiderrufe in solchen Fällen.
19. Unterscheide sauber zwischen:
   - kryptografischem Sicherheitsgewinn,
   - Governance-/Auditierbarkeitsgewinn,
   - betrieblichem Schaden für Kunden,
   - Anreizwirkungen für CAs.
20. Prüfe insbesondere, ob harte Widerrufspflichten bei trivialen Dokumentationsfehlern perverse Anreize schaffen, CP/CPS absichtlich vage zu formulieren.
21. Identifiziere einschlägige Root-Store- oder Branchen-Diskussionen, in denen genau dieses Problem thematisiert wurde.

V. GRUNDSATZFRAGE PKI
22. Diskutiere die Nutzerthese:
   „Wenn das gesamte PKI-System strukturell kaputt ist, dann nutzt auch die hunderttausendste Laufzeitverkürzung nichts.“
23. Trenne analytisch:
   - Welche Probleme werden durch kurze Laufzeiten tatsächlich reduziert?
   - Welche Probleme werden dadurch gar nicht gelöst?
24. Beurteile die Aussage:
   „Wenn PKI in Ordnung wäre, könnte man Zertifikate auch für tausend Jahre ausstellen.“
   Hier bitte explizit unterscheiden zwischen:
   - öffentlicher Public-Trust-PKI,
   - interner Enterprise-/Closed-PKI,
   - End-Entity-Zertifikaten,
   - Root-/Intermediate-Lebenszyklen.
25. Bewerte, ob das Problem primär in der Kryptografie, in der Revokationsarchitektur, in der Root-Store-Governance, in der Audit-/Dokumentationslogik oder in der globalen Trust-Topologie liegt.

VI. VERGLEICHE UND ALTERNATIVEN
26. Gibt es vergleichbare frühere Fälle, in denen Zertifikate wegen CP/CPS-/Profil-Dokumentationsfehlern massenhaft widerrufen wurden, obwohl die Zertifikate technisch identisch wieder ausgestellt werden konnten?
27. Falls ja: Welche Lehren ergeben sich daraus?
28. Welche alternativen Sanktions- oder Remediationsmodelle wären denkbar?
   - öffentliche Incident-Meldung ohne Sofortwiderruf
   - verpflichtende Dokumentkorrektur mit historischer Annotation
   - verschärftes Audit
   - Austausch beim nächsten Renewal
   - nur gezielter Widerruf bei materiell abweichenden Zertifikaten
29. Bewerte diese Alternativen unter den Kriterien:
   - Sicherheit
   - Auditierbarkeit
   - Marktvertrauen
   - Betriebsstabilität
   - Anreizwirkung auf CAs

AUSGABEFORMAT

Gib die Ergebnisse in genau dieser Struktur aus:

1. Executive Summary
   - maximal 15 präzise Sätze
   - klare Antwort darauf, was gesichert ist, was offen bleibt und wie der Vorfall einzuordnen ist

2. Gesicherte Fakten
   - nummeriert
   - jede Aussage mit unmittelbarem Beleg

3. Materielle technische Analyse
   - genaue Darstellung der betroffenen Zertifikatsprofile und Felder
   - ggf. tabellarischer Soll-Ist-Vergleich

4. Regulatorische Analyse
   - welche Norm zieht welche Folge nach sich
   - genaue Ableitung, nicht bloss Behauptung

5. Verhältnismässigkeitsprüfung
   - Pro
   - Contra
   - eigene abgewogene Bewertung

6. Grundsatzanalyse zur PKI-Frage
   - Was an der Nutzerkritik zutrifft
   - Was überzeichnet ist
   - Welche strukturellen Schwächen tatsächlich vorliegen

7. Vergleichsfälle
   - kurz, aber präzise

8. Offene Punkte / Beleglücken
   - sauber markieren

9. Schlussurteil
   - in 10 bis 20 Sätzen
   - nüchtern, juristisch-technisch, ohne Polemik

STIL

- Hochsprachliches Deutsch
- nüchtern, analytisch, skeptisch
- keine moralische Pose
- keine unbelegten Zuspitzungen
- keine Übernahme von Marketingformulierungen von Herstellern oder CAs
- wo nötig: Schritt-für-Schritt-Herleitung der Schlussfolgerung

Deep Research Prompt – ChatGPT Bericht

2026.04.22_Deepsearch_ChatGPT_SwissSign_S_MIME-Silver-Vorfall_2026
Categories: Digitalisierung, IT, IT-Security, Kryptographie
Tags: , , , ,

You may also like

Search: