scusimarcus
Goto Top

Zertfikate mit XCA - "Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden."

Hallo!

Mal wieder plagt mich ein Windows-Sicherheitsproblem. Mal wieder ist es scheinbar nirgends dokumentiert.

Es geht um die Zertifikatsbasierte Verschlüsselung von RDP bei Windows Server 2012 in einer Domänenstruktur..
Die Zertifikate wurden NICHT mit AD CS sondern mit XCA erstellt.

Ein Root-CA, eine Intermediate-CA sowie diverse Server-Certs. Vom Intermediate-CA wurde eine Revocation-List erstellt.

Soweit, sogut.

Die Zertifikate der Root-CA und der Zwischen-CA wurden über eine GPO verteilt. Die Server Zertifikate wurden installiert.
Auf dem RemoteDesktopServer1 (Broker, Web Access, Session Host) lade ich die Zertifikate, für Web Access sowie für die Farm, in die Bereitstellungseigentschaften rein.
Ausserdem werden die jeweiligen Server-Zertifikate als Session-Host-Zertifikate konfiguriert.

Auf dem RemoteDesktopServer1 läuft, bedingt durch die Web Access-Rolle, auch ein Webserver. Ich möchte über diesen die Revocationliste an alle anderen Server zum Download bereitstellen/verfügbar machen. Die Zertifikate haben alle bereits im "Sperrlistenverteilungspunkt" die URL , z.B. http://remotedesktopserver1/crl/sperrliste.crl, enthalten.
Die Liste kann man von mir als Benutzer ohne Probleme, druch aufrufen der URL, von jeder Maschine im Netz aus, heruntergeladen werden.

Dennoch erhalte ich bei jedem aufruf über RDP die im Betreff genannte Warnung.

Habt ihr eine Idee was ich vergessen habe?

Danke und Gruß für eure Hilfe face-smile
Marcus

Content-ID: 336292

Url: https://administrator.de/forum/zertfikate-mit-xca-es-konnte-keine-sperrpruefung-fuer-das-zertifikat-durchgefuehrt-werden-336292.html

Ausgedruckt am: 23.12.2024 um 14:12 Uhr

132895
Lösung 132895 27.04.2017 aktualisiert um 16:44:41 Uhr
Goto Top
Habt ihr eine Idee was ich vergessen habe?
Die CRL der RootCA?
Checke die CRL aller Certs (auch die der CAs) mit certutil und poste den Output
certutil -verify -urlfetch test.cer
https://blogs.technet.microsoft.com/pki/2006/11/30/basic-crl-checking-wi ...

Gruß
scusimarcus
scusimarcus 27.04.2017, aktualisiert am 02.05.2017 um 09:40:31 Uhr
Goto Top
Hallo,

hier mal die Ausgabe von einem Zertifikat.

Aussteller:
CN=bla_Intermediate_CA
OU=bla
O=blabla
L=Berlin
S=Berlin
C=DE
Namenshash (sha1): 77b7278e2bbe9f058dc061ba82067652408f8f3d
Namenshash (md5): ee0d0c136a5faa0dac7477529646329d
Antragsteller:
CN=blascrvs01w.blasic.ref
OU=bla
O=blabla
L=Berlin
S=Berlin
C=DE
Namenshash (sha1): e27b363e0df3f10176b8f63bdd66cb222afb59c2
Namenshash (md5): 77764a14b9fef22131d2d71113f8f0b7
Zertifikatseriennummer: 0f

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

CertContext: dwInfoStatus=104 dwErrorStatus=1000040
Issuer: CN="bla_Intermediate_CA ", OU=bla, O=blabla, L=Berlin, S=Berlin, C=DE
NotBefore: 27.04.2017 02:00
NotAfter: 27.04.2027 01:59
Subject: CN=blascrvs01w.blasic.ref, OU=bla, O=blabla, L=Berlin, S=Berlin, C=DE
Serial: 0f
1360db498e16f3ef12fa8320610fa19ba387d95b
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
---------------- Zertifikat abrufen ----------------
Keine URLs "Keine" Zeit: 0
---------------- Zertifikat abrufen ----------------
Gescheitert "CDP" Zeit: 0
Fehler beim Abrufen der URL: Für die Clientauthentifizierung ist ein Zertifikat erforderlich. 0x80072f0c (INet: 12044 ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED)
https://blascrvs01w.blasic.ref/crl/WNSIC_Intermediate_CA.crl

---------------- Zertifikat-OCSP ----------------
Keine URLs "Keine" Zeit: 0
--------------------------------
Application = 1.3.6.1.5.5.7.3.1 Serverauthentifizierung
Application[1] = 1.3.6.1.5.5.7.3.2 Clientauthentifizierung
Application[2] = 1.3.6.1.5.5.7.3.5 IP-Sicherheitsendsystem

CertContext[1]: dwInfoStatus=104 dwErrorStatus=1000040
Issuer: CN=blub_Root-CA, OU=blub, O=blubblubb, L=Dortmund, S=NRW, C=DE
NotBefore: 27.04.2017 02:00
NotAfter: 27.04.2047 01:59
Subject: CN="blaSIC_Intermediate_CA ", OU=bla, O=blabla, L=Berlin, S=Berlin, C=DE
Serial: 0b
56e919a44d8296f50b5433043c184adcbf3a559d
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
---------------- Zertifikat abrufen ----------------
Keine URLs "Keine" Zeit: 0
---------------- Zertifikat abrufen ----------------
Gescheitert "CDP" Zeit: 0
Fehler beim Abrufen der URL: Für die Clientauthentifizierung ist ein Zertifikat erforderlich. 0x80072f0c (INet: 12044 ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED)
https://blascrvs01w.blasic.ref/crl/blasic_intermediate_ca.crl

---------------- Zertifikat-OCSP ----------------
Keine URLs "Keine" Zeit: 0
--------------------------------

CertContext[2]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=blub_Root-CA, OU=blub, O=blubblub, L=Dortmund, S=NRW, C=DE
NotBefore: 25.04.2017 02:00
NotAfter: 25.04.2052 01:59
Subject: CN=blub_Root-CA, OU=blub, O=blubblub, L=Dortmund, S=NRW, C=DE
Serial: 01
95b4ac02daa7d66f9c2271538152ef40aa08ad71
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Zertifikat abrufen ----------------
Keine URLs "Keine" Zeit: 0
---------------- Zertifikat abrufen ----------------
Keine URLs "Keine" Zeit: 0
---------------- Zertifikat-OCSP ----------------
Keine URLs "Keine" Zeit: 0
--------------------------------

Exclude leaf cert:
3c1d4ef9c251c428b7dd6b6990bb75bd14ab0c2a
Full chain:
581e49662f521e46a627c24a25901528c1246919
Issuer: CN="blaSIC_Intermediate_CA ", OU=bla, O=blabla, L=Berlin, S=Berlin, C=DE
NotBefore: 27.04.2017 02:00
NotAfter: 27.04.2027 01:59
Subject: CN=blascrvs01w.blasic.ref, OU=bla, O=blabla, L=Berlin, S=Berlin, C=DE
Serial: 0f
1360db498e16f3ef12fa8320610fa19ba387d95b
Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)
Sperrungsüberprüfung übersprungen -- Server ist offline

FEHLER: Die Sperrstatusüberprüfung des untergeordneten Zertifikats hat Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) zurückgegeben.
CertUtil: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.
132895
132895 27.04.2017, aktualisiert am 28.04.2017 um 09:54:21 Uhr
Goto Top
Zitat von @scusimarcus:
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
Die CRL der CA kann nicht abgerufen werden!
Fehler beim Abrufen der URL: Für die Clientauthentifizierung ist ein Zertifikat erforderlich. 0x80072f0c (INet: 12044 ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED)
https://goewnscrvs01w.goewnsic.ref/crl/WNSIC_Intermediate_CA.crl
Hast du im IIS die zwingende Authentifizierung per Client-Zertifikate aktiviert? Das darf natürlich nicht aktviert sein da die CRL ansonsten nicht abgerufen werden kann! Und per HTTPS geht das sowieso nicht!!!

Ahh.. jetzt weiß ich auch warum:
Zitat:
Auf dem RemoteDesktopServer1 läuft, bedingt durch die Web Access-Rolle, auch ein Webserver. Ich möchte über diesen die Revocationliste an alle anderen Server zum Download bereitstellen/verfügbar machen.
Der hat vermutlich bei euch die Einstellung im IIS gesetzt...


Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)
Sperrungsüberprüfung übersprungen -- Server ist offline
Deswegen auch die Meldung das der Sperrserver offline ist, weil die URL nicht ohne jegliche Restriktionen abgerufen werden kann. Also nehme alle Restriktionen im IIS raus, oder lege eine zweite Site an wenn in das in dieser IIS Site gefordert ist, oder lege die CRL auf einen anderen öffentlich abrufbaren Server.

Bevor du hier keine Positiv-Meldung über den Abruf der CRL erhältst brauchst du gar nicht bei deinen RDP-Servern weiter machen.
scusimarcus
scusimarcus 28.04.2017 um 09:46:43 Uhr
Goto Top
Vielen Dank für deine Antwort und Denkanstoss.

Ich schau mal was sich dort machen lässt. Kenne mich mit dem IIS nur nicht wirklich aus.

Ist es den prinzipiell eher eine schlechte Idee die CRL über einen HTTPS link verteilen zu wollen?

Gruß
132895
Lösung 132895 28.04.2017 aktualisiert um 09:55:10 Uhr
Goto Top
Ist es den prinzipiell eher eine schlechte Idee die CRL über einen HTTPS link verteilen zu wollen?
Logisch, über https geht das ja sowieso nicht face-wink
Certificate revocation lists cannot be accessed over HTTPS
https://blogs.technet.microsoft.com/enterprisemobility/2009/05/01/how-to ...

Hatte ich in deinen URLs vollkommen übersehen, sorry.
scusimarcus
scusimarcus 28.04.2017 aktualisiert um 10:20:48 Uhr
Goto Top
Zitat von @132895:

Ist es den prinzipiell eher eine schlechte Idee die CRL über einen HTTPS link verteilen zu wollen?
Logisch, über https geht das ja sowieso nicht face-wink
> Certificate revocation lists cannot be accessed over HTTPS
> 
https://blogs.technet.microsoft.com/enterprisemobility/2009/05/01/how-to ...

Hatte ich in deinen URLs vollkommen übersehen, sorry.


Oh ok, das macht irgendwie auch Sinn. Vielen Dank für den Hinweis!!! Wobei die Sperrlistenprüfung ja perse erfolgt zu sein scheint, siehe meinen Post darüber a la "Falscher Aussteller" ?
132895
132895 28.04.2017 aktualisiert um 10:36:14 Uhr
Goto Top
Zitat von @scusimarcus:
Wobei die Sperrlistenprüfung ja perse erfolgt zu sein scheint, siehe meinen Post darüber a la "Falscher Aussteller" ?
Nein, das falscher Aussteller ist ja das Problem. Die Übersetzung ist da wohl etwas missglückt. Fakt ist CRLs nur per http zum Abruf bereit zu stellen, denn die Dienste die die CRLs abrufen sind meist auf https-Abrufe der CRLs nicht ausgelegt und die Prüfung schlägt dann fehl.
Es ist ein Henne-Ei Problem: wenn der Client erst die CRLs der Sperrserver überprüfen würde das irgendwann in einem Loop enden.
scusimarcus
scusimarcus 28.04.2017 um 12:07:47 Uhr
Goto Top
Soeben habe ich alle Zertifikate neu erstellt und mit entsprechend neuem http-link zur CRL versehen.
Es wurde auch eine neue Website auf dem IIS angelegt.
Das Problem bleibt laut CERTUTIL bestehen aber ich erhalte beim mstsc-Aufruf keine Fehlermeldung mehr a la "Sperrlistenprüfung konnte für diesen Server nicht durchgeführt werden".
scusimarcus
scusimarcus 28.04.2017 um 13:56:02 Uhr
Goto Top
Ich bin dem ganzen einen Schritt näher gekommen.

Es scheint, dass die Fehlermeldung "Sperrserver offline" daher rührt dass ich keine sognenannte Deltasperrliste zur Verfügung stelle. Was hat es damit auf sich? Wie kann ich das, fernab einer Windows CA, erstellen?

Danke und Gruß
scusimarcus
scusimarcus 02.05.2017 um 09:36:42 Uhr
Goto Top
Das Problem ist gelöst!

Lösung: Ich hatte aus der Root-CA heraus keine CRL für die Sub-CA erstellt. D.h. CRL aus Root-CA generieren und die URL zu dieser CRL in die Sub-CA eintragen. Das gleiche gilt für die Sub-CA -> CRL aus Sub-CA erstellen und die passende URL in die User-/Serverzertifikate eintragen. Et voilá es funktioniert.

Danke und Gruß
132895
Lösung 132895 02.05.2017 aktualisiert um 09:39:14 Uhr
Goto Top
Lösung: Ich hatte aus der Root-CA heraus keine CRL für die Sub-CA erstellt.
Hatte ich ja schon im aller ersten Post erwähnt face-wink
scusimarcus
scusimarcus 02.05.2017 um 09:41:45 Uhr
Goto Top
Ah ok, naja, das habe ich dann wohl missverstanden... Danke!