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.

2 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

Schreibe einen Kommentar