Certifikatkrav för Azure Stack Hub för offentlig nyckelinfrastruktur (PKI)
Azure Stack Hub har ett offentligt infrastrukturnätverk med externt tillgängliga offentliga IP-adresser tilldelade till en liten uppsättning Azure Stack Hub-tjänster och eventuellt virtuella klientdatorer. PKI-certifikat med lämpliga DNS-namn för dessa slutpunkter för offentlig infrastruktur i Azure Stack Hub krävs under Azure Stack Hub-distributionen. Den här artikeln innehåller information om:
- Certifikatkrav för Azure Stack Hub.
- Obligatoriska certifikat som krävs för Azure Stack Hub-distribution.
- Certifikat kan behövas när du distribuerar mervärdeskapande resursleverantörer.
Not
Azure Stack Hub använder som standard även certifikat som utfärdats från en intern Active Directory-integrerad certifikatutfärdare (CA) för autentisering mellan noderna. För att verifiera certifikatet litar alla Azure Stack Hub-infrastrukturdatorer på rotcertifikatet för den interna certifikatutfärdare genom att lägga till certifikatet i sitt lokala certifikatarkiv. Det går inte att fästa eller filtrera certifikat i Azure Stack Hub. SAN för varje servercertifikat verifieras mot målets FQDN. Hela förtroendekedjan verifieras också, tillsammans med certifikatets förfallodatum (standard-TLS-serverautentisering utan att certifikatet fästs).
Certifikatkrav
I följande lista beskrivs de allmänna kraven för utfärdande, säkerhet och formatering av certifikat:
- Certifikat måste utfärdas från antingen en intern certifikatutfärdare eller en offentlig certifikatutfärdare. Om en offentlig certifikatutfärdare används måste den ingå i den grundläggande operativsystemavbildningen som en del av Microsoft Trusted Root Authority Program. Den fullständiga listan finns i Lista över deltagare – Microsoft Trusted Root Program.
- Azure Stack Hub-infrastrukturen måste ha nätverksåtkomst till certifikatutfärdares crl-plats (Certificate Revocation List) som publicerats i certifikatet. Den här CRL:en måste vara en http-slutpunkt. Obs! för frånkopplade distributioner stöds inte certifikat som utfärdats av en offentlig certifikatutfärdare (CA) om CRL-slutpunkten inte är tillgänglig. För mer information, se funktioner som är begränsade eller otillgängliga i frånkopplade distributioner.
- När du roterar certifikat i versioner före 1903 måste certifikat antingen utfärdas från samma interna certifikatutfärdare som används för att signera certifikat som tillhandahålls vid distributionen eller från någon offentlig certifikatutfärdare ovan.
- När du roterar certifikat för versioner 1903 och senare, kan dessa certifikat utfärdas av vilken företags- eller offentlig certifikatutfärdare som helst.
- Användning av självsignerade certifikat stöds inte.
- För distribution och rotation kan du antingen använda ett enda certifikat som täcker alla namnrymder i certifikatets ämnesnamn (SN) och alternativt ämnesnamn (SAN). Du kan också använda enskilda certifikat för vart och ett av de namnområden nedan som de Azure Stack Hub-tjänster som du planerar att använda kräver. Båda metoderna kräver att du använder jokertecken för slutpunkter där de krävs, till exempel KeyVault och KeyVaultInternal.
- Certifikatsignaturalgoritmen ska inte vara SHA1.
- Certifikatformatet måste vara PFX eftersom både offentliga och privata nycklar krävs för Azure Stack Hub-installation. Den privata nyckeln måste ha det lokala datornyckelattributet inställt.
- PFX-krypteringen måste vara 3DES (den här krypteringen är standard när du exporterar från en Windows 10-klient eller Ett Windows Server 2016-certifikatarkiv).
- Certifikatets pfx-filer måste ha värdet "Digital signatur" och "KeyEncipherment" i fältet "Nyckelanvändning".
- Certifikatets pfx-filer måste ha värdena "Serverautentisering (1.3.6.1.5.5.7.3.1)" och "Klientautentisering (1.3.6.1.5.5.7.3.2)" i fältet "Utökad nyckelanvändning".
- Certifikatets fält "Utfärdat till:" får inte vara detsamma som fältet "Utfärdat av:".
- Lösenorden till alla pfx-certifikatfiler måste vara desamma vid tidpunkten för distributionen.
- Lösenord till certifikatets pfx måste vara ett komplext lösenord. Anteckna det här lösenordet eftersom du använder det som en distributionsparameter. Lösenordet måste uppfylla följande krav på lösenordskomplexitet:
- Minst åtta tecken.
- Minst tre av följande teckentyper: versaler, gemener, siffror från 0–9, specialtecken, tecken som inte är versaler eller gemener.
- Se till att ämnesnamnen och de alternativa ämnesnamnen i det alternativa ämnesnamnstillägget (x509v3_config) matchar. Med fältet Alternativt namn för ämne kan du ange ytterligare värdnamn (webbplatser, IP-adresser, vanliga namn) som ska skyddas av ett enda SSL-certifikat.
Notera
Självsignerade certifikat stöds inte.
När du distribuerar Azure Stack Hub i frånkopplat läge rekommenderar vi att du använder certifikat som utfärdats av en företagscertifikatutfärdare. Detta är viktigt eftersom klienter som har åtkomst till Azure Stack Hub-slutpunkter måste kunna kontakta listan över återkallade certifikat (CRL).
Anteckning
Förekomsten av mellanliggande certifikatutfärdare i en certifikatkedjas förtroendehierarki är stödd.
Obligatoriska certifikat
I tabellen i det här avsnittet beskrivs de offentliga PKI-certifikat för Azure Stack Hub-slutpunkter som krävs för både Microsoft Entra-ID och AD FS Azure Stack Hub-distributioner. Certifikatkraven grupperas efter område och de namnområden som används och de certifikat som krävs för varje namnområde. Tabellen beskriver också mappen där lösningsprovidern kopierar de olika certifikaten per offentlig slutpunkt.
Certifikat med lämpliga DNS-namn för varje slutpunkt för den offentliga infrastrukturen i Azure Stack Hub krävs. Varje slutpunkts DNS-namn uttrycks i formatet: <prefix>.<region>.<fqdn>.
För distributionen måste <region> och <fqdn-> värden matcha de region- och externa domännamn som du valde för ditt Azure Stack Hub-system. Om regionen till exempel är Redmond och det externa domännamnet är contoso.comhar DNS-namnen formatet <prefixet>.redmond.contoso.com. De <-prefix>-värdena är förbestämda av Microsoft för att beskriva slutpunkten som skyddas av certifikatet. Dessutom beror prefixet <> för värdena på de externa infrastrukturens slutpunkter på den Azure Stack Hub-tjänst som använder den specifika slutpunkten.
För produktionsmiljöerna rekommenderar vi att enskilda certifikat genereras för varje slutpunkt och kopieras till motsvarande katalog. För utvecklingsmiljöer kan certifikat tillhandahållas som ett enskilt wildcard-certifikat som täcker alla namnområden i fälten Ämne och Alternativt namn för certifikatmottagare (SAN) som kopieras till alla kataloger. Ett enda certifikat som täcker alla slutpunkter och tjänster utgör en osäker säkerhetsstrategi och är därmed endast avsedd för utvecklingsändamål. Kom ihåg att båda alternativen kräver att du använder wildcard-certifikat på slutpunkter såsom acs och Key Vault där de krävs.
Notera
Under distributionen måste du kopiera certifikat till distributionsmappen som matchar den identitetsprovider som du distribuerar mot (Microsoft Entra-ID eller AD FS). Om du använder ett enda certifikat för alla slutpunkter måste du kopiera certifikatfilen till varje distributionsmapp enligt beskrivningen i följande tabeller. Mappstrukturen är förbyggd i den virtuella distributionsdatorn och finns på: C:\CloudDeployment\Setup\Certificates.
| Distributionsmapp | Obligatoriskt certifikatsubjekt och ämnesalternativa namn (SAN) | Omfattning (per region) | Underdomännamnområde |
|---|---|---|---|
| Offentlig portal | portal.<region>.<fqdn> | Portaler | <region>.<fqdn> |
| Administratörsportal | adminportal.<region>.<fqdn> | Portaler | <region>.<fqdn> |
| Azure Resource Manager, offentligt | förvaltning.<region>.<fqdn> | Azure Resource Manager | <region>.<fqdn> |
| Azure Resource Manager-administratör | administrationshantering.<region>.<fqdn> | Azure Resource Manager | <region>.<fqdn> |
| ACSBlob | *.blob.<region>.<fqdn> (SSL-certifikat med jokertecken) |
Blob Storage | blob.<region>.<fqdn> |
| ACSTable | *.tabell.<region>.<fqdn> (SSL-certifikat med jokertecken) |
Tabellagring | bord.<region>.<fqdn> |
| ACSQueue | *.queue.<region>.<fqdn> Wildcard SSL-certifikat |
Kölager | kö.<region>.<fqdn> |
| KeyVault | *.säkerlagring.<region>.<fqdn> (SSL-certifikat med jokertecken) |
Nyckelvalv | valv.<region>.<fqdn> |
| KeyVaultInternal | *.adminvault.<region>.<fqdn> (Wildcard SSL-certifikat) |
Internt nyckelvalv | adminvault.<region>.<fqdn> |
| Administratörstilläggsvärd | *.adminhosting.<region>.<fqdn> (SSL-jokerteckencertifikat) | Administratörstilläggsvärd | adminhosting.<region>.<fqdn> |
| Värd för offentligt tillägg | *.hosting.<region>.<fqdn> (Wildcard SSL-certifikat) | Värd för offentligt tillägg | värdtjänst.<region>.<fqdn> |
Om du distribuerar Azure Stack Hub med microsoft Entra-distributionsläget behöver du bara begära certifikaten som anges i föregående tabell. Men om du distribuerar Azure Stack Hub med hjälp av AD FS-distributionsläget måste du också begära certifikaten som beskrivs i följande tabell:
| Implementeringsmapp | Obligatoriskt certifikatämne och alternativa ämnesnamn (SAN) | Omfång (per region) | Underdomännamnområde |
|---|---|---|---|
| ADFS | adfs.<region>.<fqdn> (SSL-certifikat) |
ADFS | <region>.<fqdn> |
| Graf | graf.<region>.<fqdn> (SSL-certifikat) |
Graf | <region>.<fqdn> |
Viktig
Alla certifikat som anges i det här avsnittet måste ha samma lösenord.
Valfria PaaS-certifikat
Om du planerar att distribuera Azure Stack Hub PaaS-tjänster (till exempel SQL, MySQL, App Service eller Event Hubs) när Azure Stack Hub har distribuerats och konfigurerats måste du begära ytterligare certifikat för att täcka slutpunkterna för PaaS-tjänsterna.
Viktig
De certifikat som du använder för resursprovidrar måste ha samma rotutfärdare som de som används för de globala Azure Stack Hub-slutpunkterna.
I följande tabell beskrivs de slutpunkter och certifikat som krävs för resursprovidrar. Du behöver inte kopiera dessa certifikat till Azure Stack Hub-distributionsmappen. I stället anger du dessa certifikat under installationen av resursprovidern.
| Täckning (per region) | Intyg | Obligatoriskt ämne för certifikat och Alternativa ämnesnamn (SAN) | Underdomännamnområde |
|---|---|---|---|
| App Service | Standard-SSL-certifikat för webbtrafik | *.appservice.<region>.<fqdn> *.scm.appservice.<region>.<fqdn> *.sso.appservice.<region>.<fqdn> (SSL-jokerteckencertifikat för flera domäner1) |
appservice.<region>.<fqdn> scm.appservice.<region>.<fqdn> |
| App Service | API | api.appservice.<region>.<fqdn> (SSL-certifikat2) |
appservice.<region>.<fqdn> scm.appservice.<region>.<fqdn> |
| App Service | FTP | ftp.appservice.<region>.<fqdn> (SSL-certifikat2) |
appservice.<region>.<fqdn> scm.appservice.<region>.<fqdn> |
| App Service | SSO | sso.appservice.<region>.<fqdn> (SSL-certifikat2) |
appservice.<region>.<fqdn> scm.appservice.<region>.<fqdn> |
| Event Hubs | SSL | *.eventhub.<region>.<fqdn> (SSL-certifikat med jokertecken) |
eventhub.<region>.<fqdn> |
| SQL, MySQL | SQL och MySQL | *.dbadapter.<region>.<fqdn> (SSL-certifikat med jokertecken) |
dbadapter.<region>.<fqdn> |
1 Kräver ett certifikat med flera wildcard-ämnesalternativa namn. Flera jokerteckens-SAN på ett enda certifikat kanske inte stöds av alla offentliga certifikatutfärdare.
2 A *.appservice.<region>.<fqdn> wildcard-certifikat kan inte användas i stället för dessa tre certifikat (api.appservice.<region>.<fqdn>, ftp.appservice.<region>.<fqdn>och sso.appservice.<region>.<fqdn>. Appservice kräver uttryckligen användning av separata certifikat för dessa slutpunkter.
Nästa steg
Lär dig hur du genererar PKI-certifikat för distribution av Azure Stack Hub.