Jouw ultieme gids voor het begrijpen van CEP en CES

Als het je lukt om een Windows Server Publieke Sleutel Infrastructuur (PKI) In uw omgeving is certificaatregistratie een van de meest operationeel kritieke en vaakst problematische processen in uw infrastructuur. Wanneer apparaten zich buiten uw domeinnetwerk bevinden, werkt traditionele certificaatregistratie via Active Directory simpelweg niet. Dat is precies het probleem dat Webservice voor het certificaatinschrijvingsbeleid (CEP) en Certificaatinschrijvingswebservice (CES) waren ontworpen om op te lossen.

Deze twee Active Directory Certificate Services (AD CS)-rolservices werken samen om veilige, geautomatiseerde certificaatinschrijving mogelijk te maken voor elk apparaat, ongeacht of het is aangesloten op een domein, op afstand is verbonden, een cloud-hybride verbinding heeft of zich volledig buiten uw interne netwerk bevindt. Laten we elk onderdeel eens nader bekijken en begrijpen hoe het automatische inschrijvingsproces werkt met behulp van CEP en CES.

Wat is de Certificate Enrollment Policy Web Service (CEP)?

De Certificate Enrollment Policy Web Service (CEP) is de AD CS-rolservice die verantwoordelijk is voor het leveren van het certificaatinschrijvingsbeleid aan clients via een beveiligde webinterface. Het fungeert als de distributiepunt voor beleid van uw PKI-omgeving.

In een typische domeinconfiguratie ontvangt een Windows-computer die aan het domein is toegevoegd automatisch certificaatgerelateerde informatie van Active Directory, zonder handmatige tussenkomst. De computer "vraagt" in feite aan Active Directory welke certificaten hij mag aanvragen, welke certificaatsjablonen beschikbaar zijn en welke certificaten hij mag aanvragen. Certificeringsinstanties (CA's) Het systeem moet dit certificaat gebruiken. Op basis van deze informatie kan de machine vervolgens automatisch het certificaat aanvragen en installeren. Dit alles gebeurt op de achtergrond, waardoor het proces voor de gebruiker onzichtbaar is.

Deze traditionele aanpak werkt niet meer in moderne omgevingen waar systemen niet rechtstreeks met Active Directory kunnen communiceren. Bijvoorbeeld:

• Externe werknemers verbinding maken via internet zonder VPN
• Apparaten die niet aan een domein zijn gekoppeld die geen AD-connectiviteit hebben
• DMZ-servers zijn geïsoleerd van het interne domein
• Cloud-werklasten in Azure, AWS, hybride omgevingen of zelfs systemen van partners/leveranciers
• Apparaten van partners of leveranciers die organisatiecertificaten nodig hebben

Omdat ze geen toegang hebben tot Active Directory, kunnen ze geen certificaatsjablonen of beschikbare CA's vinden, wat het normale automatische inschrijvingsproces verstoort. Dit is precies waar oplossingen zoals CEP en CES van belang zijn, omdat ze een veilige, webgebaseerde manier bieden voor deze externe of geïsoleerde systemen om toch certificaten aan te vragen en te ontvangen.

CEP lost dit probleem op door het certificaatinschrijvingsbeleid beschikbaar te maken via een beveiligde interface. HTTPS-webservice In plaats van directe toegang tot Active Directory te vereisen, kan een geautoriseerde client, zelfs als deze zich buiten het interne netwerk bevindt of niet is aangesloten op het domein, via het web verbinding maken met CEP en opvragen welke certificaten deze mag aanvragen, welke sjablonen beschikbaar zijn en welke CA deze moet gebruiken. Simpel gezegd fungeert CEP als een veilige online vervanging voor de beleidsopzoekfunctie van Active Directory, waardoor externe of geïsoleerde systemen de benodigde informatie over certificaatinschrijving kunnen verkrijgen.

Welke informatie levert CEP?

Wanneer een klant verbinding maakt met CEP, stuurt CEP alle regels en opties voor certificaatinschrijving terug die van toepassing zijn op die specifieke klant. Dit omvat:

• Alles certificaatsjablonen dat de klant toestemming heeft om te gebruiken
• Sjabloonspecifiek instellingen of beperkingen, zoals belangrijke gebruiks- of onderwerpvereisten
• Het doel Certificeringsinstantie dat de klant verzoeken moet richten aan
• Configuratie van het inschrijvingsbeleid, inclusief verlengingsdrempels en geldigheidsperioden
• Verificatievereisten De klant moet aan de volgende voorwaarden voldoen bij het indienen van een verzoek.
• Beleidsmetadata, inclusief de unieke identificatiecode voor het inschrijvingsbeleid

Let op: CEP biedt alleen informatie over het beleid voor certificaatregistratie; het vertelt de klant wat hij mag aanvragen en onder welke regels. Het geeft zelf geen certificaten uit, verwerkt geen registratieverzoeken, communiceert niet met de certificeringsinstantie om een ​​verzoek in te dienen en slaat geen certificaatgegevens op. Simpel gezegd is CEP slechts een beleidsrichtlijn; het informeert de klant, maar voert de daadwerkelijke certificaatregistratie niet uit.

Wat is de Certificate Enrollment Web Service (CES)?

Het Certificaatinschrijvingswebservice (CES) is de AD C.S. Deze servicerol verzorgt de daadwerkelijke registratie en verlenging van certificaten. Het gaat verder waar CEP ophoudt en fungeert als een veilige, geauthenticeerde tussenpersoon tussen de client en de certificeringsinstantie.

Zelfs nadat de klant van CEP heeft vernomen welk certificaat hij mag aanvragen, moet hij dat certificaat nog steeds daadwerkelijk versturen. te vragen Ergens waar het certificaat kan worden uitgegeven. In een normale interne domeinconfiguratie gebeurt dit door het verzoek rechtstreeks naar de certificeringsinstantie te sturen via DCOM/RPC, wat alleen werkt als de client een directe netwerkverbinding met de CA heeft. Dat vormt een probleem voor externe gebruikers, internetapparaten of geïsoleerde systemen, omdat zij de CA meestal niet rechtstreeks kunnen bereiken.

CES lost dit op door als een beveiligde tussenlaag te fungeren: de client stuurt het certificaatverzoek via HTTPS naar CES, waarna CES het doorstuurt naar de interne CA van de client. Dit betekent dat de client zich nog steeds kan aanmelden voor certificaten zonder ooit directe toegang tot de CA zelf nodig te hebben.

Rol van CES

• Accepteert aanvragen voor certificaatinschrijving en -vernieuwing van klanten van meer dan HTTPS
• Authenticeert de client voordat we een verzoek verwerken
• Stuurt geauthenticeerde verzoeken door. aan de interne certificeringsinstantie
• Retourneert CA-reacties – afgegeven certificaat, status in behandeling of afwijzing – terug naar de klant
• Handvaten certificaatvernieuwing, inclusief sleutelgebaseerde verlenging voor geautomatiseerde scenario's
• Handhaaft de volledige inschrijvingstransactie van indiening tot levering van het antwoord

Dit ontwerp is belangrijk omdat het de interne certificeringsinstantie (CA) beschermt tegen directe blootstelling aan externe systemen. De CA hoeft geen openbaar IP-adres te hebben of bereikbaar te zijn vanaf het internet, wat het beveiligingsrisico aanzienlijk verlaagt. In plaats daarvan bevindt CES zich vóór de CA en fungeert als een beveiligde poortwachter. Het controleert eerst de authenticatie en autorisatie, zodat alleen geldige en goedgekeurde verzoeken aan de CA worden doorgegeven.

Op deze manier fungeert CES als een gecontroleerd toegangspunt voor certificaatinschrijving, terwijl de CA veilig achter CES verborgen blijft. Het verbetert ook de verantwoording, omdat zowel CES als de CA de activiteiten afzonderlijk kunnen registreren en controleren, waardoor er beter inzicht is in wie een aanvraag heeft ingediend en hoe deze is verwerkt.

Definitieve vergelijking tussen CEP en CES

CEP vertelt de klant wat hij moet aanvragen. CES helpt de klant om het daadwerkelijk aan te vragen.

Laten we de overeenkomsten en verschillen tussen CEP en CES eens nader bekijken.

CEP (Webservice voor het certificaatinschrijvingsbeleid)	CES (Webservice voor certificaatinschrijving)
Biedt klanten informatie over het inschrijvingsbeleid voor certificaten.	Behandelt aanvragen voor certificaatinschrijving en -vernieuwing.
Geeft de klant aan welke certificaten hij kan aanvragen.	Hiermee kan de klant het verzoek daadwerkelijk indienen.
Communiceert NIET met de certificeringsinstantie.	Communiceert met de certificeringsinstantie.
Geeft GEEN certificaten uit	Geeft GEEN certificaten uit (proxy's voor CA)
Geeft sjablonen, instellingen en beleidsdetails terug.	Verwerkt en stuurt certificaataanvragen door.
Klantgerichte dienstverlening	Klantgerichte dienstverlening
IIS is vereist.	IIS is vereist.
Vereist authenticatie	Vereist authenticatie
Ondersteunt Kerberos en authenticatie met gebruikersnaam en wachtwoord.	Ondersteunt Kerberos-, gebruikersnaam/wachtwoord- en certificaatauthenticatie.
Ondersteunt GEEN authenticatie op basis van certificaten.	Ondersteunt certificaatverificatie (voornamelijk voor verlenging).
Wordt gebruikt om beleid op afstand op te halen.	Wordt gebruikt om inschrijvingen op afstand uit te voeren.
Maakt gebruik van HTTPS (poort 443)	Maakt gebruik van HTTPS (poort 443)

Stapsgewijze uitleg over hoe automatische certificaatinschrijving werkt

Hieronder volgt de complete workflow voor automatische certificaatinschrijving met behulp van CEP en CES in een Active Directory-omgeving voor bedrijven.

Stap 1 - Cliënt neemt initiatief: Neemt contact op met CEP voor het inschrijvingsbeleid.

De workflow begint wanneer een client, zoals een Windows-werkstation, server of extern apparaat, vaststelt dat deze een certificaat moet aanvragen of een verlopend certificaat moet vernieuwen. Deze trigger kan afkomstig zijn van:

• Automatische inschrijving voor groepsverzekering (geplande certificaatcontrole)
• Handmatige inschrijving geïnitieerd door een gebruiker of beheerder
• Automatische verlenging geactiveerd doordat het certificaat de vervaldatum nadert
• Eerste inschrijving op een nieuw apparaat dat wordt geconfigureerd

De klant neemt contact op met de CEP-eindpunt via HTTPS om het inschrijvingsbeleid op te vragen. Op dit moment is er nog geen certificaatverzoek ingediend. De klant vraagt ​​simpelweg: Wat mag ik aanvragen en welke regels gelden er?

Deze stap is cruciaal voor externe apparaten die niet aan een domein zijn gekoppeld, omdat ze geen andere manier hebben om beschikbare certificaatsjablonen en CA-informatie te achterhalen.

Stap 2 - CEP reageert: Retourneert de toepasselijke beleidsdetails

Wanneer een klant contact opneemt met CEP, analyseert het bedrijf wie de klant is en stuurt het het exacte certificaatinschrijvingsbeleid terug dat op die klant van toepassing is. Dit antwoord bevat:

• Volledige lijst met certificaatsjablonen de klant is gemachtigd om te gebruiken
• Sjabloonspecifieke instellingen, inclusief vereisten voor sleutelgrootte, geldigheidsperiode, verlengingsdrempel, configuratie van onderwerpnamen en vlaggen voor sleutelgebruik.
• Doelcertificeringsinstantie informatie — de CA waar de cliënt verzoeken moet indienen
• Configuratie van het inschrijvingsbeleid — gedrag bij automatische inschrijving, instellingen voor verlenging
• Beleids-ID — de unieke identificatiecode die het beleid koppelt aan de bron ervan

Simpel gezegd fungeert dit antwoord als een complete handleiding die de klant gebruikt om een ​​geldig en conform certificaatverzoek op te stellen.

Stap 3 - Het certificaatverzoek samenstellen

Aan de hand van het beleidsantwoord van CEP construeert de client het certificaatverzoek. Dit omvat:

• Een cryptografisch sleutelpaar genereren — publieke en private sleutel met behulp van het algoritme en de sleutelgrootte die in de sjabloon zijn gespecificeerd (RSA 2048, RSA 4096 of ECC)
• Bouwen aan de Certificaatondertekeningsaanvraag (CSR) in PKCS#10-formaat
• Het certificaatsjabloon selecteren die aansluit bij de behoeften van de klant
• Het onderwerpveld invullen — meestal de machinenaam, de UPN van de gebruiker of een aangepast onderwerp op basis van de sjabloonconfiguratie
• Het toevoegen van alternatieve onderwerpnamen (SAN's) — DNS-namen, IP-adressen of UPN's, indien nodig.
• Sjabloongebaseerde extensies toepassen — Sleutelgebruik, Verbeterd sleutelgebruik, CDP, AIA

De klant gebruikt het beleidsantwoord van CEP om ervoor te zorgen dat het verzoek perfect aansluit op wat de CA accepteert.

Stap 4 - Verzoek indienen bij CES

Zodra het certificaatverzoek is voorbereid, stuurt de client het via HTTPS naar het CES-eindpunt. Dit verzoek bevindt zich in PKCS#10-formaat Dit omvat de vereiste authenticatiemethode, zoals een Kerberos-ticket, gebruikersnaam/wachtwoord of een clientcertificaat, afhankelijk van hoe CES is geconfigureerd. Op dit punt neemt CES de rol van actieve verwerkingslaag over. De client heeft zijn deel gedaan en wacht nu terwijl CES de authenticatie afhandelt, het verzoek doorstuurt naar de CA en het inschrijvingsproces voltooit.

Stap 5 - Authenticatie van de client en doorsturen naar de CA

Dit is de meest beveiligingskritische stap in de gehele workflow. CES voert twee bewerkingen achter elkaar uit:

authenticatie: CES valideert de identiteit van de client met behulp van de geconfigureerde authenticatiemethode. Voor Kerberos valideert het het serviceticket. Voor gebruikersnaam/wachtwoord valideert het de inloggegevens. Active DirectoryBij certificaatgebaseerde verlenging wordt het bestaande certificaat gevalideerd. Geen enkele aanvraag wordt verwerkt totdat de authenticatie is geslaagd.

Doorsturen: Zodra de authenticatie is geslaagd, koppelt CES de geauthenticeerde identiteit aan de juiste CA en stuurt het certificaatverzoek door. CES gebruikt zijn backend-serviceaccount en de CA-communicatieconfiguratie om het verzoek veilig door te sturen naar de interne CA, waarmee de client geen directe verbinding heeft.

Stap 6 - Verwerkt het certificaatverzoek

Wanneer CES het certificaatverzoek doorstuurt, evalueert de certificeringsinstantie (CA) dit zelf aan de hand van de geconfigureerde regels en beleidsrichtlijnen, zoals:

• Machtigingen voor certificaatsjablonen — Is deze identiteit gemachtigd om zich voor dit sjabloon aan te melden?
• Uitgiftevereisten — Voldoet het verzoek aan alle vereiste kenmerken?
• CA-beleid — Zijn er beperkingen op CA-niveau van toepassing?
• Instellingen voor goedkeuring door de manager — Moet deze sjabloon handmatig worden goedgekeurd?

Op basis van deze controles neemt de CA een beslissing: problemen het certificaat als alles in orde is, in afwachting het verzoek indien handmatige goedkeuring nodig is, of ontkent Dit geldt als de aanvrager niet bevoegd is of als het verzoek niet aan de vereiste criteria voldoet.

Stap 7 - Levert CA-antwoord aan klant

Nadat de certificeringsinstantie een beslissing heeft genomen, stuurt CES dat resultaat via HTTPS terug naar de klant. De resultaten kunnen er als volgt uitzien:

• Als het verzoek is uitgegevenCES stuurt het ingevulde en ondertekende certificaat terug, doorgaans in PKCS#7-formaatzodat de klant het kan installeren en gebruiken.
• Als het verzoek is in afwachting vanCES stuurt een Verzoek-ID met een status 'in behandeling', waardoor de klant later nogmaals kan controleren voor het definitieve resultaat.
• Als het verzoek is ontkendCES retourneert de relevante gegevens foutcode en reden voor afwijzingzodat de klant of beheerder kan begrijpen waarom het certificaat niet is uitgegeven.

CES ontvangt de beslissing van de CA en stuurt deze via HTTPS terug naar de oorspronkelijke client:

• Uitgegeven: CES retourneert het volledig ondertekende certificaat in PKCS#7-formaat.
• In afwachting van: CES retourneert een RequestID en een status 'in behandeling', zodat de client kan controleren of de aanvraag is voltooid.
• Geweigerd: CES geeft de foutcode en de reden voor de afwijzing terug.

Stap 8 - De klant ontvangt en installeert het certificaat.

Zodra het certificaatverzoek is verwerkt, ontvangt de client het resultaat. Als het verzoek is goedgekeurd, wordt het certificaat automatisch geïnstalleerd in het juiste Windows-certificaatarchief. Lokale machine\Persoonlijk voor computercertificaten en Huidige gebruiker\Persoonlijk Voor gebruikerscertificaten is het systeem direct gebruiksklaar, zonder handmatige stappen. Als het verzoek nog in behandeling is (bijvoorbeeld in afwachting van goedkeuring), stopt het systeem niet; het automatische inschrijvingsproces blijft CES met tussenpozen controleren totdat een definitieve beslissing is genomen. Als het verzoek wordt afgewezen, wordt de fout vastgelegd in de systeemlogboeken, zodat beheerders kunnen nagaan wat er mis is gegaan en indien nodig actie kunnen ondernemen.

Een analyse van de Kerberos-authenticatie in CEP en CES

Kerberos is een veilig, op tickets gebaseerd authenticatiesysteem dat wordt gebruikt in Active Directory en waarmee gebruikers of machines hun identiteit kunnen bewijzen zonder wachtwoorden via het netwerk te verzenden. Het werkt via een vertrouwde service genaamd het Key Distribution Center (KDC), dat draait op domeincontrollers.

Hieronder volgen de stappen die nodig zijn voor Kerberos-authenticatie:

Wanneer een gebruiker inlogt op een Windows-computer die lid is van een domein, start de Kerberos-authenticatie automatisch op de achtergrond:

• De klant stuurt een AS-REQ (Authenticatieserviceverzoek) aan de Sleuteldistributiecentrum (KDC), dat draait op de domeincontroller.
• De KDC verifieert de identiteit van de client aan de hand van de opgeslagen referentiehash (voor een gebruikers- of machineaccount) in Active Directory.
• Als de inloggegevens geldig zijn, geeft de KDC een Ticket Granting Ticket (TGT).
• Deze TGT is versleuteld met de geheime sleutel van de KDCwaardoor het niet vervalst of gemanipuleerd kan worden.
• De client slaat de TGT veilig op in het geheugen. LSASS (subsysteemservice van de lokale beveiligingsautoriteit)Het wordt nooit naar de schijf geschreven.

Wanneer de klant contact moet opnemen met CEP of CES (voor certificaatregistratie of het opvragen van polisgegevens):

• De klant stuurt een TGS-REQ (Ticket Granting Service Request) naar de KDC.
• Het omvat zijn TGT en verzoekt om toegang tot een specifieke dienst, geïdentificeerd door de Service Principal Name (SPN) van CEP of CES.
• De KDC zoekt deze SPN op in Active Directory en identificeert de bijbehorende SPN. serviceaccount CEP/CES uitvoeren (doorgaans een IIS-apppoolidentiteit).
• De KDC genereert een ServiceticketDit is versleuteld met de geheime sleutel van het serviceaccountDit betekent dat alleen die dienst het kan decoderen.
• Het serviceticket wordt teruggestuurd naar de klant en tijdelijk in het geheugen opgeslagen.

Wanneer de klant daadwerkelijk verbinding maakt met CEP of CES:

• Het verzendt de Serviceticket als onderdeel van het HTTPS-verzoek met behulp van de HTTP Negotiate/Kerberos Authorization-header.
• IIS (dat CEP/CES host) ontvangt het verzoek en probeert het ticket te decoderen met behulp van de aanmeldingsgegevens voor de applicatiepoolserviceaccount.
• Na decodering onthult het ticket het volgende:
  1. Clientidentiteit (gebruikersnaam of machineaccount)
  2. Domeininformatie
  3. Groepslidmaatschappen
  4. Sessiesleutel voor veilige communicatie

• CEP/CES valideert vervolgens het ticket:
  1. Zorgt ervoor dat het ticket authentiek en onvervalst
  2. Controleert de tijdstempelHet moet binnen de toegestane grenzen vallen. Tolerantie voor klokafwijking van 5 minuten
  3. Controleert of het ticket nog geldig is (niet verlopen).

Kerberos-authenticatie is ontworpen om volledig transparant te zijn voor de eindgebruiker; er zijn geen prompts of handmatige invoer nodig, omdat de authenticatie automatisch op de achtergrond plaatsvindt met behulp van de ingelogde domeinidentiteit.

Het werkt standaard voor alle Windows-machines en -gebruikers die lid zijn van een domein, waarbij het machineaccount of gebruikersaccount in Active Directory fungeert als de authenticatie-identiteit. De door Kerberos uitgegeven tickets zijn tijdsgebonden, doorgaans ongeveer 10 uur geldig (configureerbaar via Groepsbeleid), wat een goede balans biedt tussen beveiliging en gebruiksgemak.

Kerberos is echter afhankelijk van strikte voorwaarden: de klokken van de client en de server moeten binnen een kort tijdsvenster (meestal 5 minuten) gesynchroniseerd zijn, en de client moet een netwerkverbinding met een domeincontroller hebben om tickets te verkrijgen en te vernieuwen.

Wanneer moet je Kerberos gebruiken?

Implementeer Kerberos-authenticatie voor CEP en CES wanneer:

• Alle inschrijvende klanten zijn Windows-machines die lid zijn van een domein
• U bent bezig met de implementatie Automatische inschrijving voor groepsverzekering voor computer- of gebruikerscertificaten
• Klanten hebben betrouwbare verbinding met een domeincontroller met lage latentie
• Het belangrijkste gebruiksscenario is automatische machinecertificaatregistratie
• Maximale veiligheidshouding zonder enige blootstelling aan referenties is vereist.
• U wilt volledig stil, geen interactie Beheer van de levenscyclus van certificaten
• Uw omgeving is een enkel bos of beschikt over goed functionerende Kerberos-trusts die meerdere forests omvatten.
• U voert een implementatie uit over een intern bedrijfsnetwerk of een afgedwongen split-tunnel VPN

Analyse van gebruikersnaam/wachtwoordverificatie in CEP/CES

Gebruikersnaam/wachtwoordverificatie in Postcode en CES wordt gebruikt wanneer de client niet op Kerberos kan vertrouwen, meestal omdat het niet aan het domein gekoppeld, maakt verbinding vanuit een extern netwerkof heeft geen directe verbinding met een domeincontroller.

Tip: Wanneer Microsoft-documentatie verwijst naar Gebruikersnaam/wachtwoord authenticatie Voor de Certificate Enrollment Policy Web Service (CEP) en de Certificate Enrollment Web Service (CES) wordt specifiek verwezen naar HTTP-basisverificatie, een gestandaardiseerd authenticatieschema gedefinieerd in RFC 7617, werkend via een HTTPS-transportlaag.

In dit model geeft de klant handmatig een gebruikersnaam en wachtwoord op, en deze gegevens worden via een webserver naar de CEP- of CES-webservice verzonden. HTTPS voor validatie. De service controleert die inloggegevens vervolgens aan de hand van de gegevens. Active Directory om de identiteit van de gebruiker te bevestigen voordat toegang tot het inschrijvingsbeleid of de certificaatregistratiefuncties wordt verleend.

Hieronder volgt een stapsgewijze uitleg van hoe authenticatie met gebruikersnaam en wachtwoord werkt.

• De klant neemt de gebruikersnaam en het wachtwoord in ontvangst en Base64-coderingen Voer ze in in het formaat gebruikersnaam: wachtwoord
• De gecodeerde inloggegevens worden geplaatst in de HTTP Basic Authorization-header
• Het volledige verzoek wordt verzonden via HTTPS; TLS is de enige beveiliging voor de inloggegevens. Onderweg. Belangrijk punt: Base64 is codering, geen encryptie. Zonder HTTPS zijn de inloggegevens volledig blootgesteld.
• CEP extraheert en decodeert de autorisatieheader. Het stuurt de onbewerkte gebruikersnaam en het wachtwoord door naar Active Directory voor validatie via een LDAP-verbinding.
• AD-controles:
  1. Is het account geldig en actief?
  2. Is het wachtwoord correct?
  3. Is het account ontgrendeld en niet verlopen?
• Als de validatie van de gebruikersnaam en het wachtwoord mislukt, wijst CEP het verzoek onmiddellijk af en retourneert een foutmelding. HTTP 401 Niet geautoriseerd reactie, wat betekent dat de klant niet verder mag gaan.
• Als de authenticatie slaagt, accepteert CEP de identiteit, evalueert het welk certificaatinschrijvingsbeleid van toepassing is op die gebruiker of machine, en stuurt vervolgens de details van het inschrijvingsbeleid terug naar de client.
• Wanneer de client het certificaatverzoek (CSR) naar CES stuurt, moet deze zijn inloggegevens opnieuw verstrekken, omdat CES niet vertrouwt op of de eerdere authenticatie door CEP overneemt.
• CES voert zijn onafhankelijke validatie uit tegen Active Directory met behulp van hetzelfde authenticatieproces met gebruikersnaam en wachtwoord.
• Zodra de identiteit is bevestigd, gaat CES een stap verder en controleert of die gebruiker of machine beschikt over... Inschrijven toestemming voor het aangevraagde certificaatsjabloon en of het verzoek zelf voldoet aan de sjabloonvereisten, zoals het juiste onderwerpformaat of toegestane cryptografie.
• Als een van deze controles mislukt, wijst CES het verzoek af. Als ze slagen, accepteert CES het verzoek en stuurt het namens de klant door naar de certificeringsinstantie.

Deze methode is flexibeler voor externe gebruikers, internetgebaseerde systemen, partnerapparaten en machines die niet aan een domein zijn gekoppeldMaar het is ook minder veilig dan Kerberos, omdat het direct afhankelijk is van wachtwoorden. Hoewel de inloggegevens tijdens de overdracht worden beschermd door TLS, blijft de beveiliging afhankelijk van sterke wachtwoordpraktijken, veilige afhandeling van eindpunten en een zorgvuldige IIS-configuratie. Simpel gezegd is authenticatie met gebruikersnaam en wachtwoord het praktische alternatief voor CEP/CES wanneer Kerberos niet kan worden gebruikt, maar het vereist meer voorzichtigheid omdat het directe verwerking van inloggegevens introduceert in het certificaatinschrijvingsproces.

Wanneer moet je een gebruikersnaam/wachtwoord gebruiken?

Schakel gebruikersnaam-/wachtwoordverificatie in voor CEP en CES wanneer:

• Klanten die zich inschrijven zijn niet aan het domein gekoppeld — werkgroepmachines, apparaten van aannemers, IoT-eindpunten
• Jij hebt nodig bosoverschrijdend of organisatieoverschrijdend inschrijving zonder Kerberos-vertrouwen
• Klanten Kan geen betrouwbare verbinding maken met een domeincontroller. op het moment van inschrijving
• Je steunt inschrijving via internet voor apparaten op afstand en mobiele apparaten
• De implementatie is een PKIaaS of beheerde PKI scenario voor het bedienen van extern beheerde klanten
• Je moet ondersteuning bieden niet-Windows-platformen certificaatinschrijving vereist
• Kerberos-infrastructuur is niet beschikbaar of onpraktisch in de doelomgeving

Certificaatgebaseerde authenticatie: de derde optie voor verlenging

Authenticatie op basis van certificaten is de derde authenticatieoptie die beschikbaar is. CESen het wordt voornamelijk gebruikt voor certificaatvernieuwingNiet geschikt voor eerste registraties. Bij deze methode authenticeert de client zich niet met Kerberos of een gebruikersnaam en wachtwoord. In plaats daarvan bewijst de client zijn identiteit door zijn bestaand geldig certificaat Het certificaat wordt tijdens het verlengingsverzoek naar CES gestuurd. CES valideert het certificaat vervolgens door te controleren of het vertrouwd is, of het nog geldig is, of het is gekoppeld aan een vertrouwde CA en of het overeenkomt met de identiteit van degene die de verlenging probeert aan te vragen. Als het certificaat de validatie doorstaat, accepteert CES het als identiteitsbewijs en kan het verlengingsverzoek verder worden verwerkt.

Deze aanpak is nuttig omdat het verzenden van wachtwoorden wordt vermeden en niet afhankelijk is van Kerberos-connectiviteit tussen de client en een domeincontroller. Het is met name waardevol voor externe of niet-domein-gekoppelde systemen die al een certificaat hebben en dit alleen hoeven te vernieuwen. Deze methode is echter over het algemeen beperkt tot... vernieuwingsscenario's Omdat de klant in de eerste plaats al over een geldig certificaat moet beschikken om zich te kunnen authenticeren. Simpel gezegd, bij authenticatie op basis van certificaten fungeert het bestaande certificaat als identiteitsbewijs van de klant, waardoor het een veilige en efficiënte optie is voor het vernieuwen van certificaten via CES.

Let op: Automatische inschrijving met CEP en CES werkt probleemloos wanneer de PKI on-premises is geïmplementeerd en volledig is geïntegreerd met Active Directory. Echter, wanneer de PKI als beheerde service wordt geleverd en de certificeringsinstantie zich buiten het netwerk van de organisatie bevindt, rijst de vraag: Hoe kunnen apparaten zich veilig aanmelden voor certificaten bij een certificeringsinstantie (CA) waartoe ze geen directe toegang hebben?

Belangrijkste mogelijkheden van PKIaaS

• Naadloze AD-integratie: De Enrollment Gateway integreert met uw bestaande Active Directory-infrastructuur. Uw configuratie voor automatische inschrijving via Groepsbeleid verwijst naar het Gateway-eindpunt in plaats van naar een on-premises CES-URL. Machines die lid zijn van een domein blijven zich inschrijven met behulp van Kerberos-authenticatie; vanuit het perspectief van het eindpunt verandert er niets.
• Ondersteuning voor apparaten die geen deel uitmaken van een domein en apparaten op afstand: De Enrollment Gateway ondersteunt authenticatie met gebruikersnaam en wachtwoord voor apparaten die niet aan een domein zijn gekoppeld, externe eindpunten, cloudworkloads en elk apparaat dat geen Kerberos kan gebruiken. Dit biedt u één enkele Enrollment Gateway die uw gehele apparatenpark bedient, zowel apparaten binnen als buiten een domein.
• Nul blootstelling van de CA-infrastructuur: Omdat de Enrollment Gateway als tussenpersoon fungeert, Uw apparaten communiceren nooit rechtstreeks met de infrastructuur van Encryption Consulting CA. De CA blijft volledig beschermd achter de authenticatie- en autorisatielaag van de gateway. Dit is hetzelfde principe van nul blootstelling dat CES architectonisch veilig maakt, toegepast op een volledig beheerde PKIaaS-omgeving.
• Inzicht in de levenscyclus van certificaten: Elke inschrijvingstransactie via de Encryption Consulting Enrollment Gateway wordt geregistreerd, bijgehouden en doorgegeven aan de certificaatlevenscyclusbeheerlaag. U krijgt inzicht in elk uitgegeven certificaat, elke verwerkte verlenging en elke mislukte inschrijving, zonder dat u zelf de infrastructuur hoeft te beheren.
• Schaalbaarheid zonder capaciteitsplanning: Of u nu certificaten registreert voor 500 apparaten of 500,000 apparaten, de Enrollment Gateway schaalt mee met de vraag zonder dat uw team de registratie-infrastructuur hoeft te configureren, dimensioneren of beheren.
• Een auditspoor dat voldoet aan de regelgeving: Elke inschrijvingstransactie wordt volledig traceerbaar vastgelegd, inclusief de identiteit van de aanvrager, de authenticatiemethode, het gebruikte sjabloon, het CA-antwoord, een tijdstempel en het resultaat. Dit ondersteunt de nalevingsvereisten met betrekking tot PKI binnen verschillende frameworks, waaronder SOC 2, ISO 27001, FedRAMP, HIPAAen PCI DSS.

De zakelijke argumenten: zelf bouwen versus EC PKIaaS met Enrollment Gateway

Overweging	DIY CEP/CES On-Premises	Encryptieconsulting PKIaaS + inschrijvingsgateway
Interne PKI-expertise vereist	Hoog niveau, vereist diepgaande kennis van AD CS en PKI.	De expertise van Encryption Consulting is minimaal.
CA Infrastructuurbeheer	Beheerd door het interne team.	Volledig beheerd door Encryption Consulting.
HSM-management	Uw hardware, uw belangrijkste ceremonies	Beheerd door Encryption Consulting
Onderhoud van certificaatsjablonen	Handmatig en vaak over het hoofd gezien	Beheerd en periodiek gecontroleerd
Automatische inschrijving voor apparaten op afstand	Complexe CEP/CES-configuratie vereist	Geïntegreerd via Enrollment Gateway
Levenscycluszichtbaarheid van certificaten	Handmatige tracking of tools van derden zijn nodig.	Inbegrepen in het PKIaaS-platform
Nalevingsdocumentatie	Ontwikkeld en intern onderhouden.	Aangeboden en onderhouden door Encryption Consulting.
scaling	Vereist aanvullende investeringen in infrastructuur.	Elastisch en schaalt automatisch
Algoritme-migratie (bijv. van RSA naar PQC)	Handmatige updates van sjablonen en CA	Proactief beheerd
Eén aanspreekpunt voor verantwoording	Verdeeld over IT-teams	Gecentraliseerd, eigendom van Encryption Consulting.

Hoe kan Encryption Consulting u helpen?

Met diepgaande praktijkervaring in het ontwerpen van PKI-omgevingen voor grote bedrijven, HSM-beheer, automatisering van de certificaatlevenscyclus en compliance-frameworks, heeft Encryption Consulting PKI-omgevingen gebouwd en beheerd voor organisaties variërend van middelgrote ondernemingen tot grote, gereguleerde sectoren, waaronder de financiële sector, de gezondheidszorg en de overheid.

Hier komt Encryption Consulting in beeld. PKIaaS Het aanbod pakt de specifieke technische uitdaging aan. Dit is precies de lacune die de Encryptieconsulting PKIaaS-inschrijvingsgateway vult.

Het Encryptieconsulting PKIaaS-inschrijvingsgateway Dit is een speciaal ontwikkelde service voor het bemiddelen bij certificaatinschrijvingen. De service fungeert als geauthenticeerde tussenpersoon tussen uw geregistreerde apparaten en de door Encryption Consulting beheerde CA-infrastructuur. De service vervult de rol van bemiddelaar bij certificaatinschrijvingen: certificaatverzoeken van uw apparaten worden geaccepteerd, geverifieerd en namens u doorgestuurd naar de juiste CA.

Zie het als de vertaallaag tussen uw bestaande Active Directory- en Group Policy-automatische inschrijvingsinfrastructuur en de extern beheerde PKIaaS CA, zonder dat u uw bestaande inschrijvingsworkflows hoeft te vervangen of opnieuw te ontwerpen.

Voor uw apparaten en uw IT-team werkt de registratie precies hetzelfde als altijd. Apparaten die lid zijn van een domein worden automatisch ingeschreven via Groepsbeleid. Apparaten die geen deel uitmaken van een domein worden ingeschreven via hun eigen geconfigureerde methode. Certificaten verschijnen automatisch in de juiste certificaatarchieven. Vernieuwingen vinden stilzwijgend plaats vóór de vervaldatum.

Achter de schermen regelt de Enrollment Gateway alle complexiteit. — verzoeken doorsturen naar de juiste door Encryption Consulting beheerde uitgevende CA, authenticatie- en autorisatiebeleid afdwingen, resultaten terugsturen naar clients en telemetriegegevens terugkoppelen naar de Beheer van de levenscyclus van certificaten platform.

Conclusie

CEP en CES zijn essentiële onderdelen van elke moderne PKI voor bedrijven, geen optionele onderdelen. Elke organisatie heeft tegenwoordig apparaten die buiten de grenzen van het bedrijfsnetwerk opereren, en zonder CEP en CES kan automatische certificaatregistratie voor die systemen simpelweg niet functioneren.

In domeinomgevingen blijft Kerberos de gouden standaard voor authenticatie. Het biedt veilige, naadloze toegang zonder inloggegevens prijs te geven, ondersteunt wederzijdse authenticatie, machine-identiteiten en volledige automatische inschrijving op basis van groepsbeleid. Voor apparaten die lid zijn van een domein, is er geen praktische of beveiligingsgerelateerde reden om een ​​alternatief te gebruiken. Tegelijkertijd speelt authenticatie met gebruikersnaam en wachtwoord een cruciale en geldige rol in scenario's waar Kerberos niet kan worden gebruikt, zoals bij apparaten die geen deel uitmaken van een domein of toegang tussen verschillende forests. PKIaaS omgevingen, of inschrijvingen die via internet verlopen. De juiste aanpak is niet om het te vermijden, maar om het veilig te implementeren met sterke controles zoals speciale accounts met lage privileges, afgedwongen TLS, bescherming door een webapplicatiefirewall en adequate monitoring.

Hoewel het opzetten van een CA (Certificate Authority) eenvoudig kan zijn, vereist het beheren van PKI op grote schaal, inclusief lifecycle management, compliance, algoritme-overgangen en naadloze inschrijving op alle apparaattypen, voortdurende expertise die veel organisaties zich niet kunnen veroorloven. De PKIaaS- en Enrollment Gateway-oplossingen van Encryption Consulting bieden hiervoor een oplossing door PKI van enterprise-niveau te leveren met minimale operationele lasten. Dit zorgt ervoor dat certificaten automatisch worden vernieuwd, systemen altijd beschikbaar blijven en organisaties geen speciale PKI-specialisten nodig hebben om alles soepel te laten verlopen.