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. 

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). 

Microsoft CA versus openbare CA

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

Feature-datum	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

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 opstarten van de service altijd de Windows Logboekviewer op servicegerelateerde fouten of waarschuwingen. Open de event Viewer door te zoeken naar eventvwr.msc. Navigeer naar Logboeken Toepassingen en Services > 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 

Verzekeren benodigde poorten staan ​​open 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 die vereiste poorten blokkeren. Om alle firewallregels te bekijken die CA-communicatie kunnen beïnvloeden: 

Get-NetFirewall-regel 

Netwerksegmentatie verhindert communicatie. 

Connectiviteit testen via 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: certutil De opdracht kan zowel door de client als door de CA-server zelf worden geprobeerd. 

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 respons 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). Hierdoor wordt de controle rechtstreeks op de opgegeven CA uitgevoerd, 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”

Hiermee worden gedelegeerde machtigingen in Active Directory gecontroleerd met behulp van 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 geen enkele sjabloon werkt, controleer dan eerst de machtigingen op CA-niveau.

Typische rollen die met de CA interacteren:

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 wordt weergegeven, controleer dan de machtigingen en publicatiestatus op de CA. Houd er rekening mee dat replicatievertragingen in Active Directory de zichtbaarheid van nieuwe of bijgewerkte sjablonen in verschillende domeinen of sites kunnen beïnvloeden. Het kan enige tijd duren voordat de wijzigingen die in de CA of in de sjabloonmachtigingen worden aangebracht, zijn doorgevoerd en voor alle clients zichtbaar zijn.

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 volledig inzicht kunt u de gebeurtenislogboeken op zowel de CA-server als de clientcomputers raadplegen. Logboeken aan de clientzijde kunnen problemen met de beleidstoepassing, inschrijvingsfouten of verbindingsproblemen aan het licht brengen die mogelijk niet in de logboeken van de CA worden weergegeven. Als u een meer geavanceerde probleemoplossing nodig hebt, kunt u uitgebreide/foutopsporingsregistratie inschakelen voor de component Certificate Services (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.

Hoe kan Encryption Consulting helpen?

Encryption Consulting helpt organisaties bij het beveiligen en beheren Microsoft-certificaatservices door duidelijke richtlijnen te geven voor het oplossen van communicatieproblemen, het opzetten van PKI correct en het automatiseren van certificaatprocessen met CertSecure ManagerWij werken samen met klanten om de exacte oorzaak van problemen te vinden, 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 bedrijfssystemen. Of het nu gaat om een ​​eenmalige uitval of een volledige PKI-implementatie, wij bieden de ondersteuning die nodig is om een ​​betrouwbare, compliant, schaalbare certificaatinfrastructuur.

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 overwegen contact op te nemen met PKI-experts voor geavanceerde probleemoplossing en ondersteuning.