Requisiti dei certificati di infrastruttura a chiave pubblica (PKI) dell'hub di Azure Stack
L'hub di Azure Stack ha una rete di infrastruttura pubblica usando indirizzi IP pubblici accessibili esternamente assegnati a un piccolo set di servizi dell'hub di Azure Stack ed eventualmente macchine virtuali tenant. I certificati PKI con i nomi DNS appropriati per questi endpoint dell'infrastruttura pubblica dell'hub di Azure Stack sono necessari durante la distribuzione dell'hub di Azure Stack. Questo articolo fornisce informazioni su:
- Requisiti dei certificati per l'hub di Azure Stack.
- Certificati obbligatori necessari per la distribuzione dell'hub di Azure Stack.
- Certificati facoltativi necessari per la distribuzione di provider di risorse con valore aggiunto.
Nota
Per impostazione predefinita, l'hub di Azure Stack usa anche i certificati emessi da un'autorità di certificazione integrata (CA) di Active Directory interna per l'autenticazione tra i nodi. Per convalidare il certificato, tutti i computer dell'infrastruttura dell'hub di Azure Stack considerano attendibile il certificato radice della CA interna aggiungendo tale certificato all'archivio certificati locale. Non è disponibile alcun blocco o filtro dei certificati nell'hub di Azure Stack. La san di ogni certificato server viene convalidata in base al nome di dominio completo della destinazione. Viene convalidata anche l'intera catena di attendibilità, insieme alla data di scadenza del certificato (autenticazione standard del server TLS senza aggiunta del certificato).
Requisiti per i certificati
L'elenco seguente descrive i requisiti generali di rilascio, sicurezza e formattazione dei certificati:
- I certificati devono essere rilasciati da un'autorità di certificazione interna o da un'autorità di certificazione pubblica. Se viene usata un'autorità di certificazione pubblica, deve essere inclusa nell'immagine del sistema operativo di base come parte del programma Microsoft Trusted Root Authority. Per l'elenco completo, vedere Elenco dei partecipanti - Programma radice attendibile Microsoft.
- L'infrastruttura dell'hub di Azure Stack deve avere accesso di rete al percorso dell'elenco di revoche di certificati (CRL) dell'autorità di certificazione pubblicato nel certificato. Questo CRL deve essere un endpoint HTTP. Nota: per le distribuzioni disconnesse, i certificati rilasciati da un'autorità di certificazione pubblica (CA) non sono supportati, se l'endpoint CRL non è accessibile. Per altre informazioni, vedere Funzionalità compromesse o non disponibili nelle distribuzioni disconnesse.
- Quando si ruotano i certificati nelle build precedenti al 1903, i certificati devono essere rilasciati dalla stessa autorità di certificazione interna usata per firmare i certificati forniti in fase di distribuzione o da qualsiasi autorità di certificazione pubblica precedente.
- Quando si ruotano i certificati per le build 1903 e successive, i certificati possono essere rilasciati da qualsiasi autorità di certificazione aziendale o pubblica.
- L'uso di certificati autofirmati non è supportato.
- Per la distribuzione e la rotazione, è possibile usare un singolo certificato che copre tutti gli spazi dei nomi nel nome soggetto del certificato e nel nome alternativo soggetto (SAN). In alternativa, è possibile usare singoli certificati per ognuno degli spazi dei nomi seguenti che i servizi dell'hub di Azure Stack che si prevede di usare richiedono. Entrambi gli approcci richiedono l'uso di caratteri jolly per gli endpoint in cui sono necessari, ad esempio KeyVault e KeyVaultInternal.
- L'algoritmo di firma del certificato non deve essere SHA1.
- Il formato del certificato deve essere PFX, perché per l'installazione dell'hub di Azure Stack sono necessarie sia le chiavi pubbliche che private. La chiave privata deve avere il set di attributi della chiave del computer locale.
- La crittografia PFX deve essere 3DES (questa crittografia è predefinita durante l'esportazione da un client Windows 10 o Windows Server 2016 archivio certificati).
- I file pfx del certificato devono avere un valore "Firma digitale" e "KeyEncipherment" nel relativo campo "Utilizzo chiavi".
- I file pfx del certificato devono avere i valori "Autenticazione server (1.3.6.1.5.5.7.3.1)" e "Autenticazione client (1.3.6.1.5.5.7.3.2)" nel campo "Utilizzo chiavi avanzato".
- Il campo "Rilasciato a:" del certificato non deve corrispondere al campo "Rilasciato da:".
- Le password per tutti i file pfx del certificato devono essere uguali al momento della distribuzione.
- La password del certificato pfx deve essere una password complessa. Prendere nota di questa password perché verrà usata come parametro di distribuzione. La password deve soddisfare i requisiti di complessità delle password seguenti:
- Lunghezza minima di otto caratteri.
- Almeno tre dei caratteri seguenti: lettera maiuscola, lettera minuscola, numeri da 0 a 9, caratteri speciali, carattere alfabetico non maiuscolo o minuscolo.
- Assicurarsi che i nomi dei soggetti e i nomi alternativi del soggetto nell'estensione del nome alternativo del soggetto (x509v3_config) corrispondano. Il campo nome alternativo soggetto consente di specificare nomi host aggiuntivi (siti Web, indirizzi IP, nomi comuni) da proteggere con un singolo certificato SSL.
Nota
I certificati autofirmati non sono supportati.
Quando si distribuisce l'hub di Azure Stack in modalità disconnessa, è consigliabile usare i certificati rilasciati da un'autorità di certificazione aziendale. Questo è importante perché i client che accedono agli endpoint dell'hub di Azure Stack devono essere in grado di contattare l'elenco di revoche di certificati (CRL).
Nota
È supportata la presenza di autorità di certificazione intermedie in una catena di trust di un certificato.
Certificati obbligatori
La tabella in questa sezione descrive i certificati PKI dell'hub di Azure Stack che sono necessari per le distribuzioni dell'hub di Azure Stack Microsoft Entra e AD FS. I requisiti dei certificati sono raggruppati per area e gli spazi dei nomi usati e i certificati necessari per ogni spazio dei nomi. La tabella descrive anche la cartella in cui il provider di soluzioni copia i diversi certificati per endpoint pubblico.
Sono necessari certificati con nomi DNS appropriati per ogni endpoint dell'infrastruttura pubblica dell'hub di Azure Stack. Il nome DNS di ogni endpoint è espresso nel formato:< prefisso>.<area> geografica.<fqdn>.
Per la distribuzione, i <valori di area> e <fqdn> devono corrispondere all'area e ai nomi di dominio esterni scelti per il sistema hub di Azure Stack. Ad esempio, se l'area è Redmond e il nome di dominio esterno è contoso.com, i nomi DNS avranno il prefisso> di formato.redmond.contoso.com<. I <valori del prefisso> vengono predesignati da Microsoft per descrivere l'endpoint protetto dal certificato. Inoltre, i <valori di prefisso> degli endpoint dell'infrastruttura esterna dipendono dal servizio hub di Azure Stack che usa l'endpoint specifico.
Per gli ambienti di produzione, è consigliabile generare singoli certificati per ogni endpoint e copiarli nella directory corrispondente. Per gli ambienti di sviluppo, i certificati possono essere forniti come un singolo certificato con caratteri jolly che copre tutti gli spazi dei nomi nei campi Soggetto e Nome alternativo soggetto (SAN) copiati in tutte le directory. Un singolo certificato che copre tutti gli endpoint e i servizi non è una procedura sicura, quindi è consigliabile usare questo metodo solo per lo sviluppo. Tenere presente che entrambe le opzioni richiedono l'uso di certificati con caratteri jolly per gli endpoint come acs e insiemi di credenziali delle chiavi dove sono richiesti.
Nota
Durante la distribuzione, è necessario copiare i certificati nella cartella di distribuzione corrispondente al provider di identità in cui si esegue la distribuzione (ID Microsoft Entra o AD FS). Se si usa un singolo certificato per tutti gli endpoint, è necessario copiare il file del certificato in ogni cartella di distribuzione, come descritto nelle tabelle seguenti. La struttura di cartelle è predefinita nella macchina virtuale di distribuzione e si trova in: C:\CloudDeployment\Setup\Certificates.
| Cartella di distribuzione | Soggetto del certificato e nome alternativo del soggetto richiesti | Ambito (per area) | Spazio dei nomi sottodominio |
|---|---|---|---|
| Portale pubblico | Portale.<area> geografica.<Fqdn> | Portali | <region>.<fqdn> |
| Portale di amministrazione | adminportal.<region>.<fqdn> | Portali | <region>.<fqdn> |
| Cartella pubblica di Azure Resource Manager | management.<region>.<fqdn> | Azure Resource Manager | <region>.<fqdn> |
| Amministrazione di Azure Resource Manager | adminmanagement.<region>.<fqdn> | Azure Resource Manager | <region>.<fqdn> |
| ACSBlob | *.Blob.<area> geografica.<Fqdn> (Certificato SSL con caratteri jolly) |
Archiviazione BLOB | blob.<region>.<fqdn> |
| ACSTable | *.tavolo.<area> geografica.<Fqdn> (Certificato SSL con caratteri jolly) |
Archiviazione tabelle | table.<region>.<fqdn> |
| ACSQueue | *.Coda.<area> geografica.<Fqdn> (Certificato SSL con caratteri jolly) |
Archiviazione code | queue.<region>.<fqdn> |
| Insieme di credenziali delle chiavi | *.volta.<area> geografica.<Fqdn> (Certificato SSL con caratteri jolly) |
Key Vault | vault.<region>.<fqdn> |
| KeyVaultInternal | *.adminvault.<area> geografica.<Fqdn> (Certificato SSL con caratteri jolly) |
Insieme di credenziali delle chiavi interno | adminvault.<region>.<fqdn> |
| Host estensione amministrazione | *.adminhosting.<area> geografica.<fqdn> (certificati SSL con caratteri jolly) | Host estensione amministrazione | adminhosting.<region>.<fqdn> |
| Host estensione pubblica | *.ospitare.<area> geografica.<fqdn> (certificati SSL con caratteri jolly) | Host estensione pubblica | ospitare.<area> geografica.<Fqdn> |
Se si distribuisce l'hub di Azure Stack usando la modalità di distribuzione Microsoft Entra, è sufficiente richiedere i certificati elencati nella tabella precedente. Tuttavia, se si distribuisce l'hub di Azure Stack usando la modalità di distribuzione AD FS, è necessario richiedere anche i certificati descritti nella tabella seguente:
| Cartella di distribuzione | Soggetto del certificato e nome alternativo del soggetto richiesti | Ambito (per area) | Spazio dei nomi sottodominio |
|---|---|---|---|
| AD FS | Adfs. <area> geografica.<Fqdn> (Certificato SSL) |
AD FS | <area> geografica.<Fqdn> |
| Grafico | Grafico. <area> geografica.<Fqdn> (Certificato SSL) |
Grafico | <area> geografica.<Fqdn> |
Importante
Tutti i certificati elencati in questa sezione devono avere la stessa password.
Certificati PaaS facoltativi
Se si prevede di distribuire i servizi PaaS dell'hub di Azure Stack (ad esempio SQL, MySQL, servizio app o Hub eventi) dopo la distribuzione e la configurazione dell'hub di Azure Stack, è necessario richiedere certificati aggiuntivi per coprire gli endpoint dei servizi PaaS.
Importante
I certificati usati per i provider di risorse devono avere la stessa autorità radice usata per gli endpoint globali dell'hub di Azure Stack.
La tabella seguente descrive gli endpoint e i certificati necessari per i provider di risorse. Non è necessario copiare questi certificati nella cartella di distribuzione dell'hub di Azure Stack. Questi certificati vengono invece forniti durante l'installazione del provider di risorse.
| Ambito (per area) | Certificato | Nomi alternativi del certificato e del soggetto richiesti | Spazio dei nomi sottodominio |
|---|---|---|---|
| Servizio app | Certificato SSL predefinito del traffico Web | *.appservice. <area> geografica.<Fqdn> *.scm.appservice. <area> geografica.<Fqdn> *.sso.appservice. <area> geografica.<Fqdn> (Certificato SSL con caratteri jollymultidominio 1) |
appservice. <area> geografica.<Fqdn> scm.appservice. <area> geografica.<Fqdn> |
| Servizio app | API | api.appservice. <area> geografica.<Fqdn> (Certificato SSL2) |
appservice. <area> geografica.<Fqdn> scm.appservice. <area> geografica.<Fqdn> |
| Servizio app | FTP | ftp.appservice. <area> geografica.<Fqdn> (Certificato SSL2) |
appservice. <area> geografica.<Fqdn> scm.appservice. <area> geografica.<Fqdn> |
| Servizio app | SSO | sso.appservice. <area> geografica.<Fqdn> (Certificato SSL2) |
appservice. <area> geografica.<Fqdn> scm.appservice. <area> geografica.<Fqdn> |
| Hub eventi | SSL | *.eventhub. <area> geografica.<Fqdn> (Certificato SSL con caratteri jolly) |
eventhub. <area> geografica.<Fqdn> |
| SQL, MySQL | SQL e MySQL | *.dbadapter. <area> geografica.<Fqdn> (Certificato SSL con caratteri jolly) |
dbadapter. <area> geografica.<Fqdn> |
1 Richiede un certificato con più nomi alternativi di soggetto con caratteri jolly. È possibile che più SAN con caratteri jolly in un singolo certificato non siano supportati da tutte le autorità di certificazione pubbliche.
2 A *.appservice. <area> geografica.<Non è possibile usare il certificato con caratteri jolly fqdn> al posto di questi tre certificati (api.appservice.<area> geografica.<fqdn>, ftp.appservice. <area> geografica.<fqdn> e sso.appservice. <area> geografica.<fqdn>. Il servizio app richiede in modo esplicito l'uso di certificati separati per questi endpoint.
Passaggi successivi
Informazioni su come generare certificati PKI per la distribuzione dell'hub di Azure Stack.