none
AD Zertifikatsdienste starten nicht (mehr) RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo

    2stufige PKI auf Basis Server 2019 die einwandfrei funktioniert hat(te) DC und PKI auf einem Server=DC1

    seit geraumer Zeit (19.9.2020), kann leider diesen Zeitpunkt nicht einer vorausgegangen Änderung am Server zuordnen, starten die Zertifikatsdienste nicht mehr, bzw. brechen mit Fehlercode -2146885613 ab.

    Bei der Fehlersuche stiess ich auf eine Info eines veralteten Sperrlistenzertifikats. Ich kann die Zertifikatsperrliste per gesetzter URL herunterladen. In der Tat steht dort "nächste Aktualisierung = 16.9.2020" sprich da hat was nicht geklappt.

    Befehl certutil -crl auf DC1 ausgeführt endete in einer Fehlermeldung:

    CertUtil: -CRL-Befehl ist fehlgeschlagen: 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)
    CertUtil: Der RPC-Server ist nicht verfügbar.

    Und hier stosse ich an meine Grenzen. Diverse Online Posts angeschaut was diese Fehlermeldung betrifft aber keine Lösung gefunden.

    RPC Dienst läuft, Ports sind offen etc. meiner Meinung nach alles gecheckt.

    Wer hat hier noch eine Lösungsfindung bzw. einen Punkt zur Fehlereingrenzung um dort mit einem Lösungsansatz weiter zu kommen?

    Möchte auch noch anfügen, dass ich auf diesem Gebiet ein absoluter Neuling bin. Daher danke für jeden Input.

    Gruss Markus

    Mittwoch, 23. September 2020 12:12
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden
    Naja, Du hast ne abgelaufene Root CA-Sperrliste. Damit kann die SubCA nicht bestimmen, ob ihr eigenes Zertifikat noch gültig ist. Du musst die Root hochfahren und die neue CRL veröffentlichen.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    • Als Antwort markiert MAME-MSWORK Donnerstag, 24. September 2020 12:08
    Mittwoch, 23. September 2020 17:24
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    Du schreibst von 2-stufiger PKI. Auf dem DC1 ist vermutlich die Issuing CA. Wo ist die Root? Wo sind die CRLs von der Root? Welche CDP-Pfade sind im Zertifikat der Issuing CA eingestellt? Sind sie erreichbar? Was passiert, wenn Du das *öffentliche* Zertifikat, also ohne den Private Key, der Issuing CA versuchst mit

    certutil -f –urlfetch -verify c:\temp\cert_der_issuing_ca.cer

    zu überprüfen?

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 23. September 2020 12:24
    |
  • Question
    Anmelden
    0
    Anmelden

    RO1 als Hyper-V Maschine ist auf DC1 installiert. RO1 läuft aktuell nicht. DC1 ist die SubCA.

    Auf dem DC1 läuft der IIS Dienst inkl. einem Shared Folder PKI wo die Zertifikatsperrlisten Zertifikate liegen.

    http://pki.domain.com/DOMAIN-SubCA.crl und http://pki.domain.com/DOMAIN-SubCA.crt sind erreichbar und ich kann die jeweiligen Dateien herunterladen.

    Befehl certutil -f –urlfetch -verify zeigt:
    Aussteller:
        CN=DOMAIN-RootCA
      Namenshash (sha1): 4647.....
      Namenshash (md5): 7785....
    Antragsteller:
        CN=DOMAIN-SubCA
        DC=domain
        DC=com
      Namenshash (sha1): 1234....
      Namenshash (md5): 4567....
    Zertifikatseriennummer: 8912... 

    dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
    dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
    dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
    dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
    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)
    ChainContext.dwRevocationFreshnessTime: 191 Days, 18 Hours, 48 Minutes, 46 Seconds

    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
    SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
    SimpleChain.dwRevocationFreshnessTime: 191 Days, 18 Hours, 48 Minutes, 46 Seconds

    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040
      Issuer: CN=DOMAIN-RootCA
      NotBefore: 16.03.2020 14:16
      NotAfter: 16.03.2035 14:26
      Subject: CN=DOMAIN-SubCA, DC=domain, DC=com
      Serial: 8912....
      Template: SubCA
      Cert: 3456.....
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      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  ----------------
      Überprüft "Zertifikat (0)" Zeit: 0 6789.....
        [0.0] http://pki.domain.com/DOMAIN-RootCA.crt

      ----------------  Zertifikat abrufen  ----------------
      Abgelaufen "Basissperrliste (01)" Zeit: 0 8913.....
        [0.0] http://pki.domain.com/DOMAIN-RootCA.crl

      ----------------  Basissperrliste veraltet  ----------------
      Keine URLs "Keine" Zeit: 0 (null)
      ----------------  Zertifikat-OCSP  ----------------
      Keine URLs "Keine" Zeit: 0 (null)
      --------------------------------
        CRL 01:
        Issuer: CN=DOMAIN-RootCA
        ThisUpdate: 16.03.2020 00:03
        NextUpdate: 16.09.2020 12:23
        CRL: 5855....

    CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=DOMAIN-RootCA
      NotBefore: 16.03.2020 00:03
      NotAfter: 16.03.2050 00:13
      Subject: CN=DOMAIN-RootCA
      Serial: 6463....
      Cert: 8346....
      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 (null)
      ----------------  Zertifikat abrufen  ----------------
      Keine URLs "Keine" Zeit: 0 (null)
      ----------------  Basissperrliste veraltet  ----------------
      Keine URLs "Keine" Zeit: 0 (null)
      ----------------  Zertifikat-OCSP  ----------------
      Keine URLs "Keine" Zeit: 0 (null)
      --------------------------------
        CRL 01:
        Issuer: CN=DOMAIN-RootCA
        ThisUpdate: 16.03.2020 00:03
        NextUpdate: 16.09.2020 12:23
        CRL: 8846....

    Exclude leaf cert:
      Chain: 7844...
    Full chain:
      Chain: 7843....
    ------------------------------------
    Verfizierte Ausstellungsrichtlinien: Kein
    Verfizierte Anwendungsrichtlinien: Alle
    Zertifikat ist ein Zertifizierungsstellenzertifikat

    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.

    Mittwoch, 23. September 2020 17:06
    |
  • Question
    Anmelden
    0
    Anmelden
    Naja, Du hast ne abgelaufene Root CA-Sperrliste. Damit kann die SubCA nicht bestimmen, ob ihr eigenes Zertifikat noch gültig ist. Du musst die Root hochfahren und die neue CRL veröffentlichen.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    • Als Antwort markiert MAME-MSWORK Donnerstag, 24. September 2020 12:08
    Mittwoch, 23. September 2020 17:24
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke..dein Tipp führte zum Erfolg.

    Muss ich mir nun einen Termin setzen um vor dem Ablauf der Root CRL diese wieder zu veröffentlichen?

    Oder gibt es da ein "automatisches" Verfahren?

    Donnerstag, 24. September 2020 12:10
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke..dein Tipp führte zum Erfolg.

    Muss ich mir nun einen Termin setzen um vor dem Ablauf der Root CRL diese wieder zu veröffentlichen?

    Oder gibt es da ein "automatisches" Verfahren?

    Naja, es heißt ja nicht umsonst "offline Root CA" ;-) Wobei ich das schon mal für einen Kunden automatisiert hatte (Tausch-VHD eingehängt, VM hoch, CRL erzeugt, CRL auf Tausch-VHD kopiert, VM runter, Tausch-VHD in eine andere VM gehängt, CRL auf CDP kopiert, Tausch-VHD ausgehängt, CRL geprüft, fertig).

    Aber Termin geht auch :-)

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Donnerstag, 24. September 2020 12:46
    |
  • Question
    Anmelden
    0
    Anmelden
    hihi...da hört sich Termin einfacher an ;-) DANKE
    Donnerstag, 24. September 2020 13:44
    |