4
Fehler bei SMIME Zertifikatskette aus LDAP Adressbuch
Hallo zusammen,
ich habe ein etwas seltsames Problem mit SMIME-Zertifikaten aus einem LDAP Adressbuch.
Kurze technische Erklärung:
Wir verwenden einen externen Dienst, der uns SMIME-Zertifikate von Partnern zur Verfügung stellt (certBox).
Hierzu binde ich ein zusätzliches LDAP-Adressbuch in Outlook ein. Wenn wir nun an einen Partner verschlüsselte Mails verschicken möchten, dann können wir ohne den klassischen SMIME-Mail-Pingpong zum Austausch der Zertifikate verschlüsselt kommunizieren, da wir die Zertifikate vom dem Partner-Directory erhalten.
Ich habe das soweit eingerichtet, aber beim Versenden an eine Partner-Mailadresse erhalte ich trotzdem den Fehler im Outlook, dass kein Zertifikat gefunden wurde oder das Zertifikate nicht valide ist.
Fehleranalyse inkl. Wireshark-Mitschnitt hat gezeigt, dass das externe Directory ein korrektes Zertifikat zurück liefert. Die weitere Analyse hat dann gezeigt, dass die Zertifikatskette nicht erstellt werden konnte. Hier die Auszüge aus den Events mit Event-ID 11 und 19 im CAPI2-Eventlog:
--- EVENT-ID 11 ---
Protokollname: Microsoft-Windows-CAPI2/Operational
Quelle: Microsoft-Windows-CAPI2
Datum: 07.03.2025 14:09:02
Ereignis-ID: 11
Aufgabenkategorie:Kette erstellen
Ebene: Fehler
Schlüsselwörter:Pfadsuche,Pfadüberprüfung
<TrustStatus>
<ErrorStatus value="1010040" CERT_TRUST_REVOCATION_STATUS_UNKNOWN="true" CERT_TRUST_IS_OFFLINE_REVOCATION="true" CERT_TRUST_IS_PARTIAL_CHAIN="true" />
<InfoStatus value="0" />
</TrustStatus>
<RevocationInfo>
<RevocationResult value="80092013">Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.</RevocationResult>
</RevocationInfo>
<EventAuxInfo ProcessName="OUTLOOK.EXE" />
<CorrelationAuxInfo TaskId="{E8CE0C50-5C8A-4DB6-BA90-A62AC596DC8C}" SeqNumber="3" />
<Result value="800B010A">Eine Zertifikatkette zu einer vertrauenswürdigen Stammzertifizierungsstelle konnte nicht aufgebaut werden.</Result>
</CertGetCertificateChain>
Das seltsame ist, wenn ich das SMIME-Zertifikat des Benutzers herunterlade und manuell öffne, dann ist die Kette vorhanden in Ordnung und ich kann ab dann problemlos SMIME-Verschlüsselt kommunizieren.
Meine erste Idee war Einschränkungen durch unsere Zentrale, daher habe ich ein vollständig neu installiertes System verwendet und das gleiche Ergebnis erhalten. Scheinbar keine GPO- oder Intune-Policy.
Meine nächste Idee war, ob Outlook irgendein Problem mit Proxy-Settings etc. hat und daher die CRL nicht prüfen kann. Ich sehe aber im Wireshark keine geblockte Verbindung. Auch in der Firewall sehe ich keine blockierte Anfrage.
Kenn jemand ein solches Verhalten. Der Service Provider der certBox sagt mir, dass alles normal konfiguriert wäre.
Kennt jemand ein solches Verhalten?
Bin für jeden Tipp dankbar.
Vielen Dank!
Tsukaito
ich habe ein etwas seltsames Problem mit SMIME-Zertifikaten aus einem LDAP Adressbuch.
Kurze technische Erklärung:
Wir verwenden einen externen Dienst, der uns SMIME-Zertifikate von Partnern zur Verfügung stellt (certBox).
Hierzu binde ich ein zusätzliches LDAP-Adressbuch in Outlook ein. Wenn wir nun an einen Partner verschlüsselte Mails verschicken möchten, dann können wir ohne den klassischen SMIME-Mail-Pingpong zum Austausch der Zertifikate verschlüsselt kommunizieren, da wir die Zertifikate vom dem Partner-Directory erhalten.
Ich habe das soweit eingerichtet, aber beim Versenden an eine Partner-Mailadresse erhalte ich trotzdem den Fehler im Outlook, dass kein Zertifikat gefunden wurde oder das Zertifikate nicht valide ist.
Fehleranalyse inkl. Wireshark-Mitschnitt hat gezeigt, dass das externe Directory ein korrektes Zertifikat zurück liefert. Die weitere Analyse hat dann gezeigt, dass die Zertifikatskette nicht erstellt werden konnte. Hier die Auszüge aus den Events mit Event-ID 11 und 19 im CAPI2-Eventlog:
--- EVENT-ID 11 ---
Protokollname: Microsoft-Windows-CAPI2/Operational
Quelle: Microsoft-Windows-CAPI2
Datum: 07.03.2025 14:09:02
Ereignis-ID: 11
Aufgabenkategorie:Kette erstellen
Ebene: Fehler
Schlüsselwörter:Pfadsuche,Pfadüberprüfung
<TrustStatus>
<ErrorStatus value="1010040" CERT_TRUST_REVOCATION_STATUS_UNKNOWN="true" CERT_TRUST_IS_OFFLINE_REVOCATION="true" CERT_TRUST_IS_PARTIAL_CHAIN="true" />
<InfoStatus value="0" />
</TrustStatus>
<RevocationInfo>
<RevocationResult value="80092013">Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.</RevocationResult>
</RevocationInfo>
<EventAuxInfo ProcessName="OUTLOOK.EXE" />
<CorrelationAuxInfo TaskId="{E8CE0C50-5C8A-4DB6-BA90-A62AC596DC8C}" SeqNumber="3" />
<Result value="800B010A">Eine Zertifikatkette zu einer vertrauenswürdigen Stammzertifizierungsstelle konnte nicht aufgebaut werden.</Result>
</CertGetCertificateChain>
Das seltsame ist, wenn ich das SMIME-Zertifikat des Benutzers herunterlade und manuell öffne, dann ist die Kette vorhanden in Ordnung und ich kann ab dann problemlos SMIME-Verschlüsselt kommunizieren.
Meine erste Idee war Einschränkungen durch unsere Zentrale, daher habe ich ein vollständig neu installiertes System verwendet und das gleiche Ergebnis erhalten. Scheinbar keine GPO- oder Intune-Policy.
Meine nächste Idee war, ob Outlook irgendein Problem mit Proxy-Settings etc. hat und daher die CRL nicht prüfen kann. Ich sehe aber im Wireshark keine geblockte Verbindung. Auch in der Firewall sehe ich keine blockierte Anfrage.
Kenn jemand ein solches Verhalten. Der Service Provider der certBox sagt mir, dass alles normal konfiguriert wäre.
Kennt jemand ein solches Verhalten?
Bin für jeden Tipp dankbar.
Vielen Dank!
Tsukaito
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671970
Url: https://administrator.de/forum/fehler-bei-smime-zertifikatskette-aus-ldap-adressbuch-671970.html
Ausgedruckt am: 17.04.2025 um 18:04 Uhr
4 Kommentare
Neuester Kommentar
Nimm die URL der CRL aus dem CA Zertifikat und füge sie von Hand in einen Browser ein und prüfe ob sie damit abrufbar ist.
Wenn nicht, hast du dein Problem. Dann ist entweder die Sperrliste beim CA Anbieter offline oder aus deinem Netz gibt es Abrufprobleme oder das Routing zur Sperrliste läuft bei deinem Provider ins leere.
Nutzt ihr einen Proxy ? Wenn ja, bitte die Settings unter netsh winhttp prüfen ob dort der Proxy dann auch hinterlegt ist, denn darüber ruft Windows die CRLs ab.
Wenn nicht, hast du dein Problem. Dann ist entweder die Sperrliste beim CA Anbieter offline oder aus deinem Netz gibt es Abrufprobleme oder das Routing zur Sperrliste läuft bei deinem Provider ins leere.
Nutzt ihr einen Proxy ? Wenn ja, bitte die Settings unter netsh winhttp prüfen ob dort der Proxy dann auch hinterlegt ist, denn darüber ruft Windows die CRLs ab.
Hallo BiberMan,
Danke für die schnelle Antwort.
Die URL der CRL habe ich bereits über den Browser geprüft und funktioniert - ich kann die CRL herunterladen und öffnen. Das seltsame ist, dass ich das Zertifikat manuell herunterladen und manuell öffnen kann (Doppelklick) - Kette ist dann auch okay. Danach kann auch Outlook auf die Kette zugreifen und ich kann verschlüsselt senden.
Proxy ist nicht in Verwendung weder im System noch transparent. Hab aber trotz allem einen Proxy Reset durchgeführt.
Was ich noch gesehen habe in der Analyse war, dass die Zwischenzertifikate für die Kette nicht heruntergeladen werden, da Outlook die CRL scheinbar nicht prüfen kann (so zumindest das CAPI2-Event). Wenn ich das Zertifikat manuell öffne, dann werden die fehlenden Zertifikate nachgeladen und die Kette ist vollständig.
In welchem Benutzerkontext wird denn die CRL überprüft? SYSTEM? NETWORK? Könnte es hier noch ein Proxy-Setting geben? Ich habe schon den depperten Haken in den Internetoptionen für automatische Ermittlung rausgenommen - auch nichts geholfen.
Ich mach schon lange und viel mit Zertifikaten, aber so ein Verhalten hatte ich noch nie. Kenn jemand eventuell ein solches Verhalten, wenn die Quelle irgendetwas unsauber liefert? Eventuell ist das Event auch irreführend und ist nur eine Standardmeldung?
Aber im Normalfall wird doch das Zertifikat geladen und auf Grund der Informationen im Zertifikat wird die Cert Chain erstellt und ggf. public trusted certificates nachgeladen (Es sind keine self-signed Zertifikate vom Partner).
Danke für die schnelle Antwort.
Die URL der CRL habe ich bereits über den Browser geprüft und funktioniert - ich kann die CRL herunterladen und öffnen. Das seltsame ist, dass ich das Zertifikat manuell herunterladen und manuell öffnen kann (Doppelklick) - Kette ist dann auch okay. Danach kann auch Outlook auf die Kette zugreifen und ich kann verschlüsselt senden.
Proxy ist nicht in Verwendung weder im System noch transparent. Hab aber trotz allem einen Proxy Reset durchgeführt.
Was ich noch gesehen habe in der Analyse war, dass die Zwischenzertifikate für die Kette nicht heruntergeladen werden, da Outlook die CRL scheinbar nicht prüfen kann (so zumindest das CAPI2-Event). Wenn ich das Zertifikat manuell öffne, dann werden die fehlenden Zertifikate nachgeladen und die Kette ist vollständig.
In welchem Benutzerkontext wird denn die CRL überprüft? SYSTEM? NETWORK? Könnte es hier noch ein Proxy-Setting geben? Ich habe schon den depperten Haken in den Internetoptionen für automatische Ermittlung rausgenommen - auch nichts geholfen.
Ich mach schon lange und viel mit Zertifikaten, aber so ein Verhalten hatte ich noch nie. Kenn jemand eventuell ein solches Verhalten, wenn die Quelle irgendetwas unsauber liefert? Eventuell ist das Event auch irreführend und ist nur eine Standardmeldung?
Aber im Normalfall wird doch das Zertifikat geladen und auf Grund der Informationen im Zertifikat wird die Cert Chain erstellt und ggf. public trusted certificates nachgeladen (Es sind keine self-signed Zertifikate vom Partner).
Aber im Normalfall wird doch das Zertifikat geladen und auf Grund der Informationen im Zertifikat wird die Cert Chain erstellt und ggf. public trusted certificates nachgeladen (Es sind keine self-signed Zertifikate vom Partner).
Nein, CA-Zertifikate werden niemals von selbst nachgeladen, sie sind entweder bereits in den vertrauenswürdigen CAs vorhanden oder befinden sich bereits mit im Zertifikatscontainer.Was ich noch gesehen habe in der Analyse war, dass die Zwischenzertifikate für die Kette nicht heruntergeladen werden
Wie gesagt Zertifikate werden niemals von selbst heruntergeladen. Wenn Intermediate Certs im Einsatz sind importiere diese ebenfalls in den vertrauenswürdigen Truststore.Outlook macht diesbezüglich gerne mal Mucken.
Ich mach schon lange und viel mit Zertifikaten
Dito.
Hallo BiberMan,
Danke für den Denkanstoß - ich melde mich wieder.
Nein, CA-Zertifikate werden niemals von selbst nachgeladen, sie sind entweder bereits in den vertrauenswürdigen CAs vorhanden oder befinden sich bereits mit im Zertifikatscontainer.
Da hast Du recht. Die gesamte Zertifikatskette muss mitgeliefert werden und dann werden die CRLs geprüft. Ich versuche mal einen Mitschnitt der Daten zu machen, die ich vom LDAP-Adressbuch erhalte und schau mal, ob da alles geliefert wird. Eventuell kommt da nur das SMIME-User-Zertifikat und nicht die ganze Kette.Wenn Intermediate Certs im Einsatz sind importiere diese ebenfalls in den vertrauenswürdigen Truststore.
Genau das wollte ich gerne verhindern, damit ich nicht jedes depperte Zertifikat verteilen muss. Da wir eine Unmenge an Partnern haben, wäre das eine Sisyphus-Arbeit Danke für den Denkanstoß - ich melde mich wieder.
