Aan de slag gaan met Key Vault-certificaten
Deze richtlijn helpt u aan de slag te gaan met certificaatbeheer in Key Vault.
Lijst met scenario's die hier worden behandeld:
- Uw eerste Key Vault-certificaat maken
- Een certificaat maken met een certificeringsinstantie die is gekoppeld aan Key Vault
- Een certificaat maken met een certificeringsinstantie die niet is gekoppeld aan Key Vault
- Certificaat importeren
Certificaten zijn complexe objecten
Certificaten bestaan uit drie aan elkaar gerelateerde resources die zijn gekoppeld als een Key Vault-certificaat; certificaatmetagegevens, een sleutel en een geheim.
Uw eerste Key Vault-certificaat maken
Voordat een certificaat kan worden gemaakt in een Key Vault (KV), moeten vereiste stappen 1 en 2 worden uitgevoerd en moet er een sleutelkluis bestaan voor deze gebruiker/organisatie.
Stap 1: CA-providers (Certificeringsinstantie)
- Onboarding als IT-beheerder, PKI-beheerder of iedereen die accounts met CA's beheert, is voor een bepaald bedrijf (bijvoorbeeld Contoso) een vereiste voor het gebruik van Key Vault-certificaten.
De volgende CA's zijn de huidige partnerproviders met Key Vault. U vindt hier meer informatie- DigiCert - Key Vault biedt OV TLS/SSL-certificaten met DigiCert.
- GlobalSign - Key Vault biedt OV TLS/SSL-certificaten met GlobalSign.
Stap 2: Een accountbeheerder voor een CA-provider maakt referenties die door Key Vault moeten worden gebruikt om TLS/SSL-certificaten in te schrijven, te vernieuwen en te gebruiken via Key Vault.
Stap 3a: Een Contoso-beheerder, samen met een Contoso-werknemer (Key Vault-gebruiker) die eigenaar is van certificaten, afhankelijk van de CA, kan een certificaat ophalen van de beheerder of rechtstreeks vanuit het account met de CA.
- Begin met een referentiebewerking aan een sleutelkluis door een certificaatverlenerresource in te stellen. Een certificaatverlener is een entiteit die in Azure Key Vault (KV) wordt weergegeven als een CertificateIssuer-resource. Het wordt gebruikt om informatie te verstrekken over de bron van een KV-certificaat; naam van verlener, provider, referenties en andere beheergegevens.
Bijvoorbeeld: MyDigiCertIssuer
- Provider
- Referenties: CA-accountreferenties. Elke CA heeft zijn eigen specifieke gegevens.
Zie het gerelateerde bericht op de Key Vault-blog voor meer informatie over het maken van accounts met CA-providers.
Stap 3b: certificaatcontactpersonen instellen voor meldingen. Dit is de contactpersoon voor de Key Vault-gebruiker. Deze stap wordt niet afgedwongen in Key Vault.
Opmerking: dit proces, tot en met stap 3b, is een eenmalige bewerking.
Een certificaat maken met een CA die is gekoppeld aan Key Vault
Stap 4: De volgende beschrijvingen komen overeen met de groene genummerde stappen in het voorgaande diagram.
(1) - In het bovenstaande diagram maakt uw toepassing een certificaat dat intern begint met het maken van een sleutel in uw sleutelkluis.
(2) - Key Vault verzendt een TLS/SSL-certificaataanvraag naar de CA.
(3) - Uw toepassing pollt, in een lus en wachtproces, voor uw Key Vault voor voltooiing van het certificaat. Het maken van het certificaat is voltooid wanneer Key Vault de reactie van de certificeringsinstantie met x509-certificaat ontvangt.
(4) - De CA reageert op de TLS/SSL-certificaataanvraag van Key Vault met een X509 TLS/SSL-certificaat.
(5) - Het maken van uw nieuwe certificaat is voltooid met de fusie van het X509-certificaat voor de CA.
Key Vault-gebruiker: maakt een certificaat door een beleid op te geven
Herhaal dit indien nodig
Beleidsbeperkingen
- X509-eigenschappen
- Belangrijke eigenschappen
- Providerverwijzing - > bijvoorbeeld MyDigiCertIssure
- Verlengingsgegevens - > bijvoorbeeld 90 dagen vóór de vervaldatum
Een proces voor het maken van certificaten is meestal een asynchroon proces en omvat het peilen van uw sleutelkluis voor de status van de bewerking voor het maken van certificaten.
Certificaatbewerking ophalen- Status: voltooid, mislukt met foutinformatie of geannuleerd
- Vanwege de vertraging die moet worden gemaakt, kan een annuleringsbewerking worden gestart. De annulering kan al dan niet effectief zijn.
Netwerkbeveiligings- en toegangsbeleid dat is gekoppeld aan geïntegreerde CA
De Key Vault-service verzendt aanvragen naar CA (uitgaand verkeer). Daarom is het volledig compatibel met sleutelkluizen met firewalls. Key Vault deelt geen toegangsbeleid met de CA. De CA moet zijn geconfigureerd om ondertekeningsaanvragen onafhankelijk te accepteren. Handleiding voor het integreren van vertrouwde CA
Certificaat importeren
U kunt ook een certificaat importeren in Key Vault : PFX of PEM.
Certificaat importeren: vereist dat een PEM of PFX op schijf is en een persoonlijke sleutel heeft.
U moet opgeven: kluisnaam en certificaatnaam (beleid is optioneel)
PEM-/PFX-bestanden bevatten kenmerken die KV kan parseren en gebruiken om het certificaatbeleid te vullen. Als er al een certificaatbeleid is opgegeven, probeert KV gegevens uit het PFX-/PEM-bestand te vinden.
Zodra het importeren is voltooid, gebruiken volgende bewerkingen het nieuwe beleid (nieuwe versies).
Als er geen verdere bewerkingen zijn, is het eerste wat de Key Vault doet, een vervaldatummelding verzenden.
De gebruiker kan ook het beleid bewerken, dat op het moment van importeren functioneel is, maar standaardwaarden bevat waarbij geen gegevens zijn opgegeven tijdens het importeren. Bijvoorbeeld geen informatie over verleners
Indelingen van Import die we ondersteunen
Azure Key Vault ondersteunt PEM- en PFX-certificaatbestanden voor het importeren van certificaten in Key Vault. We ondersteunen het volgende type import voor PEM-bestandsindeling. Eén met PEM gecodeerd certificaat en een met PKCS#8 gecodeerde, niet-versleutelde sleutel met de volgende indeling:
-----BEGIN CERTIFICAAT-----
-----EIND CERTIFICAAT-----
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
Wanneer u het certificaat importeert, moet u ervoor zorgen dat de sleutel in het bestand zelf is opgenomen. Als u de persoonlijke sleutel afzonderlijk in een andere indeling hebt, moet u de sleutel combineren met het certificaat. Sommige certificeringsinstanties bieden certificaten in verschillende indelingen, dus voordat u het certificaat importeert, moet u ervoor zorgen dat ze een PEM- of PFX-indeling hebben.
Notitie
Zorg ervoor dat er geen andere metagegevens aanwezig zijn in het certificaatbestand en dat de persoonlijke sleutel niet wordt weergegeven als versleuteld.
Indelingen van SAMENVOEG-CSR die we ondersteunen
Azure Key Vault biedt ondersteuning voor PKCS#8 gecodeerd certificaat met onderstaande headers:
-----BEGIN CERTIFICAAT-----
-----EIND CERTIFICAAT-----
Notitie
P7B (PKCS#7) ondertekende certificatenketen, die vaak door certificeringsinstanties (CA's) wordt gebruikt, wordt ondersteund zolang base64 wordt gecodeerd. U kunt certutil -encode gebruiken om te converteren naar ondersteunde indeling.
Een certificaat maken met een CA die niet is gekoppeld aan Key Vault
Met deze methode kunt u werken met andere CA's dan de partnerproviders van Key Vault, wat betekent dat uw organisatie kan werken met een CA naar keuze.
De volgende stapbeschrijvingen komen overeen met de groene stappen in het voorgaande diagram.
(1) - In het bovenstaande diagram maakt uw toepassing een certificaat, dat intern begint met het maken van een sleutel in uw sleutelkluis.
(2) - Key Vault keert terug naar uw toepassing een aanvraag voor certificaatondertekening (CSR).
(3) - Uw toepassing geeft de CSR door aan de door u gekozen CA.
(4) - Uw gekozen CA reageert met een X509-certificaat.
(5) - Uw toepassing voltooit het maken van het nieuwe certificaat met een fusie van het X509-certificaat van uw CA.