Configurare HTTPS per un dominio personalizzato di Frontdoor (classico)
Importante
Frontdoor di Azure (versione classica) verrà ritirato il 31 marzo 2027. Per evitare interruzioni del servizio, è importante eseguire la migrazione dei profili frontdoor di Azure (versione classica) al livello Frontdoor di Azure Standard o Premium entro marzo 2027. Per altre informazioni, vedere Ritiro di Frontdoor di Azure (versione classica).
Questo articolo illustra come abilitare il protocollo HTTPS per un dominio personalizzato associato alla frontdoor (versione classica) nella sezione host front-end. Usando il protocollo HTTPS nel dominio personalizzato , ad esempio https://www.contoso.com, si garantisce che i dati sensibili vengano recapitati in modo sicuro tramite la crittografia TLS/SSL quando vengono inviati attraverso Internet. Quando il Web browser è connesso a un sito Web tramite HTTPS, convalida il certificato di sicurezza del sito Web e verifica se rilasciato da un'autorità di certificazione legittima. Questo processo offre sicurezza e protegge le applicazioni Web da attacchi dannosi.
Il servizio Frontdoor di Azure supporta HTTPS per un nome host predefinito della frontdoor, per impostazione predefinita. Ad esempio, se si crea una frontdoor (ad esempio https://contoso.azurefd.net), HTTPS viene abilitato automaticamente per le richieste effettuate a https://contoso.azurefd.net. Tuttavia, dopo aver eseguito l'onboarding del dominio personalizzato 'www.contoso.com' è necessario abilitare anche HTTPS per questo host front-end.
Di seguito sono riportati alcuni attributi chiave della funzionalità HTTPS personalizzato.
Nessun costo aggiuntivo: non sono previsti costi per l'acquisizione o il rinnovo dei certificati né costi aggiuntivi per il traffico HTTPS.
Abilitazione semplice: il provisioning è disponibile con un unico clic nel portale Azure. È possibile anche usare l'API REST o altri strumenti per sviluppatori per abilitare la funzionalità.
Disponibilità di una gestione completa dei certificati: tutta la fase di acquisizione e gestione dei certificati viene gestita automaticamente. Il provisioning e il rinnovo dei certificati vengono effettuati automaticamente prima della scadenza, eliminando i rischi di interruzione del servizio dovuti alla scadenza di un certificato.
In questa esercitazione apprenderai a:
- Abilitare il protocollo HTTPS nel dominio personalizzato
- Usare un certificato gestito dal servizio Frontdoor di Azure
- Usare il certificato personale, vale a dire un certificato TLS/SSL personalizzato
- Convalidare il dominio
- Disabilitare il protocollo HTTPS nel dominio personalizzato
Nota
È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.
Prerequisiti
Prima di poter completare i passaggi di questa esercitazione, è necessario creare una frontdoor ed eseguire l'onboarding di almeno un dominio personalizzato. Per altre informazioni, vedere Esercitazione: Aggiungere un dominio personalizzato alla frontdoor.
Certificati TLS/SSL
Per abilitare il protocollo HTTPS per la distribuzione sicura del contenuto in un dominio personalizzato frontdoor (classico), è necessario usare un certificato TLS/SSL. È possibile scegliere di usare un certificato che viene gestito da Frontdoor di Azure o usare il proprio certificato.
Opzione 1 (predefinita): Usare un certificato gestito da Frontdoor
Quando si usa un certificato gestito da Frontdoor di Azure, la funzionalità HTTPS può essere attivata con alcune modifiche all'impostazione. Le attività di gestione dei certificati, come l'acquisizione e il rinnovo, vengono interamente gestite dal servizio Frontdoor di Azure. Dopo l'abilitazione della funzionalità, il processo viene avviato immediatamente. Se il dominio personalizzato è già mappato all'host front-end predefinito di Frontdoor ({hostname}.azurefd.net), non sono necessarie altre azioni. Frontdoor elabora i passaggi e completa automaticamente la richiesta. Se il dominio personalizzato è mappato in altro modo, invece, è necessario convalidare la proprietà del dominio tramite posta elettronica.
Per abilitare il protocollo HTTPS in un dominio personalizzato, seguire questa procedura:
Nel portale di Azure passare al profilo di Frontdoor.
Nell'elenco degli host front-end, selezionare il dominio personalizzato per cui si vuole abilitare HTTPS.
Nella sezione HTTPS dominio personalizzato selezionare Abilitato e selezionare Frontdoor gestito come origine del certificato.
Seleziona Salva.
Continuare a Convalidare il dominio.
Nota
- Per i certificati gestiti da Frontdoor di Azure, viene applicato il limite di 64 caratteri di DigiCert. Se il limite viene superato, la convalida non riuscirà.
- L'abilitazione di HTTPS tramite il certificato gestito di Frontdoor non è supportata per i domini apex/root (ad esempio: contoso.com). È possibile usare il proprio certificato per questo scenario. Per altri dettagli, continuare con l'opzione 2.
Opzione 2: Usare il certificato personale
Per abilitare la funzionalità HTTPS, è possibile usare un certificato personale. Questo processo avviene tramite un'integrazione con Azure Key Vault, che consente di archiviare i certificati in modo sicuro. Frontdoor di Azure usa questo meccanismo sicuro per ottenere il certificato e richiede alcuni passaggi aggiuntivi. Quando si crea il certificato TLS/SSL, è necessario creare una catena di certificati completa con un'autorità di certificazione (CA) consentita che fa parte dell'elenco ca attendibile Microsoft. Se si usa una CA non consentita, la richiesta viene rifiutata. Se viene presentato un certificato senza catena completa, le richieste che coinvolgono tale certificato non funzioneranno necessariamente come previsto.
Preparare l’insieme di credenziali delle chiavi di Azure e il certificato
È necessario avere un account dell'insieme di credenziali delle chiavi nella stessa sottoscrizione di Azure della frontdoor. Se non si ha un account dell'insieme di credenziali delle chiavi, crearne uno.
Avviso
Il servizio Frontdoor di Azure attualmente supporta solo account Key Vault nella stessa sottoscrizione della configurazione della frontdoor. La scelta di un insieme di credenziali delle chiavi in una sottoscrizione diversa da quella della frontdoor genererà un errore.
Se l'insieme di credenziali delle chiavi ha restrizioni di accesso alla rete abilitate, è necessario configurare l'insieme di credenziali delle chiavi per consentire ai servizi Microsoft attendibili di ignorare il firewall.
L'insieme di credenziali delle chiavi deve essere configurato per l'uso del modello di autorizzazione dei criteri di accesso di Key Vault.
Se si ha già un certificato, è possibile caricarlo direttamente nell'insieme di credenziali delle chiavi. In caso contrario, creare un nuovo certificato direttamente tramite Azure Key Vault da una delle autorità di certificazione partner integrate con Azure Key Vault. Caricare il certificato come oggetto certificato, anziché come segreto.
Nota
Frontdoor non supporta i certificati con algoritmi di crittografia a curva ellittica (EC). Il certificato deve avere una catena di certificati completa con certificati foglia e intermedi e la CA radice deve far parte dell'elenco ca attendibile Microsoft.
Registrare il servizio Frontdoor di Azure
Registrare l'entità servizio per Frontdoor di Azure come app nell'ID Microsoft Entra usando Azure PowerShell o l'interfaccia della riga di comando di Azure.
Nota
- Questa azione richiede almeno le autorizzazioni del ruolo Application Amministrazione istrator in Microsoft Entra ID. La registrazione deve essere eseguita una sola volta per ogni tenant di Microsoft Entra.
- L'ID applicazione viene assegnato in modo specifico da Azure per Frontdoor di Azure (versione classica).
- Frontdoor di Azure (versione classica) ha un ID applicazione diverso rispetto al livello Frontdoor di Azure Standard/Premium.
- Il ruolo assegnato è solo per la sottoscrizione selezionata, a meno che non si definisci un ambito diverso.
Azure PowerShell
Se necessario, installare Azure PowerShell in PowerShell nel computer locale.
In PowerShell eseguire questo comando:
New-AzADServicePrincipal -ApplicationId "ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037"
Interfaccia della riga di comando di Azure
Se necessario, installare l'interfaccia della riga di comando di Azure nel computer locale.
Nell'interfaccia della riga di comando eseguire il comando seguente:
az ad sp create --id ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037
Concedere al servizio Frontdoor di Azure l'accesso all'insieme di credenziali delle chiavi
Concedere al servizio Frontdoor di Azure l'autorizzazione ad accedere ai certificati nell'account Azure Key Vault.
Nell'account dell'insieme di credenziali delle chiavi selezionare Criteri di accesso.
Selezionare Crea per creare un nuovo criterio di accesso.
In Autorizzazioni dei segreti selezionare Recupera per consentire a Frontdoor di recuperare il certificato.
In Autorizzazioni del certificato selezionare Recupera per consentire a Frontdoor di recuperare il certificato.
In Seleziona un'entità cercare ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037 e selezionare Microsoft.Azure.Frontdoor. Selezionare Avanti.
In Applicazione selezionare Avanti.
In Rivedi e crea selezionare Crea.
Nota
Se l'insieme di credenziali delle chiavi è protetto con restrizioni di accesso alla rete, assicurarsi di consentire all'servizi Microsoft attendibile di accedere all'insieme di credenziali delle chiavi.
Frontdoor di Azure può ora accedere a questo insieme di credenziali delle chiavi e ai certificati contenuti.
Selezionare il certificato per Frontdoor di Azure da distribuire
Tornare alla frontdoor nel portale.
Nell'elenco di domini personalizzati selezionare il dominio personalizzato per cui si vuole abilitare il protocollo HTTPS.
Viene visualizzata la pagina Dominio personalizzato.
In Tipo di gestione dei certificati selezionare Usa certificato personale.
Il servizio Frontdoor di Azure richiede che la sottoscrizione dell'account Key Vault sia identica a quella della frontdoor. Selezionare un insieme di credenziali delle chiavi, un segreto e una versione del segreto.
Il servizio Frontdoor di Azure elenca le informazioni seguenti:
- Account Key Vault per l'ID sottoscrizione.
- Segreti nell'insieme di credenziali delle chiavi selezionato.
- Versioni del segreto disponibili.
Nota
Per ruotare automaticamente il certificato alla versione più recente quando è disponibile una versione più recente del certificato nel Key Vault, impostare la versione segreta su "Ultima". Se è stata selezionata una versione specifica, è necessario riselezionare manualmente la nuova versione per la rotazione del certificato. Sono necessarie 72-96 ore per la distribuzione della nuova versione del certificato/segreto.
Avviso
Si tratta di un avviso portale di Azure solo. È necessario configurare l'entità servizio per avere un'autorizzazione GET per Key Vault. Per consentire a un utente di visualizzare il certificato nell'elenco a discesa del portale, l'account utente deve disporre delle autorizzazioni LIST e GET per Key Vault. Se un utente non dispone di queste autorizzazioni, verrà visualizzato un messaggio di errore inaccessibile nel portale. Un messaggio di errore inaccessibile non ha alcun impatto sulla rotazione automatica del certificato o su alcuna funzione HTTPS. Non sono necessarie azioni per questo messaggio di errore se non si intende apportare modifiche al certificato o alla versione. Per modificare le informazioni in questa pagina, vedere Fornire l'autorizzazione a Key Vault per aggiungere l'account all'autorizzazione LIST e GET dell'insieme di credenziali delle chiavi.
Quando si usa un certificato proprio, la convalida del dominio non è necessaria. Continuare con Attendere la propagazione.
Convalidare il dominio
Se si dispone già di un dominio personalizzato in uso che viene mappato all'endpoint personalizzato con un record CNAME o si usa il proprio certificato, continuare con Il dominio personalizzato viene mappato a Frontdoor. In caso contrario, se la voce di record CNAME per il dominio non esiste più o contiene il sottodominio afdverify, continuare con il dominio personalizzato non viene mappato alla frontdoor.
Il dominio personalizzato è mappato alla frontdoor con un record CNAME
Quando viene aggiunto un dominio personalizzato agli host front-end della frontdoor, nella tabella DNS del registrar viene creato un record CNAME per mapparlo al nome host .azurefd.net predefinito della frontdoor. Se il record CNAME esiste ancora e non contiene il sottodominio afdverify, l'autorità di certificazione DigiCert lo usa per convalidare automaticamente la proprietà del dominio personalizzato.
Se si usa il proprio certificato, la convalida del dominio non è necessaria.
Il record CNAME deve avere il formato seguente, dove Nome è il nome del dominio personalizzato e Valore è il nome host .azurefd.net predefinito della frontdoor:
| Nome | Type | Valore |
|---|---|---|
| <www.contoso.com> | CNAME | contoso.azurefd.net |
Per altre informazioni sui record CNAME, vedere Create the CNAME DNS record (Creare un record DNS CNAME).
Se il record CNAME è nel formato corretto, DigiCert verifica automaticamente il nome di dominio personalizzato e crea un certificato dedicato per il nome di dominio. DigitCert non invia un messaggio di posta elettronica di verifica e non è necessario approvare la richiesta. Il certificato è valido per un anno e autorenews prima della scadenza. Continuare con Attendere la propagazione.
La convalida automatica richiede in genere qualche minuto. Se il dominio non viene convalidato entro un'ora, aprire un ticket di supporto.
Nota
Se si ha un record di autorizzazione dell'autorità di certificazione (CAA, Certificate Authority Authorization) con il provider DNS, il record deve includere DigiCert come CA valida. Un record CAA consente ai proprietari di domini di indicare ai propri provider DNS le CA autorizzate a emettere certificati per i loro domini. Se una CA riceve l'ordine di un certificato per un dominio dotato di record CAA ma la CA non è citata come autorità emittente autorizzata in tale record, non deve emettere il certificato per il dominio o il sottodominio. Per informazioni sulla gestione dei record CAA, vedere l'argomento relativo alla gestione dei record CAA. Per informazioni su uno strumento per i record CAA, vedere Strumento di supporto per record CAA.
Il dominio personalizzato non è mappato alla frontdoor
Se la voce di record CNAME per l'endpoint non esiste più o contiene il sottodominio afdverify, seguire le istruzioni riportate in questo passaggio.
Dopo l'abilitazione di HTTPS nel dominio personalizzato, la CA DigiCert convalida la proprietà del dominio contattandone il registrante in base alle informazioni sul registrante stesso in WHOIS. Per il contatto viene usato l'indirizzo di posta elettronica (impostazione predefinita) o il numero di telefono riportato nella registrazione WHOIS. È necessario completare la convalida del dominio prima che HTTPS sia attivo nel dominio personalizzato. Il dominio deve essere approvato entro sei giorni lavorativi. Le richieste non approvate entro sei giorni lavorativi vengono annullate automaticamente. La convalida del dominio DigiCert funziona a livello di sottodominio. È necessario dimostrare la proprietà di ogni sottodominio separatamente.
DigiCert invia anche un messaggio di posta elettronica di verifica ad altri indirizzi di posta elettronica. Se le informazioni del registrante WHOIS sono private, verificare di poter eseguire l'approvazione direttamente da uno degli indirizzi seguenti:
<admin@your-domain-name.com> administrator@<your-domain-name.com> webmaster@<your-domain-name.com> hostmaster@your-domain-name.com< your-domain-name.com postmaster@<your-domain-name.com>>
Entro pochi minuti si dovrebbe ricevere un messaggio di posta elettronica simile all'esempio seguente, in cui viene chiesto di approvare la richiesta. Se si usa un filtro di posta indesiderata, aggiungerlo no-reply@digitalcertvalidation.com all'elenco consenti. In alcuni scenari, DigiCert potrebbe non essere in grado di recuperare i contatti del dominio dalle informazioni del registrante WHOIS per inviare un messaggio di posta elettronica. Se non si riceve un messaggio di posta elettronica entro 24 ore, contattare il supporto tecnico Microsoft.
Quando si seleziona il collegamento di approvazione, si viene indirizzati a un modulo di approvazione online. Seguire le istruzioni nel modulo. Sono disponibili due opzioni di verifica:
È possibile approvare tutti gli ordini futuri effettuati con lo stesso account per lo stesso dominio radice, ad esempio contoso.com. Questo approccio è consigliato se si prevede di aggiungere altri domini personalizzati per lo stesso dominio radice.
È possibile approvare solo il nome host specifico usato in questa richiesta. Per le richieste successive è necessaria un'approvazione aggiuntiva.
Dopo l'approvazione, DigiCert completa la creazione del certificato per il nome di dominio personalizzato. Il certificato è valido per un anno e ottiene l'autorenew prima della scadenza.
Attendere la propagazione
Dopo la convalida del nome di dominio, per l'attivazione della funzionalità HTTPS per il dominio personalizzato possono essere necessarie 6-8 ore. Al termine del processo, lo stato HTTPS personalizzato nel portale di Azure viene impostato su Abilitato e i quattro passaggi nella finestra di dialogo del dominio personalizzato sono contrassegnati come completati. Il dominio personalizzato è ora pronto per l'uso di HTTPS.
Avanzamento dell'operazione
La tabella seguente illustra l'avanzamento dell'operazione per l'abilitazione di HTTPS. Dopo l'abilitazione di HTTPS, i quattro passaggi dell'operazione vengono visualizzati nella finestra di dialogo del dominio personalizzato. Man mano che ogni passaggio diventa attivo, vengono visualizzati più dettagli di passaggi secondari nel passaggio man mano che procede. Non si verificano tutti questi passaggi secondari. Al completamento di un passaggio, accanto viene visualizzato un segno di spunta verde.
| Passaggio dell'operazione | Dettagli del passaggio secondario dell'operazione |
|---|---|
| 1. Invio della richiesta | Invio della richiesta |
| La richiesta HTTPS è in fase di invio. | |
| La richiesta HTTPS è stata inviata. | |
| 2. Convalida del dominio | Il dominio viene convalidato automaticamente se è CNAME mappato all'host front-end predefinito .azurefd.net front-end della frontdoor. In caso contrario, una richiesta di verifica viene inviata al messaggio di posta elettronica elencato nel record di registrazione del dominio (registrante WHOIS). Verificare il dominio non appena possibile. |
| La proprietà del dominio è stata convalidata. | |
| La richiesta di convalida della proprietà del dominio è scaduta (probabilmente perché il cliente non ha risposto entro 6 giorni). HTTPS non verrà abilitato nel dominio. * | |
| Richiesta di convalida della proprietà del dominio rifiutata dal cliente. HTTPS non verrà abilitato nel dominio. * | |
| 3. Provisioning dei certificati | L'autorità di certificazione sta per rilasciare il certificato necessario per abilitare HTTPS nel dominio. |
| Il certificato è stato rilasciato ed è in fase di distribuzione per la frontdoor. Il completamento di questo processo può richiedere da alcuni minuti a un'ora. | |
| Il certificato è stato distribuito per la frontdoor. | |
| 4. Completa | HTTPS è stato abilitato nel dominio. |
* Questo messaggio non viene visualizzato a meno che non si sia verificato un errore.
Se si verifica un errore prima dell'invio della richiesta, viene visualizzato il messaggio di errore seguente:
We encountered an unexpected error while processing your HTTPS request. Please try again and contact support if the issue persists.
Domande frequenti
Chi è il provider di certificati e quale tipo di certificato viene usato?
Per il dominio personalizzato viene usato un certificato dedicato/singolo, fornito da Digicert.
Viene usata una configurazione TLS/SSL basata su IP o su SNI?
Il servizio Frontdoor di Azure usa SNI TLS/SSL.
Cosa accade se non si riceve il messaggio di verifica del dominio da DigiCert?
Se si dispone di una voce CNAME per il dominio personalizzato che punta direttamente al nome host dell'endpoint (e non si usa il nome del sottodominio afdverify), non si riceverà un messaggio di posta elettronica di verifica del dominio. La convalida viene eseguita automaticamente. In caso contrario, se non è disponibile alcuna voce CNAME e non è stato ricevuto alcun messaggio di posta elettronica entro 24 ore, contattare il supporto tecnico Microsoft.
L'uso di un certificato SAN è meno sicuro rispetto a un certificato dedicato?
Un certificato SAN applica gli stessi standard di crittografia e sicurezza di un certificato dedicato. Tutti i certificati TLS/SSL emessi usano l'algoritmo SHA-256 per la protezione avanzata dei server.
È necessario avere un record di autorizzazione dell'autorità di certificazione presso il provider DNS?
No, non è attualmente necessario un record di autorizzazione dell'autorità di certificazione. Se tuttavia se ne ha uno, deve includere DigiCert come CA valida.
Pulire le risorse
Nei passaggi precedenti è stato abilitato il protocollo HTTPS nel dominio personalizzato. Se non si vuole più usare il dominio personalizzato con HTTPS, è possibile disabilitare HTTPS seguendo questa procedura:
Disabilitare la funzionalità HTTPS
Nel portale di Azure passare alla configurazione del servizio Frontdoor di Azure.
Nell'elenco degli host front-end selezionare il dominio personalizzato per il quale si vuole disabilitare HTTPS.
Selezionare Disabilitato per disabilitare HTTPS, quindi selezionare Salva.
Attendere la propagazione
Per rendere effettiva la disabilitazione della funzionalità HTTPS per il dominio personalizzato possono essere necessarie 6-8 ore. Al termine del processo, lo stato HTTPS personalizzato nella portale di Azure viene impostato su Disabilitato e i tre passaggi dell'operazione nella finestra di dialogo del dominio personalizzato vengono contrassegnati come completi. Il dominio personalizzato non può più usare HTTPS.
Avanzamento dell'operazione
La tabella seguente illustra l'avanzamento dell'operazione per la disabilitazione di HTTPS. Al termine, i tre passaggi dell'operazione vengono visualizzati nella finestra di dialogo del dominio personalizzato. Man mano che ogni passaggio diventa attivo, vengono visualizzati altri dettagli nel passaggio. Al completamento di un passaggio, accanto viene visualizzato un segno di spunta verde.
| Avanzamento dell'operazione | Dettagli dell'operazione |
|---|---|
| 1. Invio della richiesta | Invio della richiesta |
| 2. Deprovisioning dei certificati | Eliminazione del certificato |
| 3. Completa | Il certificato è stato eliminato |
Passaggi successivi
Per informazioni su come configurare un criterio di filtro geografico per Frontdoor, continuare con l'esercitazione successiva.