Kostenloses S/MIME Zertifikat (Update April 2020)

Im Januar diesen Jahres hatte ich noch über kostenlose S/MIME Zertifikate von WISeID berichtet. Leider musste ich mittlerweile feststellen, dass neu beantragte Zertifikate dieser CA nicht mehr als vertrauenswürdig gelten. Aufgefallen ist mir dies, als ich ein neues 1 Jahres Zertifikat von WISeID angefordert habe. Die CA stellt nach wie vor die Zertifikate aus, jedoch weigerte sich NoSpamProxy Mails mit dem neuen Zertifikat zu signieren und zu verschlüsseln. Hier mal ein Screenshot des Fehlers:

NoSpamProxy S/MIME Zertifikat

Die Fehlermeldung in NoSpamProxy lautete “Nicht vertrauenswürdiges Stammzertifikat”. Dies machte mich stutzig, denn Windows hatte augenscheinlich kein Problem mit dem Zertifikat und sieht es als gültig an:

NoSpamProxy S/MIME Zertifikat

Erst mit der unbürokratischen Hilfe des Herstellers von NoSpamProxy sind wir dem Problem gemeinsam auf die Schliche gekommen. Während Windows das S/MIME Zertifikat augenscheinlich noch als gültig anzeigt, wie oben zu sehen ist, wurde der Root CA “OISTE WISeKey Global Root GB CA” mehr oder weniger aus Vertrauen entzogen. Allerdings erst für neue Zertifikate, nicht für die Alten.

Im Eventlog von NoSpamProxy war dazu die folgende Meldung zu finden (gekürzt):

  • Protokollname: Net at Work Mail Gateway
  • Quelle: Gateway Role
  • Ereignis-ID: 9354
  • Ebene: Informationen
  • Meldung: The validation of the certificate issued to E=frank@frankysweb.de, CN=frank@frankysweb.de, OU=Person’s Identity not Verified – WISeID Free Certificates (Thumbprint C4E36E94410D57AC8F04DAE4D150AC89E74C24C7, valid from 30.03.2020 22:07:24 to 31.03.2021 22:23:00) failed. The validation results for each certificate in the chain are displayed below.

Im Event findet sich dann auch der Hinweis, warum die Validierung des Zertifikats fehlgeschlagen ist:

Kostenloses S/MIME Zertifikat (Update April 2020)

Die Root CA “OISTE WISeKey Global Root GB CA” hat des Status “ExplicitDistrust”. Nach weiteren Recherchen ist dann der folgende Microsoft Artikel aufgefallen:

Hier findet sich die sich dann die OISTE CAs mit dem Status “NotBefore”:

Microsoft NotBefore bzw. ExplicitDistrust

Im verlinkten Artikel findet sich dann auch ein kleiner unscheinbarer Hinweis:

Microsoft NotBefore bzw. ExplicitDistrust

Microsoft hat also den OISTE (WISeID) Root Zertifikaten das Vertrauen entzogen, ohne die CAs aus dem Speicher für “Vertrauenswürdige Stammzertifizierungsstellen” zu entfernen. Technisch gesehen macht diesen Vorgehen Sinn, denn mit dem NotBefore bzw. ExplicitDistrust Flag kann Microsoft bestimmen, ab welchem Zeitpunkt Zertifikate einer CA als nicht mehr vertrauenswürdig gelten. Im meinem Fall war das alte Zertifikat also noch vertrauenswürdig, das neue Zertifikat allerdings nicht mehr. Warum der CA das Vertrauen entzogen wurde bleibt allerdings offen.

NoSpamProxy verhält sich hier also völlig korrekt und übernimmt die Vorgaben des Betriebssystems. Windows selbst zeigt den Status allerdings nicht so schön an wie NoSpamProxy. Hätte Windows hier ebenfalls angezeigt, dass mein neues Zertifikat aufgrund dieses Updates nicht mehr als vertrauenswürdig gilt, wäre die Fehlersuche um einiges kürzer gewesen.

Auf diesem Weg möchte ich daher einmal ein großes Dankeschön für den unkomplizierten und hervorragenden Support seitens des Herstellers von NoSpamProxy loswerden.

Übrigens: Actalis ist damit die letzte mir bekannte CA, welche noch kostenlose S/MIME Zertifikate ausstellt. Es wird wirklich Zeit, dass Let’s Encrypt diese Aufgabe übernimmt.

7 Gedanken zu „Kostenloses S/MIME Zertifikat (Update April 2020)“

  1. Danke für die Info.
    Ich habe mir am 25.01.2020 auch ein privates Zertifikat ausstellen lassen.
    Unser dienstliches Mail-Security-Gateway meckert aber das Zertifikat auch an.
    Habe bisher nicht verfolgt warum genau, weil es in Windows als gültig gilt.

    Antworten
  2. Soweit ich das in den Trusted-Root Updates von Microsoft sehe wurde dem Zertifikat lediglich die CodeSigning-EKU (Extended Key Usage) entzogen, nicht jedoch andere Verwendungszwecke. Daher sollte dies auf die Validierung des S/MIME-Zertifikats keinen negativen Einfluss haben, wenn die richtige EKU verwendet wird bei der Verifikation.
    Probier es doch mal mit dem Cmdlet Test-Certificate aus…
    Und siehe auch https://www.sysadmins.lv/blog-en/constraining-extended-key-usages-in-microsoft-windows.aspx

    Antworten
  3. Hallo,
    kannst du bitte etwas detailierter erklären warum die Root-CA ungültig sein soll? Ich habe bei mir die Powershell geöffnet und mir mit certutil die aktuelle Liste von WindowsUpdate geladen und authroot aus dem cab extrahiert.

    certutil -dump authroot.stl

    liefert dann den dump unten für WiseKey.
    Ich lese es so, dass AB dem Oktober 2019 die CA auch für Code-Signing gut ist, aber nicht davor. Um eine Funktion zu disablen müsste die Gültigkeit weit in der Zukunft beginnen.
    Sektion 1.3.6.1.4.1.311.10.11.126 ist das relevante.

    Subject Identifier: 0ff9407618d3d76a4b98f0a8359e0cfd27accced
    8 attributes:

    Attribute[0]: 1.3.6.1.4.1.311.10.11.126 (CERT_NOT_BEFORE_FILETIME_PROP_ID)
    Value[0][0], Length = a
    01.10.2019 02:00

    Attribute[1]: 1.3.6.1.4.1.311.10.11.127 (CERT_NOT_BEFORE_ENHKEY_USAGE_PROP_ID)
    Value[1][0], Length = e
    Enhanced Key Usage
    Code Signing (1.3.6.1.5.5.7.3.3)

    Attribute[2]: 1.3.6.1.4.1.311.10.11.29 (CERT_SUBJECT_NAME_MD5_HASH_PROP_ID)
    Value[2][0], Length = 12
    80fec0dffcb24de4ebe73751db8db1ff

    Attribute[3]: 1.3.6.1.4.1.311.10.11.20 (CERT_KEY_IDENTIFIER_PROP_ID)
    Value[3][0], Length = 16
    350fc836635ee2a3ecf93b6615ce5152e3919a3d

    Attribute[4]: 1.3.6.1.4.1.311.10.11.83 (CERT_ROOT_PROGRAM_CERT_POLICIES_PROP_ID)
    Value[4][0], Length = 21
    Certificate Policies
    [1]Certificate Policy:
    Policy Identifier=2.23.140.1.1
    [1,1]Policy Qualifier Info:
    Policy Qualifier Id=Root Program Flags
    Qualifier:
    c0

    Attribute[5]: 1.3.6.1.4.1.311.10.11.98 (CERT_AUTH_ROOT_SHA256_HASH_PROP_ID)
    Value[5][0], Length = 22
    6b9c08e86eb0f767cfad65cd98b62149e5494a67f5845e7bd1ed019f27b86bd6

    Attribute[6]: 1.3.6.1.4.1.311.10.11.9 (CERT_ENHKEY_USAGE_PROP_ID)
    Value[6][0], Length = 36
    Enhanced Key Usage
    Server Authentication (1.3.6.1.5.5.7.3.1)
    Client Authentication (1.3.6.1.5.5.7.3.2)
    Code Signing (1.3.6.1.5.5.7.3.3)
    Time Stamping (1.3.6.1.5.5.7.3.8)
    Secure Email (1.3.6.1.5.5.7.3.4)

    Attribute[7]: 1.3.6.1.4.1.311.10.11.11 (CERT_FRIENDLY_NAME_PROP_ID)
    Value[7][0], Length = 42
    OISTE WISeKey Global Root GB CA

    Antworten
  4. Schau noch einmal genau hin:
    Da steht „revoked“.
    Habe bei WiseID eben einmal testweise ein S/MIME Zertifikat bestellt.
    Die Kette ist dabei eine andere(!) und das Zertifikat und -Kette funktionieren „full trusted“.
    Insofern bin ich dankbar für den Tipp, denn es gibt damit eine Alternative zu Actalis.

    Antworten

Schreibe einen Kommentar