Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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 e possibilmente 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 aggiunta di valore.
Annotazioni
L'hub di Azure Stack per impostazione predefinita 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 tramite l'aggiunta di tale certificato all'archivio certificati locale. Non è possibile aggiungere o filtrare i 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 server TLS standard senza aggiunta del certificato).
Requisiti dei 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 - Microsoft Trusted Root Program.
- 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 altri dettagli, vedere Funzionalità compromesse o non disponibili nelle distribuzioni disconnesse.
- Quando si ruotano i certificati nelle build precedenti al 1903, i certificati devono essere emessi 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 pubblica o aziendale.
- 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 da un archivio certificati di Windows Server 2016).
- I file pfx del certificato devono avere un valore "Firma digitale" e "KeyEncipherment" nel 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 del soggetto consente di specificare nomi host aggiuntivi (siti Web, indirizzi IP, nomi comuni) da proteggere con un singolo certificato SSL.
Annotazioni
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 aspetto è 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).
Annotazioni
La presenza di autorità di certificazione intermedie nelle catene di trust di un certificato è supportata.
Certificati obbligatori
La tabella in questa sezione descrive i certificati PKI dell'endpoint pubblico dell'hub di Azure Stack necessari per le distribuzioni dell'hub di Azure Stack di 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>.<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.
Annotazioni
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 tale file di certificato in ogni cartella di distribuzione, come descritto nelle tabelle seguenti. La struttura di cartelle è predefinita nella macchina virtuale di distribuzione ed è disponibile in: C:\CloudDeployment\Setup\Certificates.
| Cartella distribuzione | Soggetto del certificato richiesto e nomi alternativi del soggetto (SAN) | Ambito (per regione) | Spazio dei nomi del sottodominio |
|---|---|---|---|
| Portale pubblico | portale.<area>.<Fqdn> | Portali | <area>.<Fqdn> |
| Portale di amministrazione | adminportal.<area>.<Fqdn> | Portali | <area>.<Fqdn> |
| Azure Resource Manager Pubblico | gestione.<area>.<Fqdn> | Azure Resource Manager | <area>.<Fqdn> |
| Amministrazione di Azure Resource Manager | adminmanagement.<area>.<Fqdn> | Azure Resource Manager | <area>.<Fqdn> |
| ACSBlob | *.Blob.<area>.<Fqdn> (Certificato SSL con caratteri jolly) |
Archiviazione BLOB | Blob.<area>.<Fqdn> |
| ACSTable | *.tavolo.<area>.<Fqdn> (Certificato SSL con caratteri jolly) |
Archiviazione di tabelle | tavolo.<area>.<Fqdn> |
| ACSQueue | *.coda.<area>.<Fqdn> (Certificato SSL con caratteri jolly) |
Archiviazione code | coda.<area>.<Fqdn> |
| KeyVault | *.volta.<area>.<Fqdn> (Certificato SSL con caratteri jolly) |
Key Vault (archivio di chiavi) | volta.<area>.<Fqdn> |
| KeyVaultInternal | *.adminvault.<area>.<Fqdn> (Certificato SSL con caratteri jolly) |
Insieme di credenziali delle chiavi interno | adminvault.<area>.<Fqdn> |
| Host dell'estensione amministrativa | *.adminhosting.<regione>.<fqdn> (certificati SSL con caratteri jolly) | Host dell'estensione amministrativa | adminhosting.<regione>.<fqdn> |
| Host dell'estensione pubblica | *.hosting.<region>.<fqdn> (certificati SSL con caratteri jolly) | Host dell'estensione pubblica | ospitare.<'area>.<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 distribuzione | Soggetto del certificato richiesto e nomi alternativi del soggetto (SAN) | Ambito (per regione) | Spazio dei nomi del sottodominio |
|---|---|---|---|
| ADFS | adfs. <area>.<Fqdn> (Certificato SSL) |
ADFS | <area>.<Fqdn> |
| Grafico | grafico. <area>.<Fqdn> (Certificato SSL) |
Grafico | <area>.<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.
Nella tabella seguente vengono descritti 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 regione) | Certificato | Nomi alternativi del certificato e soggetto obbligatori | Spazio dei nomi del sottodominio |
|---|---|---|---|
| Servizio app | Certificato SSL predefinito per il traffico Web | *.appservice. <area>.<Fqdn> *.scm.appservice. <area>.<Fqdn> *.sso.appservice. <area>.<Fqdn> (Certificato SSL con caratteri jollymultidominio 1) |
appservice. <area>.<Fqdn> scm.appservice. <area>.<Fqdn> |
| Servizio app | API (Interfaccia di Programmazione delle Applicazioni) | api.appservice.<area>.<fqdn> (Certificato SSL2) |
appservice. <area>.<Fqdn> scm.appservice. <area>.<Fqdn> |
| Servizio app | FTP | ftp.appservice.<area>.<fqdn> (Certificato SSL2) |
appservice. <area>.<Fqdn> scm.appservice. <area>.<Fqdn> |
| Servizio app | SSO (Autenticazione Unica) | sso.appservice. <area>.<Fqdn> (Certificato SSL2) |
appservice. <area>.<Fqdn> scm.appservice. <area>.<Fqdn> |
| Hub eventi | SSL | *.eventhub. <area>.<Fqdn> (Certificato SSL con caratteri jolly) |
eventhub. <area>.<Fqdn> |
| SQL, MySQL | SQL e MySQL | *.dbadapter. <area>.<Fqdn> (Certificato SSL con caratteri jolly) |
dbadapter. <area>.<Fqdn> |
1 Richiede un certificato con più nomi alternativi di soggetto con caratteri jolly. Più SAN con caratteri jolly in un singolo certificato potrebbero non essere supportati da tutte le autorità di certificazione pubbliche.
2 A *.appservice. <area>.<Non è possibile usare il certificato con caratteri jolly fqdn> al posto di questi tre certificati (api.appservice.<area>.<fqdn>, ftp.appservice. <area>.<fqdn> e sso.appservice. <area>.<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.