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.

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

  1. Ich habe gerade versucht, ein S/Mime-Zertifikat bei actalis zu bestellen und das dann abgebrochen.
    Warum benötigen die meine Tax-ID (als Privatmensch)?

    Antworten
  2. Actalis stellt Zertifikate aus deren private Key sie selber erstellen. Genau genommen bekommt man also ein kompromittiertes Zertifikat!!!! Darauf sollte man vielleicht hinweisen.

    Antworten
  3. Weiß jemand, ob man bei Actalis das Free Zertifikat verlängern kann?
    Mein Actalis Free Zertifikat läuft im Sept 2021 aus.
    Ich wollte ein Neues ausstellen, aber es kommt die Fehlermeldung, dass aktuell ein noch gültiges Zertifikat für meine E-Mail-Adresse vorhanden ist.

    Gibt es in 2021 immer noch keine weiteren Anbieter, die kostenlose S/MIME-Zertifikat für wenigstens ein Jahr ausstellen?
    So wird das doch nie was, mit verschlüsselten Mails in der breiten Masse.

    DGNcert wäre vermutlich interessant, wenn die es schaffen würden, dass ihr Root-Zertifikat in den Windows-Zertifikatsstore aufgenommen wird.
    https://www.dgn.de/e-mail-zertifikat-dgncert/

    Antworten
    • Bezüglich Actalis kann ich nichts sagen.

      Bei WISeKey sind S/MIME-Zertifikate kostenlos ja auch nur noch drei Monate gültig, aber neu kann man auch gegen ein kleines Entgelt (9.99 USD) Zertifikate mit einem Jahr Gültigkeit und mit Zusatznutzen (Name im Zertifikat statt nur E-Mail, PDF-Signatur-Support) beziehen. Den Preis finde ich OK und so habe ich mir das geleistet.

      Antworten
    • @Matthias
      Das Problem hatte ich auch, ich habe einfach ein neues Zertifikat erstellt, so steht es auch in Anleitung von Actalis:

      3.3 I&A for Renewal Requests
      Certificate “renewal” in the strict sense is not provided for. If the subscriber would like to get a new certificate before the current certificate expires, he/she will have to proceed in the same way as for the first certificate issuance. The processing and checks made by the CA are always the same.

      Liebe Grüsse, Elena

      Antworten
      • @Elena
        Hast Du Dein neues Zertifkat vor Ablauf des alten erstellt?

        Ich wollte ein neues Zertifkat erstellen.
        Das funktionert aber wohl erst, wenn das alte abgelaufen ist.

        Zitat von oben:
        ==================================================
        Mein Actalis Free Zertifikat läuft im Sept 2021 aus.
        Ich wollte ein Neues ausstellen, aber es kommt die Fehlermeldung, dass aktuell ein noch gültiges Zertifikat für meine E-Mail-Adresse vorhanden ist.
        ==================================================

        Antworten
    • Danke für den Hinweis. Sollte ich S/MIME nicht komplett hinwerfen weis ich jetzt zumindest welche Firma ganz sicher NICHT für Zertifikate bezahlt wird. Schade, dass CACert es nie geschafft hat ihre Prozesse so hinzubekommen, dass ihr Root Certificat vertrauenswürdig wurde.

      Antworten
    • Ich habe heute eine entsprechende Mail von „WISeKey News“ bekommen. Auszug:
      „… one of our actions is to provide free digital certificates to all users willing to secure their email and protect their information.
      We will keep this commitment and you will be able to keep using these free certificates, but starting in April 2021, the validity of these free certificates will be reduced to three months. Once your certificates expire, you’ll be allowed to obtain a renewal at no cost.“

      Ich kenne eh kaum jemanden, der verschlüsselt mailt (und wenn, dann mit OpenPGP); deshalb werde ich mein bestehendes S/MIME-Zertifikat im Sommer einfach auslaufen lassen.

      Antworten
  4. Sowohl bei Wiseid als auch Actalis wird der private Schlüssel aber auf Servern von denen erstellt, wenn ich das richtig sehe? Das ist sicherheitstechnisch genau das, was man nicht möchte…

    Antworten
  5. 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
  6. 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
  7. 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
  8. 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

Schreibe einen Kommentar