Basisprincipes van Microsoft Cloud PKI

Microsoft Cloud PKI is een Intune Suite-functie waarmee u als IT-professional uw PKI (Public Key Infrastructure) in de cloud kunt beheren. U kunt uw eigen certificeringsinstanties (CA's) en certificaten maken, configureren en beheren zonder dat u een on-premises infrastructuur hoeft te installeren en onderhouden. De Microsoft Cloud PKI-service kan worden geïntegreerd met Microsoft Entra ID en Microsoft Intune om identiteits- en apparaatbeheer te bieden voor uw cloudapparaten en apps.

In dit artikel worden de basisprincipes en concepten van PKI beschreven die u moet weten wanneer u Microsoft Cloud PKI configureert. We raden u aan alle informatie te controleren voordat u de Microsoft Cloud PKI-service configureert in uw Intune-tenant.

Typen certificeringsinstantie

Een certificeringsinstantie voert de volgende taken uit:

• Controleert de identiteit van een certificaataanvraag
• Certificaten uitgeven aan aanvragers
• Certificaatintrekking beheren

Microsoft Cloud PKI ondersteunt deze typen certificeringsinstanties:

• Basis-CA
• Verlenende CA

Basiscertificeringsinstantie

Een basiscertificeringsinstantie (CA) is de bovenste CA in een CA-hiërarchie. In een PKI fungeert de basis-CA als het vertrouwenspunt voor certificaten die zijn uitgegeven door CA's in de hiërarchie. Het certificaat wordt beschouwd als vertrouwd als het via de CA-hiërarchie kan worden getraceerd naar een basis-CA die wordt vertrouwd door een gebruiker, computer, netwerkapparaat of service.

Een basis-CA is uniek omdat het certificaat zelf is uitgegeven, wat betekent dat de naam van de verlener en de onderwerpnaam van het certificaat dezelfde DN-naam bevatten. De enige manier om te controleren of een basiscertificaat geldig is, is door het basis-CA-certificaat op te nemen in een vertrouwd basisarchief. Het vertrouwde basisarchief bevat het werkelijke basis-CA-certificaat om aan te geven dat het certificaat wordt vertrouwd.

De basis-CA kan certificaten uitgeven aan andere CA's of aan gebruikers, computers, netwerkapparaten of services op het netwerk. Wanneer de basis-CA een certificaat uitgeeft aan een andere entiteit, ondertekent het basis-CA-certificaat het certificaat met de persoonlijke sleutel. De ondertekening beschermt tegen inhoudswijziging en geeft aan dat de basis-CA het certificaat heeft uitgegeven.

Belangrijk

Microsoft Cloud PKI geeft alleen certificaten uit aan netwerkapparaten die zijn ingeschreven bij MDM.

Verlenende certificeringsinstantie

Opmerking

De termen tussenliggend, uitgevend en ondergeschikt zijn allemaal verwisselbare labels die worden gebruikt om te verwijzen naar dezelfde rol binnen een CA-structuur. Microsoft Cloud PKI gebruikt de term uitgifte om dit type CA te beschrijven.

Een verlenende CA is een CA die ondergeschikt is aan een andere CA en kan:

• Certificaten uitgeven aan andere CA's in de CA-hiërarchie.
• Geef leafcertificaten uit aan een eindentiteit, zoals een server, service, client of apparaat.

De verlenende CA kan op elk niveau in de CA-hiërarchie bestaan, behalve op basis-CA-niveau.

Chaining

Chaining is het proces waarbij wordt bepaald wat het beste vertrouwenspad is voor een bepaald certificaat dat moet worden geverifieerd en vertrouwd. Elk besturingssysteem of elke service voert dit rekenproces uit dat doorgaans de certificaatketen-engine wordt genoemd.

Het ketenbouwproces bestaat uit:

• Certificaatdetectie: het verlenende CA-certificaat van een eindentiteitsbladcertificaat opzoeken tot aan het vertrouwende basis-CA-certificaat.
• Certificaatvalidatie: hiermee maakt u alle mogelijke certificaatketens. Valideert elk certificaat in de keten met betrekking tot verschillende parameters, zoals naam, tijd, handtekening, intrekking en mogelijk andere gedefinieerde beperkingen.
• Retourneert de keten van de beste kwaliteit.

Wanneer een certificaat wordt gepresenteerd voor verificatie, doorloopt een certificaatketenengine het certificeringsarchief en selecteert de tussenliggende en basiscertificaatkandidaten. Er kan meer dan één tussenliggend certificaat nodig zijn om een volledige keten te vormen.

De engine voor de certificaatketen probeert certificaten te selecteren met behulp van de onderwerpsleutel-id (SKI) en de AKI (Authority Key Identifier). Een eindentiteitscertificaat dat is uitgegeven door een Microsoft-CA bevat de AKI, dus de certificaatketen-engine moet een tussenliggend certificaat met een overeenkomende SKI selecteren. Het proces wordt herhaald totdat een zelfondertekend certificaat is geïnventariseerd.

Ketenvalidatieproces

Opmerking

Ondersteuning voor de validatiemethoden voor certificaatketens verschilt per besturingssysteemplatform. In deze sectie worden de methoden beschreven die worden ondersteund op apparaten met Windows.

In Windows zijn er drie ketenvalidatieprocessen: exacte overeenkomst, sleutelovereenkomst en naamovereenkomst.

• Exacte overeenkomst: Als de AKI-extensie het onderwerp, het serienummer van de verlener en de KeyID van de verlener bevat, worden alleen bovenliggende certificaten gekozen die overeenkomen met hun onderwerp, serienummer en KeyID in het ketenvormingsproces.

• Sleutelovereenkomst: als de AKI-extensie alleen de KeyID bevat, worden alleen certificaten die een overeenkomende KeyID bevatten in de extensie Subject Key Identifier (SKI) gekozen als geldige verleners.

• Naamovereenkomst: naamkoppeling vindt plaats wanneer er geen informatie in de AKI bestaat of als de AKI-extensie zich niet in het certificaat bevindt. In dit geval moet de onderwerpnaam van het certificaat van de uitgever overeenkomen met het kenmerk van de uitgever van het huidige certificaat.

Voor certificaten die geen SKI- en AKI-velden bevatten, probeert de ketenengine naamkoppeling te gebruiken om een keten te maken. Wanneer u twee certificaten met dezelfde naam hebt, wordt de nieuwere geselecteerd.

Certificaatdetectie wordt gestart wanneer het directe bovenliggende element niet lokaal op de computer is. De client gebruikt dit proces om ontbrekende bovenliggende certificaten op te halen. De URL's die worden weergegeven in het veld toegang tot autoriteitsgegevens van het certificaat, worden geparseerd en gebruikt om bovenliggende CA-certificaten op te halen. Het proces is vergelijkbaar met het downloaden van CRL.

Nadat de keten is gemaakt, worden de volgende controles uitgevoerd op elk certificaat in de keten:

• Controleer of deze juist is opgemaakt en ondertekend. Voer een hashcontrole van het certificaat uit.
• Controleer de velden van en naar in het certificaat om ervoor te zorgen dat het niet is verlopen.
• Controleer of het certificaat is ingetrokken.
• Controleer of de keten wordt beëindigd in een certificaat dat zich in het vertrouwde basisarchief bevindt.

Het certificaat en de bijbehorende keten worden als geldig beschouwd nadat alle controles zijn voltooid en zijn teruggekomen.

Met een certificaatketen met een geordende lijst met certificaten kan de relying party controleren of een afzender betrouwbaar is. Het werkt beide manieren, van client naar server en server-naar-client.

In het volgende diagram ziet u de validatiestroom voor de naam die overeenkomt met de keten.

Een vertrouwensketen garanderen

Wanneer u certificaten gebruikt om verificatie op basis van certificaten uit te voeren, moet u ervoor zorgen dat beide relying party's de vertrouwensketen ca-certificaat (openbare sleutels) hebben. In dit geval zijn de relying party's het Intune beheerde apparaat en het verificatietoegangspunt, zoals Wi-Fi, VPN of webservice.

De basis-CA moet aanwezig zijn. Als het verlenende CA-certificaat niet aanwezig is, kan het worden aangevraagd door de relying party met behulp van de systeemeigen engine voor de certificaatketen voor het beoogde besturingssysteemplatform. De relying party kan het verlenende CA-certificaat aanvragen met behulp van de eigenschap authority information access van het leaf-certificaat.

Op certificaat gebaseerde verificatie

Deze sectie biedt een basiskennis van de verschillende certificaten die worden gebruikt wanneer een client of apparaat verificatie op basis van certificaten uitvoert.

In de volgende stappen wordt de handshake beschreven die plaatsvindt tussen een client en een Relying Party-service tijdens verificatie op basis van certificaten.

1. De client geeft een vorm van hello-pakket uit aan de relying party.
2. De relying party reageert en geeft aan dat deze via beveiligde TLS/SSL wil communiceren. De client en relying party voeren de SSL-handshake uit en er wordt een beveiligd kanaal tot stand gebracht.
3. De relying party vraagt een certificaat aan dat moet worden gebruikt voor clientverificatie.
4. De client presenteert het clientverificatiecertificaat aan de relying party om te verifiëren.

In een omgeving zonder Microsoft Cloud PKI is een privé-CA verantwoordelijk voor het uitgeven van zowel het TLS/SSL-certificaat dat wordt gebruikt door de relying party als het verificatiecertificaat van de apparaatclient. Microsoft Cloud PKI kan worden gebruikt om het verificatiecertificaat voor de apparaatclient uit te geven, waardoor de privé-CA voor deze specifieke taak effectief wordt vervangen.