none
Welche GPO blockiert die Nutzung von S/Mime-Zertifikaten in Outlook 2016? RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo!

    Ein in Windows 10 importiertes S/Mime-Zertifikat ist auf anderen Rechnern in Outlook zum Signieren verwendbar, nicht aber auf unseren Rechnern. Leider jedoch ist unklar, womit wir dies blockieren. Vermutlich ist es irgendeine GPO-Einstellung, welche wir anpassen müssten.

    Any hints?

    Danke & Grüße

    Bernd


    Donnerstag, 10. September 2020 23:24
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    wie sieht denn dieses "kann auf unseren Rechnern nicht verwendet werden" technisch genau aus?

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 11. September 2020 04:50
    |
  • Question
    Anmelden
    0
    Anmelden

    Mist, Text verloren, da es eine Störung im TechNet gab ... Auf ein Neues:

    Hallo!

    Vorab noch diese Infos:
    Auf den Rechnern ist Windows 10 x64 enterprise, build 1809 (vereinzelt leider auch unkontrolliert und ungewollt 1903) mit Office 2016 x86 installiert. Updates kommen über unseren WSUS, auf einige Rechner hat das kumulative Mai-Update allerdings den Updatedienst kaputt gemacht. Auf einem der betroffenen Rechnern ist aber jedenfalls die o. g. Kombination vorhanden inkl. aller Patches.

    Die p12-Zertifikatsdatei wurde mit einem Doppelklick in den Windows-Zertifikatspeicher importiert.
    Anschließend wurde in Outlook über Optionen - Trust Center - E-Mail-Sicherheit die Option aktiviert, alle neuen E-Mails zu signieren ("Ausgehenden Nachrichten digitale Signatur hinzufügen").
    Dies klappt auf Rechnern, welche nicht zu unserer Domäne gehören, nicht aber eben auf den von uns verwalteten Computern. Es liegt somit nahe, dass wir eine Einstellung in einer GPO (MS-, keine anderen) korrigieren müssen, wissen aber nicht was in welcher GPO.
    Bei Nutzung von GPG4Win mit GpgOL oder Gpg4O ist klar, dass wir das entsprechende zusätzliche Add-In (dessen ID) freigeben müssen, das klappt auch. Aber wie gesagt wissen wir nicht, wie wir die (ja ohne Zusatz vorhandene) S/Mime-Funktionalität von Outlook wieder aktivieren können.

    Vielen Dank & viele Grüße

    Bernd

    Samstag, 12. September 2020 13:14
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    sorry, viel Text, aber die Frage trotzdem nicht beantwortet :-(

    Welcher Schritt klappt denn bei euch nicht? Seht ihr das Zertifikat nicht in der Auswahl, ist einer der Buttons auf dem Weg dorthin ausgegraut, gibt es eine Fehlermeldung?

    Es gibt unter Outlook\Sicherheit\Kryptographie diverse GPO-Einstellungen, welche die Funktion beeinflussen. Zieh ein GPRESULT für einen betroffenen User und schau, welche davon gesetzt sind, und aus welcher Policy sie kommen...

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Samstag, 12. September 2020 13:56
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo!

    Nun hoffentlich die gewünschten Infos:
    Da ich mich ehrlich gesagt gar nicht erinnern konnte, ob es Fehlermeldungen o. ä. gab, habe ich eine neue Maschine zum Testen angelegt.

    Die Zertifikatseinbindung habe ich gemäß dieser Anleitung vorgenommen:
    https://www.rz.uni-osnabrueck.de/Dienste/Mailing/E-Mail/Sicherheit/sicher_outlook2016.htm

    Will ich danach (nach einem Neustart von OL) eine neue E-Mail versenden, erscheint aber diese Meldung:
     Zertifikats-Fehlermeldung

    Diese erscheint nicht auf meinen anderen Rechnern, welche nicht in unserer Domäne sind.
    Klicke ich auf "Sicherheitseinstellungen ändern..." erscheinen das obere Dialogfenster, beim Klick auf "Einstellungen ändern..." das untere:
    Zertifikat-Sicherheitseinstellungen

    Auch wenn ich hier im ersten Dialogfenster unter "Sicherheit:" den Eintrag auswähle, welchen ich gemäß Punkt 12. der o. g. Anleitung vorgenommen habe bei "Name der Sicherheitseinstellung" ändert sich nichts, es kommt weiterhin die Meldung, dass das Zertifikat ungültig sei.

    gpresult steht noch aus.

    Grüße

    Bernd

    Montag, 14. September 2020 21:17
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    da kommen wir der Sache schon näher ;-)

    "Das Zertifikat ist ungültig" kann mehrere Dinge bedeuten, die evtl. nur bedingt was mit GPOs mit Deiner Umgebung zu tun haben:

    1. Dem Zertifikat wird nicht vertraut --> Zeig mal das Zertifikat, bzw. den letzten Reiter "Zertifizierungspfad" auf einer Domänen-Maschine
    2. Dem Zertifikat wird im Prinzip vertraut, es kann aber aufgrund der Beschaffenheit der Umgebung (Firewall, Proxy, Policy usw.) nicht geprüft werden, ob es nicht zurückgezogen worden ist --> certutil -verify
    3. Das Zertifikat ist aus PKI-Sicht in Ordnung, die dort erfasste e-Mail-Adresse stimmt aber nicht mit der vom MAPI-Profil überein, und es ist die GPO für Outlook gesetzt, dass diese Übereinstimmung geprüft werden soll
    4. ein paar weitere Sachen, aber die obigen sind die Basics

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 15. September 2020 06:48
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij,

    Zu 1) "Das Zertifikat ist gültig"
    Im Register "Zertifizierungspfad" findet sich dies:
    "Zertifizierungsstatus: Dieses Zertifikat ist gültig."
    Eine explizite Aussage zum Vertrauen findet sich jedoch nicht.

    Zu 2) Auf einem Windows 7-PC mit Outlook 2010 gibt es keine Probleme mit dem S/Mime-Zertifikat - aber sowohl unter Win10 wie auch besagtem Win7-Rechner gibt es Fehlermeldungen bei certutil -verify [Dateipfad und -name].

    Die cmd habe ich als Admin gestartet, den Pfad zur p12-Datei habe ich mit und ohne Anführungszeichen angegeben, immer kommt diese Fehlermeldung:

    LoadCert(Cert) hat ASN1 Unerwartetes Datenende. 0x80093102 (ASN: 258 CRYPT_E_ASN1_EOD) zurückgegeben.
    CertUtil: -verify-Befehl ist fehlgeschlagen: 0x80093102 (ASN: 258 CRYPT_E_ASN1_EOD)
    CertUtil: ASN1 Unerwartetes Datenende.

    Da es aber sowohl unter Win7 wie W10 zu diesem Fehler kommt, die Nutzung des Zertifikates aber unter Win7 klappt, nehme ich eigentlich nicht an, dass dies eine Rolle spielt.

    Zu 3) Grundsätzlich handelt es sich sowohl beim Postfach wie auch beim S/Mime-Zertifikat um dieselbe E-Mail-Adresse. Aber in der Tat müssen wir als Anmeldenamen eben unseren Kontonamen angeben - aber wie gesagt, unter Win7 gibt es unter denselben Voraussetzungen ja kein Problem.

    Danke & Grüße

    Bernd

    Mittwoch, 16. September 2020 19:14
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    für certutil -verify musst Du das Zertifikat mal *ohne* Private Key exportieren, und dann brauchst Du die CMD auch nicht mit erhöhten Rechten zu starten.

    Steht im Zertifizierungspfad denn die ausstellende CA und die Root-CA dazu?

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 16. September 2020 20:17
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij, 

    nun nur mit dem öffentlichen Schlüssel (*cer):
    Hier verläuft die Prüfung erfolgreich.
    Ich habe aber nicht den Eindruck, dass ich hier alles davon angeben sollte, deshalb nur Auszüge. Sollte weiteres wichtig sein, bitte mitteilen. Es geht übrigens bei allen Betroffenen um ein persönliches S/Mime-Zertifikat, das vom DFN ausgestellt wurde:

    CN=DFN-Verein Global Issuing CA
    OU=DFN-PKI
    O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.
    C=DE
    (...)
    ------------------------------------

    Verfizierte Ausstellungsrichtlinien:

        1.3.6.1.4.1.22177.300.1.1.4

    Verfizierte Anwendungsrichtlinien:

        1.3.6.1.5.5.7.3.2 Clientauthentifizierung

        1.3.6.1.5.5.7.3.4 Sichere E-Mail

    Das Zertifikat ist ein Endeinheitzertifikat

    Sperrstatussüberprüfung des untergeordneten Zertifikats erfolgreich abgeschlossen.

    CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

    Die CA und Root-CA finden sich im Pfad, sieht m. E. alles gut aus:
    T-TeleSec GlobalRoot Class 2
    - DFN-Verein Certification Authority 2
    -- DFN-Verein Global Issuing CA
    --- Bernd Leutenecker

    Und weiterhin mit dem Status "Das Zertifikat ist gültig."

    Danke & Grüße

    Bernd

    Mittwoch, 16. September 2020 21:10
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Evgenij, 

    inzwischen hat eine Kollegin eine Policy-Einstellung gefunden, welche nach dem Abschalten beim Test das Problem mit den persönlichen DFN-Zertifikaten löste.

    Bei der Vorbereitung der vielen Policies wurden Empfehlungen des BSI befolgt (https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-CS/BSI-CS_139.pdf?__blob=publicationFile&v=8).
    Dort gibt es die Policy "Require SuiteB algorithms for S/MIME operations", welche gemäß BSI-Empfehlung aktiviert war. 
    Nach dem Abschalten dieser Richtlinie klappte es jedenfalls bei meinen Tests. User-Rückmeldungen stehen noch aus, aber ich sehe keinen Grund (gleiche OU), dass es dort nicht genauso klappen würde.
    Zwar muss das erst noch genauer geprüft werden, aber es sieht also so aus, dass die Nutzerzertifikate des DFN nicht den Anforderungen des BSI entsprechen.

    Danke für die umfangreiche Unterstützung!

    Viele Grüße

    Bernd


    Donnerstag, 17. September 2020 12:26
    |