Certificaatvereisten voor PKI (openbare-sleutelinfrastructuur) van Azure Stack Hub

Azure Stack Hub heeft een openbaar infrastructuurnetwerk met extern toegankelijke openbare IP-adressen die zijn toegewezen aan een kleine set Azure Stack Hub-services en mogelijk tenant-VM's. PKI-certificaten met de juiste DNS-namen voor deze eindpunten van de openbare Azure Stack Hub-infrastructuur zijn vereist tijdens de implementatie van Azure Stack Hub. Dit artikel bevat informatie over:

• Certificaatvereisten voor Azure Stack Hub.
• Verplichte certificaten die vereist zijn voor de implementatie van Azure Stack Hub.
• Optionele certificaten die vereist zijn bij het implementeren van resourceproviders die waarde toevoegen.

Notitie

Azure Stack Hub maakt standaard ook gebruik van certificaten die zijn uitgegeven door een interne met Active Directory geïntegreerde certificeringsinstantie (CA) voor verificatie tussen de knooppunten. Om het certificaat te valideren, vertrouwen alle Azure Stack Hub-infrastructuurmachines het basiscertificaat van de interne CA door dat certificaat toe te voegen aan hun lokale certificaatarchief. Er is geen vastmaken of filteren van certificaten in Azure Stack Hub. De SAN van elk servercertificaat wordt gevalideerd op basis van de FQDN van het doel. De volledige vertrouwensketen wordt ook gevalideerd, samen met de vervaldatum van het certificaat (standaard TLS-serververificatie zonder het vastmaken van certificaten).

Certificaatvereisten

In de volgende lijst worden de algemene vereisten voor certificaatuitgifte, beveiliging en opmaak beschreven:

• Certificaten moeten worden uitgegeven door een interne certificeringsinstantie of een openbare certificeringsinstantie. Als een openbare certificeringsinstantie wordt gebruikt, moet deze worden opgenomen in de installatiekopieën van het basisbesturingssysteem als onderdeel van het Microsoft Trusted Root Authority-programma. Zie Lijst met deelnemers - Microsoft Trusted Root Program voor de volledige lijst.
• Uw Azure Stack Hub-infrastructuur moet netwerktoegang hebben tot de locatie van de certificaatintrekkingslijst (CRL) van de certificeringsinstantie die in het certificaat is gepubliceerd. Deze CRL moet een HTTP-eindpunt zijn. Opmerking: voor niet-verbonden implementaties worden certificaten die zijn uitgegeven door een openbare certificeringsinstantie (CA) niet ondersteund als het CRL-eindpunt niet toegankelijk is. Zie Functies die zijn beperkt of niet beschikbaar zijn in niet-verbonden implementaties voor meer informatie.

• Bij het roteren van certificaten voor builds 1903 en hoger kunnen certificaten worden uitgegeven door elke onderneming of openbare certificeringsinstantie.

• Het gebruik van zelfondertekende certificaten wordt niet ondersteund.
• Voor implementatie en rotatie kunt u één certificaat gebruiken dat alle naamruimten in de onderwerpnaam en alternatieve onderwerpnaam (SAN) van het certificaat dekt. U kunt ook afzonderlijke certificaten gebruiken voor elk van de onderstaande naamruimten die nodig zijn voor de Azure Stack Hub-services die u wilt gebruiken. Beide benaderingen vereisen het gebruik van jokertekens voor eindpunten waar ze nodig zijn, zoals KeyVault en KeyVaultInternal.
• Het algoritme voor certificaathandtekening mag niet SHA1 zijn.
• De certificaatindeling moet PFX zijn, omdat zowel de openbare als de persoonlijke sleutel vereist zijn voor de installatie van Azure Stack Hub. Voor de persoonlijke sleutel moet het kenmerk lokale computersleutel zijn ingesteld.
• De PFX-versleuteling moet 3DES zijn (deze versleuteling is standaard bij het exporteren vanuit een Windows 10-client of Windows Server 2016 certificaatarchief).
• De pfx-bestanden van het certificaat moeten de waarden 'Digitale handtekening' en 'KeyEncipherment' hebben in het veld 'Sleutelgebruik'.
• De pfx-bestanden van het certificaat moeten de waarden Serververificatie (1.3.6.1.5.5.7.3.1) en Clientverificatie (1.3.6.1.5.5.7.3.2) hebben in het veld Uitgebreid sleutelgebruik.
• Het veld 'Uitgegeven aan:' van het certificaat mag niet hetzelfde zijn als het veld 'Uitgegeven door:'.
• De wachtwoorden voor alle pfx-certificaatbestanden moeten hetzelfde zijn op het moment van implementatie.
• Het wachtwoord voor het pfx-certificaat moet een complex wachtwoord zijn. Noteer dit wachtwoord omdat u dit als een implementatieparameter gebruikt. Het wachtwoord moet voldoen aan de volgende vereisten voor wachtwoordcomplexiteit:
  • Een minimale lengte van acht tekens.
  • Ten minste drie van de volgende tekens: hoofdletters, kleine letters, cijfers van 0-9, speciale tekens, alfabetisch teken dat geen hoofdletters of kleine letters is.
• Zorg ervoor dat de onderwerpnamen en alternatieve onderwerpnamen in de alternatieve naamextensie voor onderwerp (x509v3_config) overeenkomen. In het veld Alternatieve onderwerpnaam kunt u extra hostnamen (websites, IP-adressen, algemene namen) opgeven die moeten worden beveiligd door één SSL-certificaat.

Notitie

Zelfondertekende certificaten worden niet ondersteund.
Wanneer u Azure Stack Hub implementeert in de modus niet-verbonden, wordt aanbevolen certificaten te gebruiken die zijn uitgegeven door een certificeringsinstantie van een onderneming. Dit is belangrijk omdat clients die toegang hebben tot Azure Stack Hub-eindpunten, contact moeten kunnen opnemen met de certificaatintrekkingslijst (CRL).

Notitie

De aanwezigheid van intermediaire certificeringsinstanties in de vertrouwensketen van een certificaat wordt ondersteund.

Verplichte certificaten

In de tabel in deze sectie worden de PKI-certificaten voor openbare eindpunten van Azure Stack Hub beschreven die vereist zijn voor zowel Microsoft Entra-id als AD FS Azure Stack Hub-implementaties. Certificaatvereisten worden gegroepeerd op gebied en de gebruikte naamruimten en de certificaten die vereist zijn voor elke naamruimte. In de tabel wordt ook de map beschreven waarin uw oplossingsprovider de verschillende certificaten per openbaar eindpunt kopieert.

Certificaten met de juiste DNS-namen voor elk eindpunt van de openbare Infrastructuur van Azure Stack Hub zijn vereist. De DNS-naam van elk eindpunt wordt uitgedrukt in de indeling: <voorvoegsel>.<regio>.<fqdn>.

Voor uw implementatie moeten de <regio> - en <fqdn-waarden> overeenkomen met de regio- en externe domeinnamen die u hebt gekozen voor uw Azure Stack Hub-systeem. Als de regio bijvoorbeeld Redmond is en de externe domeinnaam is contoso.com, hebben de DNS-namen de indeling <voorvoegsel.redmond.contoso.com>. De <voorvoegselwaarden> zijn vooraf ontworpen door Microsoft om het eindpunt te beschrijven dat door het certificaat wordt beveiligd. Bovendien zijn de <voorvoegselwaarden> van de eindpunten van de externe infrastructuur afhankelijk van de Azure Stack Hub-service die gebruikmaakt van het specifieke eindpunt.

Voor de productieomgevingen raden we aan afzonderlijke certificaten te genereren voor elk eindpunt en naar de bijbehorende map te kopiëren. Voor ontwikkelomgevingen kunnen certificaten worden opgegeven als één jokertekencertificaat voor alle naamruimten in de velden Onderwerp en Alternatieve naam voor onderwerp (SAN) die naar alle mappen zijn gekopieerd. Eén certificaat voor alle eindpunten en services is een onveilige houding en dus alleen voor ontwikkeling. Houd er rekening mee dat u voor beide opties jokertekencertificaten moet gebruiken voor eindpunten zoals acs en Key Vault waar ze zijn vereist.

Notitie

Tijdens de implementatie moet u certificaten kopiëren naar de implementatiemap die overeenkomt met de id-provider waarvoor u implementeert (Microsoft Entra-id of AD FS). Als u één certificaat voor alle eindpunten gebruikt, moet u dat certificaatbestand naar elke implementatiemap kopiëren, zoals beschreven in de volgende tabellen. De mapstructuur is vooraf gebouwd in de virtuele implementatiemachine en vindt u op: C:\CloudDeployment\Setup\Certificates.

Implementatiemap	Vereiste certificaatonderwerp- en onderwerp alternatieve namen (SAN)	Bereik (per regio)	Subdomeinnaamruimte
Openbare portal	Portal.<regio>.<Fqdn>	Portals	<regio>.<Fqdn>
Beheerportal	adminportal.<regio>.<Fqdn>	Portals	<regio>.<Fqdn>
Azure Resource Manager Public	Management.<regio>.<Fqdn>	Azure Resource Manager	<regio>.<Fqdn>
Azure Resource Manager Beheer	adminmanagement.<regio>.<Fqdn>	Azure Resource Manager	<regio>.<Fqdn>
ACSBlob	*.Blob.<regio>.<Fqdn> (SSL-certificaat met jokerteken)	Blob Storage	Blob.<regio>.<Fqdn>
ACSTable	*.Tabel.<regio>.<Fqdn> (SSL-certificaat met jokerteken)	Table Storage	Tabel.<regio>.<Fqdn>
ACSQueue	*.Wachtrij.<regio>.<Fqdn> (SSL-certificaat met jokerteken)	Queue Storage	Wachtrij.<regio>.<Fqdn>
KeyVault	*.Kluis.<regio>.<Fqdn> (SSL-certificaat met jokerteken)	Key Vault	Kluis.<regio>.<Fqdn>
KeyVaultInternal	*.adminvault.<regio>.<Fqdn> (SSL-certificaat met jokerteken)	Interne sleutelkluis	adminvault.<regio>.<Fqdn>
Beheer-extensiehost	*.adminhosting.<regio>.<fqdn> (SSL-certificaten met jokertekens)	Beheer-extensiehost	adminhosting.<regio>.<Fqdn>
Host van openbare extensie	*.Hosting.<regio>.<fqdn> (SSL-certificaten met jokertekens)	Host van openbare extensie	Hosting.<regio>.<Fqdn>

Als u Azure Stack Hub implementeert met behulp van de Microsoft Entra-implementatiemodus, hoeft u alleen de certificaten aan te vragen die in de vorige tabel worden vermeld. Maar als u Azure Stack Hub implementeert met behulp van de AD FS-implementatiemodus, moet u ook de certificaten aanvragen die in de volgende tabel worden beschreven:

Implementatiemap	Vereiste certificaatonderwerp- en onderwerp alternatieve namen (SAN)	Bereik (per regio)	Subdomeinnaamruimte
ADFS	Adfs. <regio>.<Fqdn> (SSL-certificaat)	ADFS	<regio>.<Fqdn>
Graph	Grafiek. <regio>.<Fqdn> (SSL-certificaat)	Graph	<regio>.<Fqdn>

Belangrijk

Alle certificaten die in deze sectie worden vermeld, moeten hetzelfde wachtwoord hebben.

Optionele PaaS-certificaten

Als u van plan bent om Azure Stack Hub PaaS-services (zoals SQL, MySQL, App Service of Event Hubs) te implementeren nadat Azure Stack Hub is geïmplementeerd en geconfigureerd, moet u aanvullende certificaten aanvragen voor de eindpunten van de PaaS-services.

Belangrijk

De certificaten die u voor resourceproviders gebruikt, moeten dezelfde basisinstantie hebben als de certificaten die worden gebruikt voor de globale Azure Stack Hub-eindpunten.

In de volgende tabel worden de eindpunten en certificaten beschreven die vereist zijn voor resourceproviders. U hoeft deze certificaten niet te kopiëren naar de implementatiemap van Azure Stack Hub. In plaats daarvan geeft u deze certificaten op tijdens de installatie van de resourceprovider.

Bereik (per regio)	Certificaat	Vereiste certificaatonderwerp en alternatieve namen voor onderwerp (SAN's)	Subdomeinnaamruimte
App Service	Standaard SSL-certificaat voor webverkeer	*.appservice. <regio>.<Fqdn> *.scm.appservice. <regio>.<Fqdn> *.sso.appservice. <regio>.<Fqdn> (Multi Domain Wildcard SSL Certificate1)	appservice. <regio>.<Fqdn> scm.appservice. <regio>.<Fqdn>
App Service	API	api.appservice. <regio>.<Fqdn> (SSL-certificaat2)	appservice. <regio>.<Fqdn> scm.appservice. <regio>.<Fqdn>
App Service	FTP	ftp.appservice. <regio>.<Fqdn> (SSL-certificaat2)	appservice. <regio>.<Fqdn> scm.appservice. <regio>.<Fqdn>
App Service	SSO	sso.appservice. <regio>.<Fqdn> (SSL-certificaat2)	appservice. <regio>.<Fqdn> scm.appservice. <regio>.<Fqdn>
Event Hubs	SSL	*.eventhub. <regio>.<Fqdn> (SSL-certificaat met jokerteken)	eventhub. <regio>.<Fqdn>
SQL, MySQL	SQL en MySQL	*.dbadapter. <regio>.<Fqdn> (SSL-certificaat met jokerteken)	dbadapter. <regio>.<Fqdn>

¹ Vereist één certificaat met meerdere alternatieve namen voor jokertekens. Meerdere SAN's met jokertekens op één certificaat worden mogelijk niet ondersteund door alle openbare certificeringsinstanties.

² Een *.appservice. <regio>.<fqdn-jokertekencertificaat> kan niet worden gebruikt in plaats van deze drie certificaten (api.appservice.<regio>.<fqdn>, ftp.appservice. <regio>.<fqdn> en sso.appservice. <regio>.<fqdn>. Appservice vereist expliciet het gebruik van afzonderlijke certificaten voor deze eindpunten.

Volgende stappen

Meer informatie over het genereren van PKI-certificaten voor de implementatie van Azure Stack Hub.