Aktivera LDAPS med Microsoft PKI

LDAPS krypterar LDAP-trafik mellan klienter och domänkontrollanter genom att omsluta standard LDAP-kommunikation i TLS, med hjälp av ett serverautentiseringscertifikat som utfärdats från din Microsoft PKI. Utan LDAPS skickar LDAP-enkla bindningar användarnamn och lösenord över nätverket i klartext, synliga för alla som kör en paketinsamling.

Detta är särskilt riskabelt med en enkel LDAP-bindning, där autentiseringsuppgifter skickas okrypterade från början till slut. En enda paketinsamling via kabeln, eller en komprometterad switchport, räcker för att samla in domänautentiseringsuppgifter. LDAPS täcker det gapet genom att binda ett certifikat till domänkontrollanten och kräva TLS för anslutningen.

Den här guiden täcker hela processen: förutsättningar, installation och konfiguration av AD LDS vid behov, utfärdande och bindning av ett serverautentiseringscertifikat från din Microsoft PKI, validering av LDAPS-anslutningen med ldp.exe, de fel som administratörer oftast stöter på och hur man återställer systemet på ett säkert sätt om något går sönder.

Key Takeaways

• LDAPS kräver ett certifikat med Server Authentication EKU, utfärdat från en certifikatutfärdare som varje klient litar på, kopplat till varje domänkontrollant eller AD LDS-instans som behöver acceptera krypterade LDAP-anslutningar.
• Det vanligaste felet efter aktivering av LDAPS är en Schannel-händelse 36870 eller 36872, orsakad av en trasig certifikatkedja, ett utgånget certifikat eller begränsande behörigheter på maskinens nyckelarkiv, inte en felkonfigurerad klient.
• Validera varje LDAPS-distribution med ldp.exe över port 636 (eller 50001 för AD LDS) innan du förlitar dig på den i produktion, och bekräfta certifikatets återstående giltighet snarare än att anta att det kommer att fortsätta fungera.
• Behandla LDAPS-certifikatet som vilken annan hanterad PKI-tillgång som helst: spåra dess utgångsdatum, automatisera förnyelse och övervaka Schannel- och CAPI2-händelseloggar, istället för att upptäcka fel när en katalogberoende applikation går ner.
• Företag som förlitar sig på manuella certifikatprocesser rapporterade certifikatrelaterade driftstopp i 45 % av fallen under det senaste året, varav 37.5 % av dessa avbrott orsakades specifikt av ett utgånget certifikat, enligt DigiCerts Trust Pulse Survey, publicerad 2 juli 2025.

Vem borde bry sig om att aktivera LDAPS

Att aktivera LDAPS berör fler roller än personen som kör guiden. Här är vad varje team faktiskt bör göra med den här guiden.

• PKI-administratörer äga certifikatmallen, utfärdandepolicyn och bindningen per domänkontrollant. Åtgärd: granska varje domänkontrollants utgångsdatum för bundna certifikat denna vecka.
• Säkerhetsarkitekter besluta om huruvida LDAP-kanalbindning och signering ska tillämpas i hela organisationen när LDAPS är live. Åtgärd: dokumentera tillämpningspolicyn och en stegvis utrullningsorder innan strikt tillämpning aktiveras.
• Plattforms- och identitetsteam Använd domänkontrollanterna och AD LDS-instanserna dagligen. Åtgärd: schemalägg certifikatinstallation i ett underhållsfönster och validera med ldp.exe före en bred utrullning.
• Efterlevnad och GRC mappa LDAPS-kryptering till det ramverk som kräver krypterad katalogtrafik internt. Åtgärd: lägg till LDAPS-certifikatstatus i nästa PKI-granskningschecklista.
• CISO: er ta ansvar för den bredare berättelsen om att minska risken för manuella certifikat i hela miljön. Åtgärd: spåra LDAPS-certifikatens hälsa som en enda post inom samma program som tar itu med den branschövergripande utvecklingen mot kortare livslängder för certifikat.

Förutsättningar

En fungerande Microsoft PKI bör vara tillgänglig och konfigurerad. Inga felmeddelanden bör visas när PKIView.msc visas.

Om du behöver hjälp med att distribuera din egen PKI kan du läsa den här artikeln för att bygga din egen tvånivå-PKI.

Utöver en sund PKI-hierarki, bekräfta vart och ett av dessa innan du börjar:

• En utfärdande certifikatutfärdare som är nåbar från varje domänkontrollant eller AD LDS-server som behöver ett certifikat
• Företagsadministratörsrättigheter på domänen och lokala administratörsrättigheter på målservern
• En certifikatmall som stöder Server Authentication EKU (genomgången nedan duplicerar standardmallen för Kerberos-autentisering för detta)
• Nätverksåtkomst från LDAP-klienter till TCP 636, eller TCP 50001 om du använder AD LDS med standard SSL-portar, inte bara port 389
• En återställningsplan och ett underhållsfönster, eftersom bindning av ett certifikat till en domänkontrollant aldrig bör behandlas som en ändring med noll risk

Installera AD LDS

Detta steg bör utföras på LDAP-servern eller på domänkontrollanter som skulle ansvara för att vara värd för LDAPS-tjänsten.

• Öppet server manager
• Från hantera, öppen Lägg till roller och funktioner
• På Innan du börjar klickar du på Nästa

• On Installationstyp, säkerställa Rollbaserad eller funktionsbaserad installation, och klicka Nästa

• On Serverval, klicka på Nästa.

• On Serverroller, klicka på Active Directory Lightweight Directory-tjänster, och klicka Lägg till funktionerOch klicka sedan på Nästa

• On Funktioner, klicka på Nästa

• On AD LDS, klicka på Nästa

• On Bekräftelse, klicka på installera

• Efter installationen måste AD LDS konfigureras

Konfigurera AD LDS

• Körning AD LDS installationsguiden. Klicka Nästa på första sidan.

• Se till unik instans är valt och klicka på Nästa

• Ge Instansnamn och BESKRIVNING, och klicka Nästa

• Lämna standardportar och klicka Nästa

Om AD LDS är installerat på domänkontrollanten är LDAP-porten 50000 och SSL-porten 50001.

• On Programkatalogpartition, klicka på Nästa

• On Filplatser, klicka på Nästa

• On Val av servicekonto, du kan lämna den kvar på Nätverkstjänstkonto, eller välj en föredraget konto som kan styra LDAPS-tjänsten

• On AD LDS-administratörer, lämna nuvarande administratör, eller välj ett annat konto från domänen

• Välja alla LDF-filer som ska importeras och klicka på Nästa

• On Redo att installeras, klicka på Nästa

• Efter installationen klickar du på Finish

Publicera ett certifikat som stöder serverautentisering

• Logga in på den utfärdande certifikatutfärdaren som företagsadministratör
• Se till att du är med server manager
• Från Verktyg meny, öppna certifikatutfärdare

Expandera konsolträdet och högerklicka på Certifikatmallar

• Välja Kerberos-autentisering (eftersom det tillhandahåller serverautentisering). Högerklicka och välj Duplicera mallVi kan nu anpassa mallen.

• Ändra Mallens visningsnamn och Mallnamn on Allmänt flik. Kontrollera Publicera certifikat i Active DirectoryDetta säkerställer att certifikatet visas när vi registrerar domänkontrollanter med hjälp av den mallen.

• On Begäran Hantering, kolla upp Tillåt export av privat nyckel.

• På Fliken Säkerhet, tillhandahålla Registrera behörigheter till lämpliga användare

• Klicka Ansök

Utfärda certifikatet vid utfärdande av CA

• Logga in på den utfärdande certifikatutfärdaren som företagsadministratör
• Se till att du är med server manager
• Från Verktyg meny, öppna certifikatutfärdare

Expandera konsolträdet och klicka på Certifikatmallar

I menyraden klickar du på Åtgärd > Nytt > Certifikatmall att utfärda

• Välj LDAPS-certifikat

• Klicka OK och det borde nu visas i certifikatmallarna

Begär ett certifikat för serverautentisering

• Logga in på LDAP-servern eller domänkontrollanten.
• Typ vinst+R och springa mmc
• Klicka Fil och klicka Lägg till / ta bort snapin-

• Välj Certifikat och klicka på Lägg till

• Välj datorkonto

• Om stegen följs på LDAPServer där AD LDS är installerat, klicka på Lokal dator eller välj En annan dator och välj var den skulle behöva installeras.

• Expandera konsolträd, och inuti Personlig, klicka på Certifieringar

• Högerklicka på Certifieringar och klicka Alla uppdrag och välj Begär nytt certifikat

• Följ instruktionerna, välj LDAPS-mallen som vi utfärdade tidigare och installera.
• När installationen är klar klickar du på Slutför

• Öppna certifikatet och i Fliken Detaljer, navigera till Förbättrad nyckelanvändning att säkerställa Serververifiering är närvarande.

Validerar LDAPS-anslutning

• Logga in på LDAP-servern som företagsadministratör
• Typ vinst+R och springa ldp.exe
• Klicka på Anslutningar i den översta menyn och klicka sedan på Anslut

• Ange domännamnet på servern, se till att SSL är markerat och att rätt port har angetts och klicka på OK

• Inga felmeddelanden bör visas. Om anslutningen misslyckades kan följande utdata visas.

Vanliga fel och hur man åtgärdar dem

Det här är de fel som administratörer stöter på oftast när de aktiverar LDAPS, och vad som faktiskt orsakar dem.

Schannel-händelse 36870 eller 36872 (certifikat- eller nyckelproblem)

Båda händelserna pekar på ett problem med själva servercertifikatet, inte LDAP-konfigurationen. Fem orsaker står för nästan alla händelser: felaktiga ACL:er i MachineKeys-mappen som blockerar systemkontot från att läsa den privata nyckeln, en certifikatåterkallningskontroll som misslyckas eftersom domänkontrollanten inte kan nå en CRL- eller OCSP-responder, en trasig certifikatkedja eftersom rot-CA:n inte finns i den betrodda rotarkivet, ett certifikat med ett saknat eller felaktigt alternativt ämnesnamn som inte matchar domänkontrollantens DNS-namn, eller ett utgånget certifikat. certutil -v -verify -urlfetch <cert.cer> under systemkontexten (med hjälp av psexec -s) för att bekräfta vilken av de fem som gäller.

ldp.exe visar "Kan inte öppna anslutningen" eller "Ett lokalt fel uppstod"

Detta betyder nästan alltid att port 636, eller AD LDS SSL-porten (50001 som standard), inte lyssnar eller är blockerad av en brandvägg, eller att inget giltigt certifikat är bundet till servern ännu. Kontrollera att certifikatet visas i datorns personliga arkiv med serverautentisering i dess utökade nyckelanvändning innan du felsöker nätverkssökvägen.

Certifikatet saknar serverautentiserings-EKU

Om certifikatmallen duplicerades från något annat än Kerberos-autentisering, eller om den utökade nyckelanvändningen redigerades under anpassningen, kommer Schannel inte att erbjuda certifikatet för LDAPS även om det är korrekt bundet. Återutfärda från en mall som har serverautentisering i sin utökade nyckelanvändning.

Trasig certifikatkedja på klienten

LDAPS misslyckas på klientsidan när den utfärdande certifikatutfärdarens rot inte finns i den maskinens arkiv för betrodda rotcertifikatutfärdare. Detta är vanligt på klienter som inte är domänanslutna, hoppboxar och tredjepartsprogram som utför LDAP-bindningar. Distribuera rotcertifikaten och eventuella mellanliggande certifikat explicit till dessa maskiner snarare än att anta att domänanslutet förtroende täcker dem.

CRL- eller OCSP-hämtningsfel

Domänkontrollanter validerar LDAPS-certifikatets återkallningsstatus som en del av TLS-handskakningen. Om en CRL-distributionspunkt eller OCSP-responder inte kan nås, sitter bakom en autentiserande proxy som systemkontot inte kan passera igenom, eller är offline, misslyckas certifikatvalideringen trots att själva certifikatet är felfritt. Aktivera CAPI2-loggning för att bekräfta att detta är orsaken innan du antar att certifikatet är felaktigt.

Återställningssteg

Om LDAPS orsakar ett avbrott eller förstör en beroende applikation, återställ den medvetet istället för att inaktivera en säkerhetskontroll som en genväg.

• Kontrollera om det tidigare certifikatet fortfarande är tillgängligt, antingen exporterat som en säkerhetskopia eller fortfarande finns men ersatt. Om så är fallet, bind det igen i datorns personliga arkiv istället för att lämna servern utan ett giltigt serverautentiseringscertifikat.
• Om inget tidigare certifikat finns, ta bort det nyligen utfärdade certifikatet från den personliga arkivet och återställ domänkontrollanten till endast LDAP tills ett korrigerat certifikat är klart att utfärdas på nytt.
• Om problemet kan spåras till nyligen aktiverad LDAP-kanalbindning eller signeringstvingande, återställ det relevanta registervärdet till dess tidigare, mindre strikta inställning, endast tillräckligt länge för att åtgärda den äldre klienten eller applikationen som orsakar felet, och återaktivera sedan tvungenheten. Låt inte tvungenheten vara permanent avslappnad som lösning.
• Validera med ldp.exe efter varje återställningssteg och dokumentera grundorsaken innan du försöker göra ändringen igen.
• Inaktivera inte kontroll av återkallning av certifikat som en lösning på ett CRL- eller OCSP-fel. Åtgärda anslutningen till återkallningsslutpunkten istället, eftersom inaktivering av återkallningskontroll tar bort exakt den kontroll som LDAPS är avsedd att ge.

Snabbreferens: Förutsättningar, validering, fel och återställning steg för steg

Använd den här tabellen som en checklista under hela utrullningen, från malldesign till validering.

Förutsättning	Kommando / Konfiguration	Valideringskontroll	Vanligt fel	rollback	Ägare
Hälsosam PKI-hierarki	Kör PKIView.msc på varje certifikatutfärdare	Inga felikoner visas i PKIView	Trasig kedja eller en återkallad mellanhand	Åtgärda hierarkin innan du fortsätter; det här steget har ingen egen återställning	PKI-administratör
Mall för serverautentiseringscertifikat	Duplicera Kerberos-autentiseringsmallen; aktivera "Publicera certifikat i Active Directory"	Mallen visas i konsolen för certifikatmallar med rätt EKU	Mallen saknar serverautentiserings-EKU	Ta bort mallen från "Certifikatmallar att utfärda"	PKI-administratör
Mall utfärdad av CA	Certifikatutfärdarkonsol > Åtgärd > Ny > Certifikatmall att utfärda	Mallen finns listad under den utfärdande CA:n	Mallen är inte synlig för den begärande servern (registreringsbehörigheter)	Högerklicka på mallen > Alla uppgifter > Utfärda inte	PKI-administratör
Certifikat begärt och bundet på servern	mmc > Certifikat (Datorkonto) > Begär nytt certifikat	Certifikatet visas i den personliga arkivet med serverautentisering i utökad nyckelanvändning	Schannel-händelse 36870 eller 36872 (ACL, kedja, SAN eller utgångsproblem)	Ta bort certifikatet från den personliga arkivet; återställ det tidigare certifikatet om ett sådant fanns.	Plattform/Identitetsteam
LDAPS-anslutning validerad	ldp.exe > Anslutning > Anslut (SSL kontrollerad, port 636 eller 50001)	Ansluter utan felmeddelande	"Kan inte öppna anslutningen" (porten är blockerad eller inget certifikat är bundet)	Återställ brandväggsregeln eller bind om det tidigare certifikatet	Plattform-/identitetsteam, med nätverksteam
Kanalbindning / LDAP-signeringstillämpning (valfri härdning)	Ange registervärdet LdapEnforceChannelBinding	Äldre LDAP-klienter autentiserar fortfarande efter tillämpning	Äldre applikationer går sönder under strikt tillämpning	Återställ tillämpningen till ett tillåtande värde tillfälligt medan klientprogrammet åtgärdas	Säkerhetsarkitekt

Hur aktivering av LDAPS ansluter till hantering av certifikatlivscykel

LDAPS-certifikatet som är bundet till en domänkontrollant är inget specialfall. Det är ytterligare ett kortlivat, förnybart certifikat som kommer att löpa ut, behöva roteras och så småningom behöva utfärdas på nytt mot en ny mall eller algoritm. Att behandla det som en engångsuppgift för installation är precis det manuella mönster som producerar certifikatrelaterade avbrott på andra ställen i miljön: DigiCerts Trust Pulse Survey, publicerad 2 juli 2025, fann att 45 % av företagen upplevde certifikatrelaterade driftstopp under det senaste året, varav 37.5 % av dessa incidenter orsakades specifikt av ett utgånget certifikat. En domänkontrollant som förlorar sitt LDAPS-certifikat i tysthet är samma felläge med en mer störande explosionsradie, eftersom varje LDAP-beroende applikation och inloggningsväg bakom den domänkontrollanten påverkas samtidigt.

Plattformar för hantering av certifikatlivscykeln, som CertSecure Manager, täcker denna lucka genom att upptäcka varje certifikat som är bundet mellan dina domänkontrollanter och AD LDS-instanser, spåra utgångsdatum centralt och automatisera förnyelse innan en administratör först behöver upptäcka ett Schannel-fel. Om du redan moderniserar certifikatåtgärder någon annanstans i miljön kan du se hur PKI-modernisering och CLM fungerar tillsammans och hur en kombinerad PKI- och CLM-färdplan tar hänsyn till just denna typ av internt, icke-offentligt certifikat.

LDAPS i moln-, hybrid- och Multi-CA PKI-miljöer

Domänkontrollanter som finns i Azure, AWS eller en hybrid Active Directory-plattform behöver fortfarande ett certifikat utfärdat av en certifikatutfärdare som varje anslutande klient litar på, vilket blir svårare när domänkontrollanter sprids över regioner och nätverksgränser. Hierarkier med flera certifikatutfärdare, där regionala utfärdande certifikatutfärdare publicerar sin egen serverautentiseringsmall, kräver att varje mall och varje utfärdande certifikatutfärdare kedjas tillbaka till samma betrodda rot, annars kommer klienter i en region att misslyckas med LDAPS-validering mot en domänkontrollant i en annan.

För organisationer som kör domänkontrollanter i flera regioner eller molnleverantörer, eliminerar centralisering av certifikatutfärdande via en PKI-as-a-Service- modell behovet av att replikera mallkonfiguration och CA-förtroende manuellt på varje plats, och ger varje utfärdande CA i en hierarki med flera CA-konton en konsekvent policy att tillämpa.

Mätning av framgång och vad som ska granskas regelbundet

En lyckad LDAPS-utrullning handlar inte bara om att "den anslöt en gång". Granska dessa regelbundet, inte bara under den första installationen:

• Certifikatets utgångsdatum på varje domänkontrollant och AD LDS-instansens LDAPS-bindning, med aviseringar långt före utgångsdatum
• Schannel- och CAPI2-händelseloggar för TLS- eller certifikatvalideringsfel, inte bara rena anslutningsfel
• CRL- och OCSP-åtkomlighet från alla domänkontrollanter, inklusive via alla proxyserverar i sökvägen.
• Vilka klienter eller applikationer använder fortfarande okrypterad enkel bindning på port 389 efter att LDAPS är tillgängligt
• Huruvida bindning och signering av LDAP-kanaler är konfigurerad som avsett, och vilka äldre klienter som skulle sluta fungera om tillämpningen skärptes.

En kryptografisk tillgångsinventering som CBOM Secure utvidgar samma disciplin bortom LDAPS-certifikat till varje nyckel, certifikat och algoritm i miljön, så att ingenting upptäcks för första gången under ett avbrott.

På längre sikt, behandla certifikatmallen för serverautentisering på samma sätt som du skulle behandla vilken certifikatprofil som helst som står inför en eventuell algoritmövergång. NIST slutförde sina tre första post-kvantkryptografistandarder, FIPS 203, FIPS 204 och FIPS 205, den 13 augusti 2024. Interna PKI-mallar som används för infrastruktur som domänkontrollanter är precis den typ av långlivade, lättglömda certifikatprofiler som behöver en kryptoagilitetsplan innan övergången når interna system. Encryption Consultings PQC Center of Excellence och en PQC-beredskapsbedömning är rätt plats att bygga den kryptoagilitetsplanen.

Krypteringskonsulternas synsätt

De flesta LDAPS-avbrott vi ser orsakas inte av ett missförstått koncept. De orsakas av ett certifikat som utfärdades en gång, fungerade och aldrig tittades på igen förrän det löpte ut eller en CAPI2-logg började fyllas med återkallningsfel. Åtgärden är inte en bättre engångsgenomgång, stegen ovan håller bra. Det handlar om att se till att certifikatet är synligt i det system som redan spårar certifikatets utgång för resten av din PKI, istället för att bara finnas kvar i minnet hos den som konfigurerade det. Om du kör mer än en handfull domänkontrollanter betyder det ett livscykelverktyg, inte ett kalkylblad som någon glömmer att öppna.

Slutsats

Genom att följa stegen ovan aktiveras LDAPS och skyddas korrekt inloggningsuppgifter som används i din PKI-miljö, tillsammans med alla andra applikationer som kan dra nytta av krypterad LDAP. Behandla certifikatet du just utfärdat som en hanterad tillgång från dag ett: spåra dess utgångsdatum, var uppmärksam på Schannel- och CAPI2-fel och ha återställningsplanen till hands istället för att improvisera en under ett avbrott.

Om du behöver hjälp med din PKI-miljö är du välkommen att mejla oss på [email protected].

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste lärdomen av att aktivera LDAPS med Microsoft PKI?

LDAPS ersätter okrypterade enkla LDAP-bindningar med en TLS-skyddad anslutning, med hjälp av ett serverautentiseringscertifikat som utfärdats från din Microsoft PKI och är bundet till varje domänkontrollant eller AD LDS-instans. När certifikatet väl är bundet behöver det samma kontinuerliga hantering som alla andra certifikat i din miljö.

Varför är detta viktigt för PKI-team på stora företag?

Okrypterade enkla LDAP-bindningar skickar domänuppgifter i klartext, och katalogtrafik berör nästan alla identitetsberoende applikationer i ett företag. PKI-team som hoppar över LDAPS lämnar en bred, välkänd exponering för uppgifter öppen över nätverket, en som en enkel paketinsamling kan utnyttja.

Vilka risker ökar om detta ämne hanteras manuellt?

Manuell hantering innebär att LDAPS-certifikatets utgångsdatum inte spåras någonstans förutom i institutionellt minne, mallar flyttas mellan domänkontrollanter, privata nycklar markeras inte konsekvent som exporterbara för säkerhetskopiering och ingen tittar på Schannel- eller CAPI2-loggar förrän ett avbrott tvingar fram problemet.

Vilka lag borde ta över den här förändringen?

PKI-administratörer äger certifikatmallen och utfärdandet. Plattforms- eller identitetsteam hanterar domänkontrollantens bindning och den dagliga driften. Säkerhetsarkitekter beslutar om kanalbindning och LDAP-signeringstillämpning. Efterlevnad och CISO:er spårar det som en del av det bredare certifikatriskprogrammet.

Hur kopplas detta till hantering av certifikatlivscykeln?

LDAPS-certifikatet är ytterligare en tillgång som behöver upptäckas, spåras förfallodatum och automatisk förnyelse. Verktyg för hantering av certifikatlivscykeln, som CertSecure Manager, tillämpar samma automatisering på domänkontrollantcertifikat som de tillämpar på publika TLS-certifikat, vilket sluter det tomrum som manuell engångsutfärdande lämnar öppet.

Hur bör organisationer mäta framgång?

Framgången ser ut att vara noll oplanerade LDAPS-avbrott, varje domänkontrollant som har ett giltigt certifikat med korrekt serverautentiserings-EKU långt före utgångsdatumet, ldp.exe-validering som genomförs utan Schannel- eller CAPI2-fel, och kanalbindning eller LDAP-signering som tillämpas utan att äldre klienter skadas.

Vad bör granskas eller övervakas regelbundet?

Utgångsdatum för granskningscertifikat för varje LDAPS-bindning, Schannel-händelser i intervallet 36870 till 36888, CRL- och OCSP-nåbarhet från varje domänkontrollant, vilka klienter som fortfarande använder okrypterad port 389 och om tillämpningen av kanalbindningar matchar din dokumenterade policy.

Hur påverkar detta ämne moln-, hybrid- eller multi-CA PKI?

Domänkontrollanter i moln- eller hybriddistributioner behöver fortfarande ett certifikat från en certifikatutfärdare som varje klient litar på, vilket är svårare att garantera över regioner och nätverksgränser. Hierarkier med flera certifikatutfärdare kräver att varje regional utfärdande certifikatutfärdares mall är kopplad till samma betrodda rot, annars kommer LDAPS-validering att misslyckas för klienter i en annan region än domänkontrollanten.

Vilka förutsättningar krävs innan implementering?

Du behöver en hälsosam PKI-hierarki utan fel i PKIView.msc, en utfärdande certifikatutfärdare som är nåbar från varje målserver, företagsadministratörsrättigheter, en certifikatmall som innehåller Server Authentication EKU och öppen nätverksåtkomst till port 636 (eller 50001 för AD LDS).

Vilka vanliga fel bör administratörer vara uppmärksamma på?

Håll utkik efter Schannel-händelser 36870 och 36872 från ett felaktigt certifikat, en nyckel-ACL, en kedja, ett SAN eller ett utgångsproblem; ldp.exe-anslutningsfel från en blockerad port eller ett saknat certifikat; ett certifikat som saknar Server Authentication EKU; en trasig förtroendekedja på klienten; och CRL- eller OCSP-hämtningsfel under TLS-handskakningen.