Microsoft CA-communicatie 

Wanneer organisaties digitale communicatie moeten beveiligen, identiteiten moeten verifiëren of veilige toegang tot netwerkbronnen mogelijk moeten maken, maken ze vaak gebruik van Public Key Infrastructure (PKI)-technologie. De kern van PKI wordt gevormd door de certificeringsinstantie (CA), een vertrouwde entiteit die verantwoordelijk is voor het uitgeven, beheren en valideren van digitale certificaten. Deze certificaten zijn elektronische referenties die een openbare sleutel koppelen aan de identiteit van een gebruiker, computer of apparaat, waardoor veilige, versleutelde communicatie, authenticatie en digitale handtekeningen mogelijk zijn.

Dit artikel is bedoeld om IT-professionals te helpen bij het diagnosticeren en oplossen van CA-communicatieproblemen, zodat digitale certificaten op betrouwbare wijze kunnen worden uitgegeven, gevalideerd en gebruikt voor veilige bewerkingen.

Wat is het oplossen van communicatieproblemen met Microsoft CA's? Het is het proces waarbij wordt vastgesteld waarom een ​​Active Directory Certificate Services (AD CS) Certificate Authority geen certificaten kan uitgeven, vernieuwen of valideren. Hierbij worden achtereenvolgens de volgende zaken gecontroleerd: de status van de CA-service, netwerkpoorten, machtigingen van serviceaccounts, zichtbaarheid van certificaatsjablonen, gebeurtenislogboeken en toegankelijkheid van de certificaatketen en CRL.

Microsoft implementeert deze technologie onder de naam Active Directory Certificate Services (AD CS). AD CS is een Windows Server-rol waarmee organisaties hun eigen interne CA kunnen maken en beheren. AD CS ondersteunt de uitgifte van een breed scala aan certificaattypen, waaronder:

• Gebruikerscertificaten: Deze worden gebruikt voor gebruikersauthenticatie, beveiligde e-mail (S/MIME) en digitale handtekeningen.
• Machine (computer) certificaten: Schakel computer- en serverauthenticatie, encryptie en beveiligde communicatie in.
• Webservercertificaten: Beveiligde webservers en applicaties met SSL/TLS-encryptie.
• Certificaten voor codeondertekening: Deze worden gebruikt voor het ondertekenen van software en scripts om de integriteit en authenticiteit ervan te garanderen.
• VPN- en externe toegangscertificaten: Beveiligde externe verbindingen via VPN's en andere technologieën voor externe toegang.
• Netwerkapparaatcertificaten: Verifieer apparaten zoals routers, switches en firewalls die mogelijk geen domeinaccounts hebben.
• Smartcardcertificaten: Zorg voor sterke authenticatie voor gebruikers via smartcards of hardwaretokens.

De certificaten die AD CS verstrekt, zorgen ervoor dat:

• Vertrouwelijkheid: Alleen de beoogde ontvangers kunnen de gegevens lezen door deze te versleutelen.
• Integrity: Onderteken uw gegevens digitaal om manipulatie te voorkomen.
• authenticatie: Door de identiteit te bevestigen van gebruikers, computers of apparaten die toegang hebben tot netwerkbronnen.

Microsoft implementeert deze technologie via Active Directory Certificate Services (AD CS), een Windows Server-rol waarmee organisaties hun eigen interne certificeringsinstantie (CA) kunnen maken en beheren.

Een Microsoft-CA kan op verschillende manieren worden ingesteld, bijvoorbeeld als root-CA (het vertrouwensanker voor uw organisatie) of als ondergeschikte CA (die certificaten uitgeeft onder het gezag van de root-CA). Enterprise-CA's integreren met Active Directory, wat geautomatiseerde certificaatuitgifte en -beheer mogelijk maakt, terwijl zelfstandige CA's onafhankelijk werken en handmatige goedkeuring van certificaataanvragen vereisen.

Betrouwbare communicatie met uw Microsoft-certificeringsinstantie (CA) is belangrijk voor elke organisatie die afhankelijk is van Active Directory Certificate Services (AD CS) voor veilige certificaatuitgifte, authenticatie of integratie met platforms van derden. Stel dat u problemen ondervindt met certificaataanvragen, verlengingen of integratiefouten. In dat geval helpt deze stapsgewijze handleiding u bij het systematisch verifiëren en oplossen van communicatieproblemen met Microsoft-certificeringsinstanties (CA's). Laten we eerst eens kijken naar de verschillen tussen openbare certificeringsinstanties (Certificate Authority) en MSCA's (Microsoft Certificate Authority).

Samenvatting

• Communicatieproblemen met Microsoft CA's zijn bijna altijd terug te voeren op een van de volgende zes gebieden: de status van de CA-service, netwerkpoorten, de reactiesnelheid van de CA, machtigingen van het serviceaccount, de zichtbaarheid van certificaatsjablonen of de toegankelijkheid van de certificaatketen en CRL.
• Beginnen met Get-Service certsvc Controleer eerst of de CA-service actief is en ga vervolgens verder met de poorten. certutil -ping, machtigingen, sjablonen, gebeurtenislogboeken en CRL-controles in de aangegeven volgorde.
• Veelvoorkomende foutmeldingen zijn onder andere "RPC Server Unavailable", CERT_E_REVOCATION_FAILURE, CERT_E_UNTRUSTEDROOT en SCEP-foutcodes 0x80092013 en 0x80094800.
• Met de snelle checklist voor probleemoplossing en de onderstaande tabel met foutcodes kunt u direct een oplossing vinden voor een bekend probleem.
• CertSecure Manager kan het vernieuwen, bewaken en afstemmen van AD-beleid automatiseren, zodat deze problemen aan het licht komen en worden opgelost voordat ze een storing veroorzaken.

Microsoft CA versus openbare CA

Om de reikwijdte van Microsoft CA te begrijpen, volgt hier een korte vergelijking met openbare CA's:

Kenmerk	Microsoft CA (AD CS)	Openbare CA (bijv. DigiCert, Let's Encrypt)
Deployment	On-premises, intern beheerd	Cloudgebaseerd, door de provider beheerd
Vertrouwensomvang	Interne gebruikers, systemen en services	Publiek vertrouwen in browsers en apparaten
Validatiemodel	AD-gebaseerde automatisering	Domein- (DV), Org- (OV) of Uitgebreide (EV) Validatie
Kostenmodel	Infrastructuur- en onderhoudskosten	Per certificaat of abonnementskosten
Best voor	Interne apps, servers, apparaten, VPN, S/MIME	Websites, externe apps, API's
Ondersteuning en SLA's	Interne IT- of Microsoft-ondersteuning	Door de leverancier verstrekte SLA's, ondersteuning

Voorwaarden voordat u problemen met Microsoft CA-communicatie kunt oplossen

Voordat u met deze handleiding aan de slag gaat, dient u te controleren of u over het volgende beschikt.

• Administratieve of gedelegeerde toegang tot de Microsoft CA-server en tot de betreffende clientcomputer.
• Een PowerShell- of opdrachtpromptsessie met beheerdersrechten op zowel de CA-server als een client, aangezien verschillende opdrachten (Restart-Service, dsacls, gpresult /r) vereisen beheerdersrechten.
• Er moet een directe netwerkverbinding zijn tussen de client en de CA-server, zodat poorttests zinvol zijn.
• Toegang tot de console van de certificeringsinstantie (certsrv.msc) en de module Certificaatsjablonen (certtmpl.msc).
• RSAT (Remote Server Administration Tools) moet geïnstalleerd zijn als u dit nodig hebt. Get-CATemplate van een andere machine dan de CA.
• Een recente back-up of gedocumenteerde basislijn van CA-machtigingen en gepubliceerde sjablonen, zodat u kunt terugkeren naar een eerdere versie als een wijziging de situatie verergert.

Stapsgewijze handleiding

1. Bevestig dat de Microsoft CA-service actief is

We beginnen met ervoor te zorgen dat de CA-service actief is op de server. Voordat u problemen met certificaten oplost, moet u altijd eerst controleren of de CA-service (Certificate Authority) op de server actief is. Dit is cruciaal, want als de CA-service is gestopt, kunnen er geen certificaataanvragen worden verwerkt en is verdere probleemoplossing ineffectief en verspilt u kostbare tijd. Open een PowerShell-venster en voer het volgende uit:

Get-Service certsvc

De uitvoer zou de servicestatus als 'Actief' moeten aangeven. U kunt ook de Services Management Console (services.msc) openen en controleren of 'Active Directory Certificate Services' actief is.

Als de service is gestopt, kan een snelle herstart het probleem vaak oplossen. Gebruik de volgende PowerShell-opdracht om de service te starten of opnieuw te starten:

Herstart-Service certsvc

Controleer na het opnieuw starten van de service altijd de Windows Logboeken op servicegerelateerde fouten of waarschuwingen. Open de Logboeken door te zoeken naar eventvwr.msc. Navigeer naar Toepassings- en servicelogboeken > Microsoft > Windows > CertificationAuthority.

Controleer recente gebeurtenissen op fouten, waarschuwingen of informatieve berichten met betrekking tot de CA-service. Besteed speciale aandacht aan logboeken met gebeurtenis-ID's zoals 58 (problemen met de certificaatketen), 4886 (certificaataanvragen) en andere relevante vermeldingen, aangezien deze inzicht kunnen bieden in onderliggende problemen of succesvolle bewerkingen kunnen bevestigen.

2. Controleer de netwerkconnectiviteit en de vereiste poorten

Zorg ervoor dat de benodigde poorten openstaan ​​voor CA-communicatie.

Vereiste poorten:

• TCP 135 – RPC-eindpunttoewijzer
  Het wordt gebruikt voor de eerste client/server-onderhandeling voor RPC-communicatie.
• TCP 445 – SMB (gebruikt voor certificaatsjablonen en groepsbeleid)
  Het is vereist voor toegang tot certificaatsjablonen (opgeslagen in AD), GPO-distributie en DCOM.
• Dynamische RPC-poorten – TCP 49152–65535 (voor Windows Server 2012 en nieuwer)
  Het wordt gebruikt nadat RPC Endpoint Mapper een hoge poort voor communicatie toewijst.
• TCP 88 – Kerberos (voor domeinauthenticatie)
  Het verwerkt domeinauthenticatie wanneer een gebruiker of computer certificaten aanvraagt.

Waarom zijn deze havens belangrijk?

• Kerberos (TCP 88): Vereist voor machines die lid zijn van een domein om zich te verifiëren bij de CA, met name tijdens automatische inschrijving of toegang tot certificaatsjablonen.
• SMB (TCP 445): Toegang tot certificaatsjablonen en CA-beleidsregels die zijn opgeslagen in Active Directory, is afhankelijk van SMB.
• RPC/Hoge poorten (TCP 135 + 49152–65535): Kern voor DCOM- en RPC-aanroepen die worden gebruikt door certreq, certutil, MMC-snap-ins en bij het op afstand aanvragen van certificaten.

Connectiviteit testen met PowerShell:

Test-NetConnection -Computernaam -Poort 135

Een succesvolle test geeft aan dat de poort open is.

Gebruikelijke problemen:

Firewalls blokkeren de vereiste poorten. Om alle firewallregels weer te geven die de CA-communicatie kunnen beïnvloeden:

Get-NetFirewall-regel

Netwerksegmentatie verhindert communicatie.

De verbinding testen met Telnet (indien geïnstalleerd):

telnet 135
telnet 445

Als het scherm zwart wordt nadat u op Enter hebt gedrukt, is de poort open.
Als er staat: "Kan geen verbinding maken", is de poort geblokkeerd.

3. Test de responsiviteit van CA's met Certutil

Controleer of de CA bereikbaar en responsief is. Als dit mislukt, betekent dit dat uw systeem niet goed kan communiceren met de certificeringsinstantie (CA). Deze fout kan wijzen op een aantal onderliggende problemen die hieronder worden genoemd:

Stappen:

Open de opdrachtprompt of PowerShell op een clientcomputer en voer de volgende opdracht uit. Het is ook aan te raden om de opdracht certutil zowel vanaf de client als vanaf de CA-server zelf te proberen.

certutil -config – -ping

U wordt gevraagd de CA te selecteren. Een succesvol antwoord bevestigt dat de CA bereikbaar is.

U wordt gevraagd de CA uit een lijst te selecteren. Een succesvolle reactie bevestigt dat de CA bereikbaar is.

Geautomatiseerde/gescripte controle:

certutil -config “ \ ”-ping

vervangen \ met de volledige configuratiestring van uw CA (bijv. CA-SERVER\My-Enterprise-CA). Hiermee wordt de controle rechtstreeks uitgevoerd op de opgegeven CA, waardoor deze geschikt is voor scripts en automatisering.

Gebruikelijke problemen:

• “RPC-server niet beschikbaar” Fouten duiden op communicatieproblemen. Een voorbeeld van zo'n fout is:

Als u een dergelijke foutmelding krijgt, is de CA mogelijk niet bereikbaar voor het systeem, verkeerd geconfigureerd of geblokkeerd door het beveiligingsbeleid.

• DNS-resolutiefout – De hostnaam van de CA kan niet worden opgelost
• Firewall-beperkingen – Vereiste poorten (bijvoorbeeld TCP 135 voor RPC) zijn geblokkeerd
• CA-service is offline – De CA-server is down of de Certificate Services-service is gestopt
• Netwerksegmentatie – Routing of VLAN-isolatie verhindert communicatie

Dergelijke problemen verhinderen dat cliënten de CA ontdekken of zich bij de CA aanmelden.

4. Controleer de machtigingen van het serviceaccount

Het account dat wordt gebruikt om te communiceren met de CA moet specifieke machtigingen hebben voor de CA en certificaatsjablonen.

Om CA-niveau-machtigingen te controleren

1. Open de Certificeringsinstantie console op de CA-server (certsrv.msc)
2. Klik met de rechtermuisknop op de CA en selecteer Aanbod
3. Navigeer naar de Security tab
4. Bevestig dat het serviceaccount toestemming heeft om Certificaten aanvragen.

Voor meer gedetailleerde auditing of scripting kunt u hulpmiddelen zoals dsacls gebruiken:

dsacls “CN=Openbare sleutelservices,CN=Services,CN=Configuratie,DC=domein,DC=com”

Gebruik de volgende opdracht om de gedelegeerde machtigingen in Active Directory te bekijken met PowerShell:

Get-ADPermission -Identiteit "CA_Naam" -Gebruiker "ServiceAccountNaam"

Met deze hulpmiddelen kunt u controleren of aan het serviceaccount de benodigde rechten zijn toegekend via AD-delegatie, vooral in grotere of geautomatiseerde omgevingen.

Om machtigingen op sjabloonniveau te controleren:

1. Open de Certificaatsjablonen snap-in (certtmpl.msc)
2. Klik met de rechtermuisknop op het relevante certificaatsjabloon en selecteer Aanbod
3. In de Security tabblad, bevestig dat het account is Lees, Inschrijvenen, indien nodig, Automatisch inschrijven permissies

Deze machtigingen moeten worden verleend via Active Directory en vereisen mogelijk een vernieuwing van het groepsbeleid. Om te controleren of het juiste groepsbeleid is toegepast, voert u de volgende stappen uit op het clientsysteem:

gpresult /r

Met deze opdracht worden de toegepaste groepsbeleidsinstellingen weergegeven en kunt u controleren of er automatisch inschrijvings- of certificaatgerelateerd beleid actief is op de computer.

Tip : Als een certificaatsjabloon is gepubliceerd maar niet zichtbaar of bruikbaar is voor een serviceaccount, is er meestal sprake van een probleem met de machtigingen op sjabloonniveau. Als helemaal geen sjablonen werken, controleer dan eerst de machtigingen op CA-niveau.

Typische rollen die interactie hebben met de CA :

1. NDES-serviceaccount
   Wordt gebruikt door Network Device Enrollment Service voor aanvragen voor apparaatcertificaten.
   Vereist "Certificaten aanvragen" bij de CA en lezen/registreren op sjablonen.
2. Klanten automatisch inschrijven
   Domeincomputers/gebruikers die zich automatisch inschrijven voor certificaten.
   Vereist 'Certificaten aanvragen' bij de CA en lees, schrijf in (automatisch inschrijven indien gebruikt) op sjablonen.
3. Applicatie-/integratieaccounts
   Wordt gebruikt door apps/services (bijv. SCEP) voor certificaatautomatisering.
   U moet 'Certificaten aanvragen' bij de CA en sjablonen lezen/registreren.
4. beheerders
   Vereisen volledige controle.
   Beheer CA en sjablonen.

5. Zorg ervoor dat certificaatsjablonen gepubliceerd en zichtbaar zijn

Als uw verwachte certificaatsjabloon niet beschikbaar is, is deze mogelijk niet gepubliceerd of is uw account mogelijk niet zichtbaar. Open de certificeringsinstantie (certsrv.msc).

Klik met de rechtermuisknop op ‘Certificaatsjablonen’ en selecteer ‘Nieuw’ > ‘Uit te geven certificaatsjabloon’.

Selecteer en publiceer de gewenste sjabloon.

U kunt vanaf een client die lid is van een domein, alle beschikbare sjablonen weergeven met de volgende opdracht:

certutil-sjabloon

Als uw sjabloon niet verschijnt, controleer dan de machtigingen en de publicatiestatus op de CA. Replicatievertragingen in Active Directory kunnen de zichtbaarheid van nieuwe of bijgewerkte sjablonen in verschillende domeinen of sites beïnvloeden, omdat wijzigingen die op de CA of in de sjabloonmachtigingen zijn aangebracht, enige tijd nodig hebben om te worden doorgevoerd en zichtbaar te worden voor alle clients.

Om een ​​lijst te maken van alle sjablonen die momenteel door de CA zijn uitgegeven (gepubliceerd) met behulp van PowerShell:

Get-CATemplate

Hiervoor is de module CertificateServices nodig, die moet worden uitgevoerd op de CA of een machine waarop RSAT (Remote Server Administration Tools) is geïnstalleerd.

6. Controleer gebeurtenislogboeken op CA-gerelateerde fouten

Open Logboeken op de CA-server en ga naar de volgende locatie:

Logboeken Toepassingen en Services > Microsoft > Windows > CertificateServicesClient

Controleer zowel de operationele als debuglogboeken op fouten zoals 'Toegang geweigerd', 'RPC niet beschikbaar', 'Sjabloon niet gevonden' of 'Inschrijving mislukt'. Deze logboeken wijzen vaak direct op machtigingsproblemen, verbindingsproblemen of verkeerde configuraties.

Voor een volledig inzicht kunt u de gebeurtenislogboeken op zowel de CA-server als de clientcomputers raadplegen. Clientlogboeken kunnen problemen met de beleidstoepassing, inschrijvingsfouten of verbindingsproblemen aan het licht brengen die mogelijk niet in de CA-logboeken voorkomen. Voor meer geavanceerde probleemoplossing kunt u uitgebreide/debug-logboekregistratie inschakelen voor de component Certificaatservices (certsvc) door de volgende registerwaarde toe te voegen:

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuratie
Waarde: Diagnostisch
Type: REG_DWORD
Gegevens: 0x0000ffff

Nadat u de wijziging hebt toegepast, start u de certificaatservices opnieuw op om gedetailleerde logging via PowerShell te activeren:

Restart-Service -Naam CertSvc

7. Valideer de certificaatketen en CRL-toegankelijkheid

Een veelvoorkomende oorzaak van communicatieproblemen is een onvolledige of niet-vertrouwde certificaatketen. Zorg ervoor dat:

• De root- en intermediate-certificaten van de CA bevinden zich in de juiste archieven 'Trusted Root Certification Authorities' en 'Intermediate Certification Authorities'.
• Certificate Revocation List (CRL)-eindpunten zijn toegankelijk vanaf clientapparaten en integratieservers.

U kunt certificaatopslag controleren met behulp van:

certlm.msc

En controleer de CRL-toegankelijkheid met:

certutil -verify -urlfetch

Vervangen met het pad naar uw certificaatbestand. Om direct te bevestigen dat CRL-distributiepunten (CDP's) bereikbaar zijn, opent u de CRL-URL in een webbrowser of gebruikt u een tool zoals curl:

krul -I http://

Een succesvolle HTTP 200-respons geeft aan dat de CRL toegankelijk is. Deze stap helpt firewall- of DNS-problemen uit te sluiten die de bereikbaarheid van de CRL beïnvloeden, wat kan leiden tot fouten met betrekking tot het vertrouwen in certificaten of het intrekken van certificaten tijdens de validatie.

Om de inhoud van een gedownloade CRL te analyseren, gebruikt u de OpenSSL-opdracht:

openssl crl -in -noout -tekst

Met deze opdracht worden CRL-metadata, intrekkingsgegevens en de gegevens van de uitgever weergegeven. Dit helpt controleren of de CRL correct is uitgegeven en up-to-date is.

Technische impact van CRL- of AIA-storingen:

Het niet kunnen openen van CRL- of AIA-URL's kan de certificaatvalidatie verstoren, wat kan leiden tot diverse operationele problemen. Deze worden meestal veroorzaakt door problemen met de DNS-resolutie, blokkeringen van de firewall, onjuiste configuraties van de HTTP-proxy of ontbrekende publicatie-instellingen op de CA. Hieronder vindt u de belangrijkste technische symptomen van dergelijke problemen:

1. Fouten bij de validatie van de certificaatketen
   Certificaatvalidatie kan mislukken tijdens het opbouwen van de keten, wat fouten zoals CERT_E_REVOCATION_FAILURE, CERT_E_CHAINING of CERT_E_UNTRUSTEDROOT veroorzaakt. Dit duidt op problemen bij het bereiken van intrekkings- of AIA-eindpunten.
2. SCEP- en automatische inschrijvingsfouten
   Inschrijvingsbewerkingen kunnen mislukken met specifieke foutcodes, zoals:
   • 0x80092013: Herroepingsserver offline
   • 0x80094800: Ongeldige certificeringsinstantie
   Deze fouten geven aan dat er geen intrekkingsstatus of autoriteitsinformatie kan worden opgehaald.
3. TLS/SSL-handshakefouten
   Clients kunnen servercertificaten afwijzen tijdens TLS/SSL-onderhandelingen vanwege onvolledige ketens of niet-beschikbare CRL/AIA-URL's. Dit kan de beveiligde communicatie voor services zoals HTTPS, LDAPS of VPN's verstoren.
4. Gebeurtenislogboekindicatoren
   In de logboeken van Windows Event Viewer kunnen relevante vermeldingen onder CertificateServicesClient of Schannel worden vastgelegd, die time-outs bij intrekkingscontroles, fouten bij de opbouw van de keten of downloadfouten van CDP/AIA-URL's aangeven.
5. OCSP- en CRL-ophaalfouten
   Pogingen om intrekkingsgegevens op te halen via OCSP of CRL kunnen mislukken vanwege:
   • DNS-resolutieproblemen
   • Onjuiste of onbereikbare URL's
   • Beperkingen voor HTTP-proxy's
   • Ontbrekende of verkeerd geconfigureerde CA-publicaties

Deze problemen kunnen onopgemerkt de processen voor vertrouwensvalidatie verstoren, tenzij er actief toezicht op wordt gehouden.

Snelle checklist voor probleemoplossing

Stap voor	Commando/Locatie	verwacht resultaat	Tips voor probleemoplossing
CA-servicestatus	Get-Service certsvc	Service is actief	Controleer de Windows-gebeurtenislogboeken op fouten als de service niet actief is. Probeer de service opnieuw te starten. Zorg ervoor dat aan de afhankelijkheden wordt voldaan.
Poortconnectiviteit	Test-NetConnection -Computernaam -Poort 135	Verbinding is succesvol	Als dit mislukt, controleer dan de firewallinstellingen, de netwerkconnectiviteit en of RPC (poort 135) open is tussen de client en de CA.
CA-ping	certutil -config – -ping	“Ping succesvol voltooid.”	Als dit niet lukt, controleer dan de netwerkconnectiviteit, de CA-servicestatus en de DNS-resolutie van de CA-server.
Sjabloonzichtbaarheid	certutil-sjabloon	Het sjabloon staat vermeld	Indien deze ontbreekt, controleer dan of de sjabloon is gepubliceerd op de CA en of de AD-replicatie is voltooid. Controleer de sjabloonmachtigingen.
machtigingen	certsrv.msc > Beveiliging	Vereiste machtigingen zijn verleend	Als er machtigingen ontbreken, controleer dan de rechten en wijs deze toe aan gebruikers/groepen. Controleer op conflicten met het groepsbeleid.
Gebeurtenislogboeken	Event Viewer (gegroepeerd op “Netwerk”, “Service”, “Machtigingen”, “Sjablonen”)	Geen RPC- of toestemmingsfouten	Als er fouten zijn, controleer dan de details op aanwijzingen. Filter logs op relevante fouten. Behandel problemen aan de hand van foutcodes.

Veelvoorkomende foutcodes en hun betekenis

De onderstaande tabel bevat een overzicht van de foutcodes en -meldingen waarnaar in deze handleiding wordt verwezen, zodat u direct naar een bekend symptoom kunt springen.

Foutmelding of bericht	Wat het betekent	Waar je het zult zien
“RPC-server niet beschikbaar”	De client kan de CA niet bereiken via RPC. De CA is mogelijk offline, onbereikbaar of geblokkeerd door een firewall.	certutil -config –ping
CERT_E_REVOCATION_FAILURE	De ketenvalidatie kon de intrekkingsstatus niet bevestigen omdat het CRL- of OCSP-eindpunt niet bereikbaar was.	Validatie van de certificaatketen
CERT_E_CHAINING	De certificaatketen kon niet worden opgebouwd, vaak vanwege een ontbrekend tussenliggend certificaat.	Validatie van de certificaatketen
CERT_E_UNTRUSTEDROOT	Het root-CA-certificaat bevindt zich niet in de lijst met vertrouwde root-certificeringsinstanties.	Validatie van de certificaatketen
0x80092013	Intrekkingsserver offline. De client kon de intrekkingsstatus niet ophalen tijdens de registratie.	SCEP en automatische inschrijving
0x80094800	Ongeldige certificeringsinstantie. De CA-referentie is onjuist geconfigureerd of niet bereikbaar.	SCEP en automatische inschrijving
"Toegang geweigerd"	Het account heeft geen toestemming om certificaten aan te vragen bij de certificeringsinstantie (CA) en geen toestemming om zich in te schrijven voor de sjabloon.	CertificateServicesClient gebeurtenislogboek
"Sjabloon niet gevonden"	De gevraagde sjabloon is niet gepubliceerd op de CA, of de AD-replicatie heeft deze nog niet doorgegeven.	CertificateServicesClient gebeurtenislogboek / certutil -template
“Inschrijving mislukt”	Een algemene inschrijvingsfout, meestal een gevolg van een van de bovengenoemde oorzaken.	CertificateServicesClient gebeurtenislogboek

Validatiecontroles na het oplossen van communicatieproblemen met de CA

Nadat je een oplossing hebt toegepast, controleer dan of het probleem daadwerkelijk is opgelost voordat je het ticket als afgesloten beschouwt.

• rerun Get-Service certsvc en bevestig dat de status 'Actief' is, en niet alleen dat de herstartopdracht zonder fouten is voltooid.
• rerun certutil -config --ping (of het script) certutil -config "<CAName>\<CACommonName>" -ping formulier) en bevestig een succesvolle ping-reactie.
• rerun Test-NetConnection -ComputerName <CA_SERVER> -Port 135 Controleer de RPC-connectiviteit en herhaal dit voor poort 445 als SMB een deel van het probleem was.
• rerun certutil -template Controleer bij de betreffende client of het verwachte sjabloon nu verschijnt.
• Vraag een testcertificaat aan met behulp van de betreffende sjabloon en bevestig dat het certificaat succesvol wordt uitgegeven in plaats van dat de aanvraag mislukt in de beleidsmodule.
• Controleer de gebeurtenislogboeken van CertificateServicesClient en CertificationAuthority op een periode zonder herhaalde fouten na de correctie.

Stappen om terug te keren naar een eerdere versie als een oplossing het probleem niet verhelpt.

Als een wijziging de omgeving verslechtert, of als u wilt terugkeren voordat u verdergaat, kunt u met deze stappen de meest voorkomende wijzigingen uit deze handleiding terugdraaien.

• Als u uitgebreide diagnostische logboekregistratie op de CA hebt ingeschakeld, zet u de registerwaarde terug naar de vorige waarde (meestal 0) en voert u de volgende stappen uit: Restart-Service -Name CertSvc om weer terug te keren naar normale logniveaus.
• Als u machtigingen op CA-niveau of sjabloonniveau hebt gewijzigd, herstel dan de vorige toegangscontrolelijst vanuit uw gedocumenteerde basislijn in plaats van te gokken wat de vorige status was.
• Als u een certificaatsjabloon hebt gedeactiveerd of verwijderd, publiceert u deze opnieuw vanuit Certificaatsjablonen in de CA-console onder Certificaatsjablonen > Nieuw > Certificaatsjabloon om uit te geven.
• Als een wijziging in een firewallregel onderdeel was van de oplossing en dit nieuwe problemen veroorzaakte, ga dan terug naar de eerder geëxporteerde regelset in plaats van ad hoc regels te verwijderen.
• Als het herstarten van de CA-service niet heeft geholpen en de CA vóór een recente wijziging wel werkte, overweeg dan om de CA-server te herstellen vanuit de laatst bekende goede back-up in plaats van door te gaan met het oplossen van problemen tijdens de live-uitvoering.

Hoe kan Encryption Consulting helpen?

Encryption Consulting helpt organisaties bij het beveiligen en beheren van Microsoft Certificate Services door duidelijke richtlijnen te bieden voor het oplossen van communicatieproblemen, het correct instellen van PKI en het automatiseren van certificaatprocessen met CertSecure Manager . We werken samen met klanten om de exacte oorzaak van problemen te achterhalen, zoals service-instellingen, toegangsrechten of netwerkfouten.

CertSecure Manager ondersteunt dit door waarschuwingen te sturen voordat certificaten verlopen, ze automatisch te verlengen om downtime te voorkomen en verbinding te maken met Active Directory om het bedrijfsbeleid voor certificaatgebruik te volgen. Het houdt alle certificaten op één plek bij, controleert op wijzigingen en verwerkt taken zonder constant handmatig werk, wat een meer geautomatiseerd certificaatbeheer biedt.

Het zorgt ervoor dat de CA correct is geïntegreerd met de bedrijfssystemen. Of het nu gaat om een ​​eenmalige storing of de planning van een volledige PKI-implementatie, wij bieden de ondersteuning die nodig is om een ​​betrouwbare, conforme en schaalbare certificaatinfrastructuur te onderhouden.

Conclusie

Door deze stappen te volgen, kunt u de meeste communicatieproblemen met Microsoft CA's systematisch diagnosticeren en oplossen. Deze aanpak zorgt ervoor dat uw PKI-infrastructuur robuust, veilig en geïntegreerd blijft met de certificaatbeheerworkflows van uw organisatie. Proactieve monitoring en auditing van de CA-status en het certificaatgebruik helpen verstoringen te voorkomen, afwijkingen vroegtijdig te detecteren en compliance-inspanningen te ondersteunen. Als u problemen blijft ondervinden, kunt u contact opnemen met PKI-experts voor geavanceerde probleemoplossing en ondersteuning.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie van Microsoft CA Communication?

De belangrijkste conclusie is dat de meeste communicatieproblemen met Microsoft CA's zich in zes controleerbare gebieden bevinden: de status van de CA-service, netwerkpoorten, de reactiesnelheid van de CA, de machtigingen van het serviceaccount, de zichtbaarheid van de certificaatsjabloon en de toegankelijkheid van de certificaatketen of CRL. Door deze gebieden in die volgorde te doorlopen, wordt de oorzaak sneller gevonden dan door te gokken.

Waarom is dit belangrijk voor PKI-teams binnen bedrijven?

Enterprise PKI-teams zijn afhankelijk van Active Directory Certificate Services voor het uitgeven en vernieuwen van certificaten voor gebruikers, computers en applicaties. Wanneer de communicatie met de certificeringsinstantie (CA) verstoord raakt, loopt het uitgeven en vernieuwen van certificaten in de hele omgeving vast. Daarom is een systematisch probleemoplossingsproces belangrijker dan een eenmalige oplossing.

Welke risico's nemen toe als dit onderwerp handmatig wordt behandeld?

Het handmatig en zonder checklist afhandelen van communicatieproblemen met de CA vergroot het risico dat de onderliggende oorzaak, zoals een niet-gepubliceerde sjabloon of een geblokkeerde RPC-poort, over het hoofd wordt gezien. Bovendien kan een oplossing die slechts een symptoom bestrijdt in plaats van het onderliggende probleem, ervoor zorgen dat dezelfde fout zich opnieuw voordoet.

Welke teams zouden verantwoordelijk moeten zijn voor deze verandering?

Het eigenaarschap is doorgaans verdeeld over het Active Directory- of PKI-beheerteam dat de CA en certificaatsjablonen beheert, het netwerkteam dat firewallregels en poorttoegang beheert, en het beveiligingsteam dat de machtigingen op CA- en sjabloonniveau controleert.

Hoe houdt dit verband met certificaatlevenscyclusbeheer?

Communicatie met de certificeringsinstantie (CA) vormt de basis voor het beheer van de certificaatlevenscyclus. Als clients de CA niet kunnen bereiken, geen sjabloon kunnen aanvragen of de certificaatketen en intrekkingsstatus niet kunnen valideren, kan de automatisering van uitgifte en verlenging niet functioneren, ongeacht hoe goed het levenscyclusbeleid is ontworpen.

Hoe moeten organisaties succes meten?

Succes betekent dat de snelle checklist voor probleemoplossing probleemloos is doorlopen, dat er geen herhaalde RPC-, machtigings- of sjabloonfouten in de gebeurtenislogboeken van CertificateServicesClient en CertificationAuthority voorkomen en dat testinschrijvingen succesvol verlopen voor alle certificaatsjablonen waarvan clients afhankelijk zijn.

Wat moet er regelmatig gecontroleerd of gemonitord worden?

Organisaties dienen regelmatig de status van de CA-service, de publicatie en machtigingen van certificaatsjablonen, de bereikbaarheid van CRL- en AIA-eindpunten en de gebeurtenislogboeken van CertificateServicesClient en CertificationAuthority te controleren op terugkerende RPC-, toegang geweigerd- of intrekkingsfouten.

Welke invloed heeft dit onderwerp op cloud-, hybride- of multi-CA PKI-oplossingen?

In hybride omgevingen kunnen communicatieproblemen met Microsoft CA's lastiger te isoleren zijn, omdat clients de CA mogelijk bereiken via VPN's, in de cloud gehoste domeincontrollers of meerdere uitgevende CA's. Dezelfde checklist blijft van toepassing, maar elke CA en elk netwerkpad moet afzonderlijk worden getest in plaats van ervan uit te gaan dat ze zich op dezelfde manier gedragen.

Welke voorwaarden zijn vereist vóór de implementatie?

Controleer vóór het oplossen van problemen of u beheerdersrechten of gedelegeerde toegang hebt tot de CA-server en de betreffende client, of er een PowerShell-sessie met beheerdersrechten op beide is, of u toegang hebt tot certsrv.msc en certtmpl.msc, RSAT als u Get-CATemplate op afstand uitvoert, en of er een gedocumenteerde basislijn is van de huidige machtigingen en gepubliceerde sjablonen waarnaar u indien nodig kunt terugkeren.

Welke veelvoorkomende fouten moeten beheerders in de gaten houden?

Beheerders moeten letten op vermeldingen zoals "RPC Server Unavailable", CERT_E_REVOCATION_FAILURE, CERT_E_CHAINING, CERT_E_UNTRUSTEDROOT, SCEP-fouten 0x80092013 en 0x80094800, en "Access Denied", "Template Not Found" of "Enrollment Failure" in het gebeurtenislogboek van CertificateServicesClient.