Microsoft CA-kommunikation 

När organisationer behöver säkra digital kommunikation, verifiera identiteter eller möjliggöra säker åtkomst till nätverksresurser, vänder de sig ofta till PKI-teknik (Public Key Infrastructure). Kärnan i PKI är certifikatutfärdaren (CA), en betrodd enhet som ansvarar för att utfärda, hantera och validera digitala certifikat. Dessa certifikat är elektroniska autentiseringsuppgifter som binder en offentlig nyckel till en användares, dators eller enhets identitet, vilket möjliggör säker, krypterad kommunikation, autentisering och digitala signaturer. 

Den här artikeln syftar till att hjälpa IT-proffs att diagnostisera och lösa kommunikationsproblem med CA, vilket säkerställer att digitala certifikat kan utfärdas, valideras och användas på ett tillförlitligt sätt för säkra operationer. 

Microsoft implementerar denna teknik som kallas Active Directory Certificate Services (AD CS). AD CS är en Windows Server-roll som gör det möjligt för organisationer att skapa och hantera sina egna interna certifikatutfärdare. AD CS stöder utfärdande av en mängd olika certifikattyper, inklusive: 

• Användarcertifikat: Dessa används för användarautentisering, säker e-post (S/MIME) och digitala signaturer.
• Maskin- (dator-) certifikat: Aktivera dator- och serverautentisering, kryptering och säker kommunikation. 
• Webbservercertifikat: Säkra webbservrar och applikationer med SSL/TLS-kryptering.
• Kodsigneringscertifikat: Dessa används för att signera programvara och skript för att säkerställa deras integritet och äkthet.
• VPN- och fjärråtkomstcertifikat: Säkra fjärranslutningar via VPN och andra fjärråtkomsttekniker. 
• Nätverksenhetscertifikat: Autentisera enheter som routrar, switchar och brandväggar som kanske inte har domänkonton.
• Smartkortcertifikat: Aktivera stark autentisering för användare via smartkort eller hårdvarutokens.

Certifikaten som tillhandahålls av AD CS hjälper till att säkerställa: 

• Sekretess: Endast avsedda mottagare kan läsa data genom att kryptera den. 
• Integritet: Signera data digitalt för att förhindra manipulation.  
• Authentication: Genom att bekräfta identiteten på användare, datorer eller enheter som har åtkomst till nätverksresurser.

Microsoft implementerar den här tekniken via Active Directory Certificate Services (AD CS), en Windows Server-roll som gör det möjligt för organisationer att skapa och hantera sina egna interna certifikatutfärdare (CA).

En Microsoft CA kan konfigureras på flera sätt, bland annat som en rot-CA (din organisations förtroendeankare) eller som en underordnad CA (som utfärdar certifikat under rot-CA:ns auktoritet). Företags-CA:er integreras med Active Directory, vilket möjliggör automatiserad certifikatutfärdande och -hantering, medan fristående CA:er fungerar oberoende och kräver manuellt godkännande av certifikatförfrågningar. 

Att säkerställa tillförlitlig kommunikation med din Microsoft-certifikatutfärdare (CA) är viktigt för alla organisationer som förlitar sig på Active Directory Certificate Services (AD CS) för säker certifikatutfärdande, autentisering eller integration med tredjepartsplattformar. Anta att du upplever problem med certifikatförfrågningar, förnyelser eller integrationsfel. I så fall hjälper den här steg-för-steg-guiden dig att systematiskt verifiera och lösa kommunikationsproblem med Microsoft CA. Låt oss först titta på skillnaderna mellan offentlig CA och MSCA. 

Microsoft CA kontra offentlig CA

För att hjälpa dig att förstå omfattningen av Microsoft CA, här är en kort jämförelse med offentliga CA:er: 

Datum för funktionen	Microsoft CA (AD CS)	Offentlig CA (t.ex. DigiCert, Let's Encrypt)
konfiguration	Lokalt, hanteras internt	Molnbaserat, leverantörshanterat
Förtroendeomfattning	Interna användare, system och tjänster	Allmänhetens förtroende över webbläsare, enheter
Valideringsmodell	AD-baserad automatisering	Domänvalidering (DV), organisationsvalidering (OV) eller utökad validering (EV)
Kostnadsmodell	Infrastruktur- och underhållskostnader	Per-certifikat eller prenumerationsavgift
Bäst för	Interna appar, servrar, enheter, VPN, S/MIME	Webbplatser, externa appar, API:er
Support och servicenivåavtal	Intern IT- eller Microsoft-support	Leverantörslevererade servicenivåavtal, support

Steg-för-steg-guide  

1. Bekräfta att Microsoft CA-tjänsten körs 

Vi börjar med att säkerställa att CA-tjänsten är aktiv på servern. Innan du felsöker certifikatrelaterade problem, börja alltid med att bekräfta att certifikatutfärdartjänsten (CA) körs på servern. Detta är avgörande eftersom om CA-tjänsten stoppas kan inga certifikatförfrågningar behandlas, och all felsökning efterföljande program kommer att vara ineffektiv och slösa bort värdefull tid. Öppna ett PowerShell-fönster och kör: 

Get-Service certsvc 

Utdata bör indikera tjänstens status som "Körs". Alternativt kan du öppna tjänsthanteringskonsolen (services.msc) och kontrollera att "Active Directory Certificate Services" körs. 

Om tjänsten har stoppats kan en snabb omstart ofta lösa problemet. Använd följande PowerShell-kommando för att starta eller starta om tjänsten: 

Omstartstjänst certsvc

Kontrollera alltid Windows Loggbok för tjänstrelaterade fel eller varningar efter att du har startat om tjänsten. Öppna Loggboken genom att söka efter eventvwr.msc. Navigera till Program- och tjänstloggar > Microsoft > Windows > Certifieringsutfärdare.

Granska de senaste händelserna för fel, varningar eller informationsmeddelanden relaterade till CA-tjänsten. Var särskilt uppmärksam på loggar med händelse-ID:n som 58 (problem med certifikatkedjan), 4886 (certifikatförfrågningar) och andra relevanta poster, eftersom dessa kan ge insikt i underliggande problem eller bekräfta lyckade åtgärder. 

2. Verifiera nätverksanslutning och nödvändiga portar 

Se till nödvändiga portar är öppna för CA-kommunikation. 

Nödvändiga portar: 

• TCP 135 – RPC-slutpunktsmappare
  Den används för initial klient/server-förhandling för RPC-kommunikation. 
• TCP 445 – SMB (används för certifikatmallar och gruppolicy)
  Det krävs för åtkomst till certifikatmallar (lagrade i AD), GPO-distribution och DCOM.
• Dynamiska RPC-portar – TCP 49152–65535 (för Windows Server 2012 och senare) 
  Den används efter att RPC Endpoint Mapper tilldelat en hög port för kommunikation.
• TCP 88 – Kerberos (för domänautentisering) 
  Den hanterar domänautentisering när en användare eller dator begär certifikat.

Varför är dessa hamnar viktiga?

• Kerberos (TCP 88): Krävs för domänanslutna maskiner för att autentisera mot certifikatutfärdaren, särskilt vid automatisk registrering eller åtkomst till certifikatmallar. 
• SMB (TCP 445): Åtkomst till certifikatmallar och CA-policyer som lagras i Active Directory är beroende av SMB.
• RPC/Höga portar (TCP 135 + 49152–65535): Kärna för DCOM- och RPC-anrop som används av certreq-, certutil- och MMC-snapin-moduler och vid fjärrbegäran av certifikat.

Testa anslutning med PowerShell: 

Test-NetConnection-Datornamn -Port 135

Ett lyckat test indikerar att porten är öppen. 

Vanliga problem: 

Brandväggar som blockerar obligatoriska portar. Så här listar du alla brandväggsregler som kan påverka CA-kommunikation: 

Get-NetFirewallRule 

Nätverkssegmentering förhindrar kommunikation. 

Testar anslutning med Telnet (om det är installerat): 

telnet 135
telnet 445 

Om skärmen blir tom efter att du tryckt på Enter är porten öppen. 
Om det står "Kunde inte öppna anslutningen" är porten blockerad. 

3. Testa CA-responsivitet med Certutil 

Kontrollera att certifikatutfärdaren är nåbar och svarar. Om den misslyckas indikerar det att ditt system inte kan kommunicera korrekt med certifikatutfärdaren (CA). Detta fel kan tyda på flera underliggande problem som anges nedan: 

Steg: 

Öppna Kommandotolken eller PowerShell på en klientdator och kör följande kommando. Det rekommenderas också att certutil kommandot kan provas från både klienten och själva CA-servern. 

certutil -config – -ping 

Du kommer att bli ombedd att välja CA. Ett lyckat svar bekräftar att CA är nåbar.

Uppmanar dig att välja CA från en lista. Ett lyckat svar bekräftar att CA är nåbar. 

Skriptstyrd/automatiserad kontroll: 

certutil -config “ \ "-ping" 

Ersätta \ med den fullständiga konfigurationssträngen för din CA (t.ex. CA-SERVER\My-Enterprise-CA). Detta kör kontrollen direkt mot den angivna CA:n, vilket gör den lämplig för skript och automatisering. 

Vanliga problem: 

• "RPC-servern är inte tillgänglig" Fel indikerar kommunikationsavbrott. Ett exempel på ett sådant fel är: 

Om du får ett sådant felmeddelande kan det hända att CA:n inte kan nås av systemet, är felkonfigurerad eller blockerad av säkerhetspolicyer. 

• DNS-upplösningsfel – CA:ns värdnamn kan inte matchas 
• Brandväggsbegränsningar – Nödvändiga portar (t.ex. TCP 135 för RPC) är blockerade 
• CA-tjänsten är offline – CA-servern är nere, eller så är certifikattjänsten stoppad 
• Nätverkssegmentering – Routing eller VLAN-isolering förhindrar kommunikation

Sådana problem hindrar klienter från att upptäcka eller registrera sig hos CA:n. 

4. Verifiera behörigheter för tjänstkonto 

Kontot som används för att kommunicera med certifikatutfärdaren måste ha specifika behörigheter för certifikatutfärdaren och certifikatmallarna. 

Kontrollera behörigheter på CA-nivå

1. Öppna Certifieringsmyndighet konsolen på CA-servern (certsrv.msc)
2. Högerklicka på certifikatutfärdaren och välj Våra Bostäder 
3. Navigera till Säkerhet fliken 
4. Bekräfta att tjänstkontot har behörighet att Begär certifikat. 

För mer detaljerad granskning eller skriptning kan du använda verktyg som dsacls:

dsacls “CN=Public Key Services,CN=Tjänster,CN=Konfiguration,DC=domän,DC=com”

Detta är för att granska delegerade behörigheter i Active Directory med PowerShell:

Get-ADPermission -Identitet "CA_namn" -Användare "Tjänstkontonamn"

Dessa verktyg hjälper till att verifiera om tjänstkontot har beviljats ​​nödvändiga rättigheter via AD-delegering, särskilt i större eller automatiserade miljöer.

Så här kontrollerar du behörigheter på mallnivå:

1. Öppna Certifikatmallar snapin-modulen (certtmpl.msc)
2. Högerklicka på relevant certifikatmall och välj Våra Bostäder
3. I Säkerhet fliken, bekräfta att kontot har Läsa, Skriva in, och, om det behövs, Autoregistrering behörigheter

Dessa behörigheter måste beviljas via Active Directory och kan kräva en uppdatering av grupprincipen för att gälla. För att kontrollera att rätt grupprinciper har tillämpats, kör följande på klientsystemet:

gpresult /r

Det här kommandot visar de tillämpade grupprincipinställningarna och kan hjälpa till att bekräfta om automatisk registrering eller certifikatrelaterade principer är aktiva på datorn.

Tips: Om en certifikatmall är publicerad men inte synlig eller kan användas av ett tjänstkonto är det vanligtvis ett problem med behörigheter på mallnivå. Om inga mallar fungerar alls börjar du med att kontrollera behörigheter på certifikatutfärdarnivå.

Typiska roller som interagerar med CA:n:

1. NDES-tjänstkonto
   Används av Network Device Enrollment Service för begäranden om enhetscertifikat.
   Behöver "Begär certifikat" hos CA och läs/registrera mallar. 
2. Automatisk registrering av klienter
   Domändatorer/användare registrerar sig automatiskt för certifikat.
   Kräv "Begär certifikat" hos CA och läs, registrera (automatisk registrering om det används) på mallar.
3. Applikations-/Integrationskonton
   Används av appar/tjänster (t.ex. SCEP) för certifikatautomation.
   Behöver "Begär certifikat" hos CA och läs/registrera mallar.
4. Administratörer
   Kräver full kontroll.
   Hantera CA och mallar.

5. Se till att certifikatmallar är publicerade och synliga

Om din förväntade certifikatmall inte är tillgänglig kanske den inte publiceras, eller så kanske ditt konto inte syns. Öppna certifikatutfärdaren (certsrv.msc).

Högerklicka på "Certifikatmallar" och välj "Nytt" > "Certifikatmall att utfärda".

Välj och publicera önskad mall.

Från en domänansluten klient kan du lista alla tillgängliga mallar med följande kommando:

certutil-mall

Om din mall inte visas, kontrollera behörigheter och publiceringsstatus på CA. Det är viktigt att notera att replikeringsfördröjningar i Active Directory kan påverka synligheten för nya eller uppdaterade mallar på olika domäner eller webbplatser. Det kan ta lite tid innan ändringar som görs på CA:n eller i mallbehörigheterna sprids och blir synliga för alla klienter.

Så här listar du alla mallar som för närvarande är utfärdade (publicerade) av CA med PowerShell:

Hämta CAT-mall

Detta kräver CertificateServices-modulen, som måste köras på CA:n eller en maskin med RSAT (Remote Server Administration Tools) installerat.

6. Granska händelseloggar för CA-relaterade fel

På CA-servern öppnar du Loggboken och navigerar till följande plats:

Program- och tjänstloggar > Microsoft > Windows > CertificateServicesClient

Granska både drifts- och felsökningsloggar för fel som "Åtkomst nekad", "RPC otillgänglig", "Mall hittades inte" eller "Registreringsfel". Dessa loggar pekar ofta direkt på behörighetsproblem, anslutningsfel eller felkonfigurationer.

För fullständig insikt, kontrollera händelseloggarna på både CA-servern och klientdatorerna. Klientsidesloggar kan avslöja problem med policyapplikationer, registreringsfel eller anslutningsproblem som kanske inte visas i CA:ns loggar. Om du vill ha en mer avancerad felsökning kan du också överväga att aktivera utförlig/felsökningsloggning för certifikattjänstkomponenten (certsvc) genom att lägga till följande registervärde:

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration
Värde: Diagnostisk
Typ: REG_DWORD
Data: 0x0000ffff

Efter att du har tillämpat ändringen, starta om certifikattjänsterna för att aktivera detaljerad loggning med PowerShell:

Omstartstjänst - Namn CertSvc

7. Validera certifikatkedjan och CRL-tillgängligheten

En vanlig orsak till kommunikationsproblem är en ofullständig eller opålitlig certifikatkedja. Säkerställ:

• CA:s rot- och mellanliggande certifikat finns i lämpliga arkiv för "Tillförlitliga rotcertifieringsutfärdare" och "Mellanliggande certifieringsutfärdare".
• Slutpunkter för certifikatåterkallningslistan (CRL) är åtkomliga från klientenheter och integrationsservrar.

Du kan kontrollera certifikatarkiv med hjälp av:

certlm.msc

Och verifiera CRL-åtkomst med:

certutil -verify -urlfetch

Ersätta med sökvägen till din certifikatfil. För att direkt bekräfta att CRL-distributionspunkter (CDP:er) är nåbara, öppna CRL-URL:en i en webbläsare eller använd ett verktyg som curl:

curl -I http://

Ett lyckat HTTP 200-svar indikerar att CRL:n är tillgänglig. Det här steget hjälper till att utesluta brandväggs- eller DNS-problem som påverkar CRL:ns tillgänglighet, vilket kan leda till certifikatförtroende eller återkallningsfel under validering.

För att analysera innehållet i en nedladdad CRL, använd OpenSSL-kommandot:

openssl crl-in -ingenut -text

Det här kommandot visar CRL-metadata, återkallningsposter och utfärdarens information. Det hjälper till att verifiera att CRL:n är korrekt utfärdad och uppdaterad.

Teknisk påverkan av CRL- eller AIA-fel:

Misslyckanden med att komma åt CRL- eller AIA-URL:er kan störa certifikatvalideringen, vilket leder till en mängd olika driftsproblem. Dessa uppstår vanligtvis på grund av DNS-upplösningsproblem, brandväggsblockeringar, felkonfigurationer av HTTP-proxy eller saknade publiceringsinställningar hos certifikatutfärdaren. Nedan följer viktiga tekniska manifestationer av sådana fel:

1. Valideringsfel för certifikatkedjan
   Certifikatvalidering kan misslyckas under kedjebyggandet, vilket utlöser fel som CERT_E_REVOCATION_FAILURE, CERT_E_CHAINING eller CERT_E_UNTRUSTEDROOT. Dessa indikerar problem med att nå återkallnings- eller AIA-slutpunkter.
2. SCEP och autoregistreringsfel
   Registreringsåtgärder kan misslyckas med specifika felkoder, till exempel:
   • 0x80092013: Återkallningsserver offline
   • 0x80094800: Ogiltig certifikatutfärdare
   Dessa fel återspeglar oförmågan att hämta information om återkallelsesstatus eller behörighet.
3. TLS/SSL-handskakningsfel
   Klienter kan avvisa servercertifikat under TLS/SSL-förhandlingar på grund av ofullständiga kedjor eller otillgängliga CRL/AIA-URL:er. Detta kan avbryta säker kommunikation för tjänster som HTTPS, LDAPS eller VPN.
4. Händelseloggindikatorer
   Loggarna i Windows Loggbok kan registrera relevanta poster under CertificateServicesClient eller Schannel, vilket indikerar timeouts för återkallningskontroll, kedjekonstruktionsfel eller nedladdningsfel från CDP/AIA-URL:er.
5. Fel vid hämtning av OCSP och CRL
   Försök att hämta återkallningsdata via OCSP eller CRL kan misslyckas på grund av:
   • DNS-upplösningsproblem 
   • Felaktiga eller oåtkomliga webbadresser
   • HTTP-proxybegränsningar
   • Saknade eller felkonfigurerade CA-publikationer

Dessa problem kan i tysthet bryta förtroendevalideringsprocesser om de inte övervakas aktivt.

Snabb felsökningschecklista

Steg	Kommando/Plats	Förväntat resultat	felsökningstips
CA-tjänstens status	Get-Service certsvc	Tjänsten är igång	Om den inte körs, kontrollera Windows händelseloggar för fel. Försök att starta om tjänsten. Se till att beroenden är uppfyllda.
Portanslutning	Test-NetConnection-Datornamn -Port 135	Anslutningen lyckades	Om det misslyckas, kontrollera brandväggsinställningar, nätverksanslutning och att RPC (port 135) är öppen mellan klienten och certifikatutfärdaren.
CA-ping	certutil -config – -ping	"Ping slutförd."	Om det misslyckas, kontrollera nätverksanslutningen, CA-tjänstens status och DNS-upplösningen för CA-servern.
Mallens synlighet	certutil-mall	Mallen är listad	Om mallen saknas, se till att den är publicerad på CA:n och att AD-replikeringen är klar. Kontrollera mallbehörigheterna.
behörigheter	certsrv.msc > Säkerhet	Nödvändiga behörigheter beviljas	Om behörigheter saknas, granska och tilldela nödvändiga rättigheter till användare/grupper. Kontrollera om det finns konflikter med grupprinciper.
Händelseloggar	Loggboken (gruppera efter "Nätverk", "Tjänst", "Behörigheter", "Mallar")	Inga RPC- eller behörighetsfel	Om fel förekommer, granska detaljerna för att hitta ledtrådar. Filtrera loggar för relevanta fel. Åtgärda problem enligt felkoder.

Hur kan krypteringskonsulting hjälpa till?

Krypteringskonsulttjänster hjälper organisationer att säkra och hantera Microsoft Certificate Services genom att ge tydlig vägledning om hur man åtgärdar kommunikationsproblem, upprättar PKI korrekt och automatisera certifikatprocesser med CertSecure-hanterareVi arbetar med kunder för att hitta den exakta orsaken till problem som tjänstinställningar, åtkomstbehörigheter eller nätverksfel.

CertSecure Manager stöder detta genom att skicka aviseringar innan certifikat löper ut, förnya dem automatiskt för att undvika driftstopp och ansluta till Active Directory för att följa företagets policyer för certifikatanvändning. Den håller reda på alla certifikat på ett ställe, övervakar eventuella ändringar och hanterar uppgifter utan att behöva ständigt manuellt arbete, vilket erbjuder en mer automatiserad certifikathantering.

Det säkerställer att CA:n är korrekt integrerad med företagets system. Oavsett om det gäller ett engångsavbrott eller en fullständig PKI-distribution, tillhandahåller vi det stöd som behövs för att upprätthålla en pålitlig, kompatibel, skalbar certifikatinfrastruktur.

Slutsats

Genom att följa dessa steg kan du systematiskt diagnostisera och lösa de flesta kommunikationsproblem med Microsoft CA. Denna metod säkerställer att din PKI-infrastruktur förblir robust, säker och integrerad med organisationens arbetsflöden för certifikathantering. Proaktiv övervakning och granskning av CA:s hälsa och certifikatanvändning hjälper till att förhindra störningar, upptäcka avvikelser tidigt och stödja efterlevnadsarbetet. Om du fortsätter att stöta på utmaningar kan du överväga att kontakta PKI-experter för avancerad felsökning och support.