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 Azure Stack Hub openbare infrastructuur-eindpunten zijn vereist tijdens Azure Stack Hub implementatie. Dit artikel bevat informatie over:
- Certificaatvereisten voor Azure Stack Hub.
- Verplichte certificaten die vereist zijn voor Azure Stack Hub implementatie.
- Optionele certificaten die vereist zijn bij het implementeren van resourceproviders voor waarde-toevoegen.
Notitie
Azure Stack Hub gebruikt standaard ook certificaten die zijn uitgegeven door een interne, in Active Directory geïntegreerde certificeringsinstantie (CA) voor verificatie tussen de knooppunten. Om het certificaat te valideren, vertrouwen Azure Stack Hub infrastructuurmachines het basiscertificaat van de interne CERTIFICERINGsinstantie door dat certificaat toe te voegen aan hun lokale certificaatopslag. Er is geen sprake van het vastmaken of filteren van certificaten in Azure Stack Hub. De SAN van elk servercertificaat wordt gevalideerd op de FQDN-naam van het doel. De volledige vertrouwensketen wordt ook gevalideerd, samen met de vervaldatum van het certificaat (standaard-TLS-serververificatie zonder dat het certificaat is vastgemaakt).
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 er een openbare certificeringsinstantie wordt gebruikt, moet deze worden opgenomen in de basisinstallatieprogramma van het besturingssysteem als onderdeel van het Microsoft Trusted Root Authority Program. 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 certificaatintrekkende certificaatintrekkende lijst (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 beperkt of niet beschikbaar zijn in niet-verbonden implementaties voor meer informatie.
- Bij het roteren van certificaten in builds vóór 1903, moeten certificaten worden uitgegeven door dezelfde interne certificeringsinstantie die wordt gebruikt voor het ondertekenen van certificaten die zijn opgegeven tijdens de implementatie of een openbare certificeringsinstantie van hierboven.
- Bij het roteren van certificaten voor builds 1903 en hoger kunnen certificaten worden uitgegeven door elke onderneming of openbare certificeringsinstantie.
- Het gebruik van zelf-ondertekende certificaten wordt niet ondersteund.
- Voor implementatie en roulatie kunt u één certificaat gebruiken dat alle naamruimten in de onderwerpnaam en san van het certificaat beslaat. U kunt ook afzonderlijke certificaten gebruiken voor elk van de onderstaande naamruimten die de Azure Stack Hub die u wilt gebruiken. Voor beide benaderingen is het gebruik van jokerwoorden vereist voor eindpunten, 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 Azure Stack Hub installatie. Voor de persoonlijke sleutel moet het kenmerk van de 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 certificaatopslag).
- De PFX-bestanden van het certificaat moeten de waarde Digitale handtekening en Sleutelcode in het veld Sleutelgebruik hebben.
- 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 'Verleend aan:' van het certificaat mag niet hetzelfde zijn als het veld 'Uitgegeven door:'.
- De wachtwoorden voor alle PFX-bestanden van certificaten moeten op het moment van implementatie hetzelfde zijn.
- Het wachtwoord voor het pfx-certificaat moet een complex wachtwoord zijn. Noteer dit wachtwoord omdat u dit gebruikt als een implementatieparameter. Het wachtwoord moet voldoen aan de volgende vereisten voor wachtwoordcomplexiteit:
- Minimaal acht tekens lang.
- 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 namen voor onderwerpen in de alternatieve naamextensie (x509v3_config) overeenkomen. In het veld Alternatieve naam voor onderwerp kunt u aanvullende hostnamen (websites, IP-adressen, algemene namen) opgeven die moeten worden beveiligd met één SSL-certificaat.
Notitie
Zelf-ondertekende certificaten worden niet ondersteund.
Bij het implementeren Azure Stack Hub in de niet-verbonden modus is het raadzaam om certificaten te gebruiken die zijn uitgegeven door een certificeringsinstantie van een onderneming. Dit is belangrijk omdat clients die toegang hebben Azure Stack Hub eindpunten contact moeten kunnen opnemen met de certificaat intrekken lijst (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 Azure Stack Hub PKI-certificaten voor openbare eindpunten beschreven die vereist zijn voor zowel Azure AD- 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 Azure Stack Hub openbare infrastructuur-eindpunt zijn vereist. De DNS-naam van elk eindpunt wordt uitgedrukt in de indeling: voorvoegsel>.< regio>.< fqdn>.
Voor uw implementatie moeten de>> 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 het indelingsprefix.redmond.contoso.com. De voorvoegselwaarden> worden 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 wordt aangeraden om afzonderlijke certificaten te genereren voor elk eindpunt en te kopiëren naar de bijbehorende map. Voor ontwikkelomgevingen kunnen certificaten worden opgegeven als één jokertekencertificaat voor alle naamruimten in de velden Onderwerp en Alternatieve naam voor onderwerp (SAN) die in alle directories zijn gekopieerd. Eén certificaat voor alle eindpunten en services is een onveilige postuur en dus alleen-ontwikkelen. Vergeet niet dat u voor beide opties jokertekencertificaten moet gebruiken voor eindpunten zoals acs en Key Vault waar ze vereist zijn.
Notitie
Tijdens de implementatie moet u certificaten kopiëren naar de implementatiemap die overeenkomt met de id-provider die u implementeert (Azure AD of AD FS). Als u één certificaat voor alle eindpunten gebruikt, moet u dat certificaatbestand kopiëren naar elke implementatiemap, zoals beschreven in de volgende tabellen. De mapstructuur is vooraf gebouwd in de virtuele implementatiemachine en is te vinden op: C:\CloudDeployment\Setup\Certificates.
| Implementatiemap | Vereiste alternatieve namen voor certificaatonderwerpen en onderwerp (SAN) | Bereik (per regio) | Subdomeinnaamruimte |
|---|---|---|---|
| Openbare portal | Portal.< regio>.< Fqdn> | Portals | <regio>.< Fqdn> |
| Beheerportal | adminportal.< regio>.< Fqdn> | Portals | <regio>.< Fqdn> |
| Azure Resource Manager Openbaar | Management.< regio>.< Fqdn> | Azure Resource Manager | <regio>.< Fqdn> |
| Azure Resource Manager beheerder | beheer.< regio>.< Fqdn> | Azure Resource Manager | <regio>.< Fqdn> |
| ACSBlob | *.blob.< regio>.< Fqdn> (SSL-certificaat met jokerteken) |
Blob Storage | Blob.< regio>.< Fqdn> |
| ACSTable | *.table.< regio>.< Fqdn> (SSL-certificaat met jokerteken) |
Table Storage | Tabel.< regio>.< Fqdn> |
| ACSQueue | *.queue.< regio>.< Fqdn> (SSL-certificaat met jokerteken) |
Queue Storage | Wachtrij.< regio>.< Fqdn> |
| KeyVault | *.vault.< regio>.< Fqdn> (SSL-certificaat met jokerteken) |
Key Vault | Kluis.< regio>.< Fqdn> |
| KeyVaultInternal | *.adminvault.< regio>.< Fqdn> (SSL-certificaat met jokerteken) |
Interne sleutelkault | adminvault.< regio>.< Fqdn> |
| Admin Extension Host | *.adminhosting.< regio>.< fqdn> (SSL-certificaten met jokerteken) | Admin Extension Host | adminhosting.< regio>.< Fqdn> |
| Openbare extensiehost | *.hosting.< regio>.< fqdn> (SSL-certificaten met jokerteken) | Openbare extensiehost | Hosting.< regio>.< Fqdn> |
Als u een Azure Stack Hub de Azure AD-implementatiemodus implementeert, hoeft u alleen de certificaten aan te vragen die in de vorige tabel worden vermeld. Maar als u een certificaat implementeert Azure Stack Hub de AD FS-implementatiemodus, moet u ook de certificaten aanvragen die worden beschreven in de volgende tabel:
| Implementatiemap | Vereiste alternatieve namen voor certificaatonderwerp en onderwerp (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 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 Azure Stack Hub implementatiemap. 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> |
1 Vereist één certificaat met meerdere alternatieve namen voor jokertekens. Meerdere SAN's met jokertekens voor één certificaat worden mogelijk niet ondersteund door alle openbare certificeringsinstanties.
2 Een *.appservice. regio.< Het fqdn-jokertekencertificaat> kan niet worden gebruikt in plaats van deze drie certificaten (api.appservice.<, ftp.appservice. > en sso.appservice. <. Appservice vereist expliciet het gebruik van afzonderlijke certificaten voor deze eindpunten.
Volgende stappen
Informatie over het genereren van PKI-certificaten voor Azure Stack Hub implementatie.