PKI-certificaatvereisten (Public Key Infrastructure) voor Azure Stack Hub
Azure Stack Hub heeft een openbaar infrastructuurnetwerk met behulp van 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 Infrastructuur van Azure Stack Hub zijn vereist tijdens de implementatie van Azure Stack Hub. In dit artikel vindt u informatie over:
- Certificaatvereisten voor Azure Stack Hub.
- Verplichte certificaten die vereist zijn voor de implementatie van Azure Stack Hub.
- Optionele certificaten vereist bij het implementeren van waarde-toevoegende resource-providers.
Notitie
Azure Stack Hub maakt standaard ook gebruik van certificaten die zijn uitgegeven door een interne Active Directory-geïntegreerde certificeringsinstantie (CA) voor verificatie tussen de knooppunten. Om het certificaat te valideren, vertrouwen alle Infrastructuurmachines van Azure Stack Hub het basiscertificaat van de interne CA door dat certificaat toe te voegen aan hun lokale certificaatarchief. Er is geen vastzetten of filteren van certificaten in Azure Stack Hub. Het 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 certificaatpinning).
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 basisinstallatiekopieën van het besturingssysteem als onderdeel van het Microsoft Trusted Root Authority Program. Zie lijst met deelnemers - Microsoft Trusted Root Programvoor 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 voor meer informatie functies die slecht of niet beschikbaar zijn in niet-verbonden implementaties.
- Bij het vernieuwen van certificaten in pre-1903-versies moeten certificaten worden uitgegeven door dezelfde interne certificeringsinstantie die wordt gebruikt voor het ondertekenen van certificaten die bij implementatie zijn geleverd, of door een van de eerder genoemde openbare certificeringsinstanties.
- 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 een enkel certificaat gebruiken dat geldt voor alle namensruimten in de onderwerpnaam en alternatieve onderwerpnaam (SAN) van het certificaat. U kunt ook afzonderlijke certificaten gebruiken voor elk van de onderstaande naamruimten die de Azure Stack Hub-services die u wilt gebruiken, vereisen. Voor beide benaderingen is het vereist om jokertekens te gebruiken voor eindpunten waar dat nodig is, zoals KeyVault- en KeyVaultInternal-.
- Het algoritme voor certificaathandtekening mag niet SHA1 zijn.
- De certificaatindeling moet PFX zijn, omdat zowel de openbare als de persoonlijke sleutels vereist zijn voor de installatie van Azure Stack Hub. Voor de persoonlijke sleutel moet het kenmerk van de lokale machine-sleutel 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 een waarde '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 op het moment van de implementatie hetzelfde zijn.
- Wachtwoord voor het certificaat pfx moet een complex wachtwoord zijn. Noteer dit wachtwoord omdat u dit als implementatieparameter gaat gebruiken. Het wachtwoord moet voldoen aan de volgende vereisten voor wachtwoordcomplexiteit:
- Een minimumlengte van acht tekens.
- Ten minste drie van de volgende tekens: hoofdletters, kleine letters, cijfers van 0-9, speciale tekens, alfabetische tekens die geen hoofdletters of kleine letters zijn.
- Zorg ervoor dat de onderwerpnamen en alternatieve onderwerpnamen in de extensie voor alternatieve onderwerpnamen (x509v3_config) overeenkomen. In het veld alternatieve onderwerpnaam kunt u extra hostnamen (websites, IP-adressen, algemene namen) opgeven die door één SSL-certificaat moeten worden beveiligd.
Notitie
Zelfondertekende certificaten worden niet ondersteund.
Wanneer u Azure Stack Hub implementeert in de niet-verbonden modus, wordt u aangeraden certificaten te gebruiken die zijn uitgegeven door een certificeringsinstantie voor ondernemingen. Dit is belangrijk omdat clients die toegang hebben tot Azure Stack Hub-eindpunten, contact moeten kunnen maken met de certificaatintrekkingslijst (CRL).
Notitie
De aanwezigheid van intermediaire certificeringsinstanties wordt ondersteund in de vertrouwensketen van een certificaat .
Verplichte certificaten
In de tabel in deze sectie worden de PKI-certificaten van het openbare Azure Stack Hub-eindpunt 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 is Redmond- en de externe domeinnaam is contoso.com, hebben de DNS-namen de indeling <voorvoegsel>.redmond.contoso.com. Het <voorvoegsel> waarden worden vooraf ontworpen door Microsoft om het eindpunt te beschrijven dat door het certificaat wordt beveiligd. Daarnaast zijn de <voorvoegsel> waarden 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 gekopieerd naar de bijbehorende map. nl-NL: Voor ontwikkelomgevingen kunnen certificaten worden verstrekt als een enkel wildcardcertificaat dat alle naamruimten dekt in de velden Onderwerp en Onderwerp Alternatieve Naam (SAN) en in alle mappen zijn gekopieerd. Eén certificaat voor alle eindpunten en services is een onveilige benadering en daarom alleen geschikt voor ontwikkeling. Houd er rekening mee dat u voor beide opties jokertekencertificaten moet gebruiken voor eindpunten zoals acs- en Key Vault waar ze nodig zijn.
Notitie
Tijdens de implementatie moet u certificaten kopiëren naar de implementatiemap die overeenkomt met de identityprovider waartegen u implementeert (Microsoft Entra ID of AD FS). Als u één certificaat voor alle eindpunten gebruikt, moet u dat certificaatbestand kopiëren naar elke implementatiemap, zoals wordt beschreven in de volgende tabellen. De mapstructuur is vooraf ingebouwd in de virtuele machine voor implementatie en vindt u op: C:\CloudDeployment\Setup\Certificates.
Uitrolmap | Vereist certificaatonderwerp en onderwerpalternatieve namen (SAN) | Bereik (per regio) | Subdomeinnaamruimte |
---|---|---|---|
Openbare portal | portaal.<regio>.<fqdn> | Portalen | <regio>.<> |
Beheerportal | adminportal.<regio>.<> | Portalen | <regio>.<volledig gekwalificeerde domeinnaam> |
Azure Resource Manager (Publiek) | beheer.<regio>.<fqdn> | Azure Resource Manager | <regio>.<> |
Azure Resource Manager-beheerder | adminmanagement.<regio>.<> | Azure Resource Manager | <regio>.<volledig gekwalificeerde domeinnaam> |
ACSBlob | *.blob.<regio>.<fqdn> (Wildcard SSL-certificaat) |
Blob-opslag | blob.<regio>.<fqdn> |
ACSTable | *.tabel.<regio>.<fqdn> (SSL-certificaat met jokertekens) |
Tabelopslag | tafel.<regio>.<fqdn> |
ACSQueue | *.rij.<regio>.<> (Wildcard SSL-certificaat) |
Wachtrijopslag | rij.<regio>.<fqdn> |
KeyVault | *.kluis.<regio>.<fqdn> Wildcard SSL-certificaat |
Key Vault | gewelf.<regio>.<volledig gekwalificeerde domeinnaam> |
KeyVaultInternal | *.adminvault.<regio>.<fqdn> (SSL-certificaat met wildcard) |
Interne sleutelkluis | adminvault.<regio>.<> |
Host van beheerextensie | *.adminhosting.<regio>.<fqdn> (Wildcard SSL-certificaten) | Host van beheerextensie | adminhosting.<regio>.<> |
Host van openbare extensie | *.hosting.<regio>.<fqdn-> (Wildcard SSL-certificaten) | Host van openbare extensie | gastvrijheid.<regio>.<> |
Als u Azure Stack Hub implementeert met behulp van de Microsoft Entra-implementatiemodus, hoeft u alleen de certificaten op 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 worden beschreven in de volgende tabel:
Uitrolmap | Vereist certificaatonderwerp en alternatieve namen voor onderwerp (SAN) | Bereik (per regio) | Subdomeinnaamruimte |
---|---|---|---|
ADFS | adfs.<regio>.<fqdn> (SSL-certificaat) |
ADFS | <regio>.<fqdn> |
Grafiek | grafiek.<regio>.<fqdn> (SSL-certificaat) |
Grafiek | <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 om de eindpunten van de PaaS-services te dekken.
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 | Vereist certificaatonderwerp en alternatieve namen voor onderwerp (SAN's) | Subdomeinnaamruimte |
---|---|---|---|
App Service | Standaard SSL-certificaat voor webverkeer | *.appservice.<regio>.<> *.scm.appservice.<regio>.<fqdn> *.sso.appservice.<regio>. volledig gekwalificeerde domeinnaam<> Ssl-certificaat voor meerdere domeinen met wildcard1 |
appservice.<regio>.<fqdn> scm.appservice.<regio>.<fqdn> |
App-dienst | API | api.appservice.<regio>.<fqdn> (SSL-certificaat2) |
appservice.<regio>.<fqdn> scm.appservice.<regio>.<> |
App Service | FTP | ftp.appservice.<regio>.<> (SSL-certificaat2) |
appservice.<regio>.<> scm.appservice.<regio>.<fqdn> |
App-dienst | SSO | sso.appservice.<regio>.<> (SSL-certificaat2) |
appservice.<regio>.<fqdn> scm.appservice.<regio>.<.> |
Event Hubs | SSL | *.eventhub.<regio>.<fqdn> (SSL-certificaat met wildcards) |
eventhub.<regio>.<fqdn> |
SQL, MySQL | SQL en MySQL | *.dbadapter.<regio>.<> Wildcard SSL-certificaat |
dbadapter.<regio>.<fqdn> |
1 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.
2 A *.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 PKI-certificaten genereren voor azure Stack Hub-implementatie.