Domini in Frontdoor di Azure

  • Articolo

Un dominio rappresenta un nome di dominio personalizzato usato da Frontdoor di Azure per ricevere il traffico dell'applicazione. Frontdoor di Azure supporta l'aggiunta di tre tipi di nomi di dominio:

  • I sottodomini sono il tipo più comune di nome di dominio personalizzato. Un sottodominio di esempio è myapplication.contoso.com.
  • I domini Apex non contengono un sottodominio. Un dominio apex di esempio è contoso.com. Per altre informazioni sull'uso di domini apex con Frontdoor di Azure, vedere Domini Apex.
  • I domini con caratteri jolly consentono la ricezione del traffico per qualsiasi sottodominio. Un dominio con caratteri jolly di esempio è *.contoso.com. Per altre informazioni sull'uso di domini con caratteri jolly con Frontdoor di Azure, vedere Domini con caratteri jolly.

I domini vengono aggiunti al profilo frontdoor di Azure. È possibile usare un dominio in più route all'interno di un endpoint, se si usano percorsi diversi in ogni route.

Per informazioni su come aggiungere un dominio personalizzato al profilo frontdoor di Azure, vedere Configurare un dominio personalizzato in Frontdoor di Azure usando il portale di Azure.

Configurazione del DNS

Quando si aggiunge un dominio al profilo frontdoor di Azure, si configurano due record nel server DNS:

  • Un record TXT DNS, necessario per convalidare la proprietà del nome di dominio. Per altre informazioni sui record TXT DNS, vedere Convalida del dominio.
  • Un record CNAME DNS, che controlla il flusso del traffico Internet verso Frontdoor di Azure.

Suggerimento

È possibile aggiungere un nome di dominio al profilo frontdoor di Azure prima di apportare modifiche DNS. Questo approccio può essere utile se è necessario impostare la configurazione di Frontdoor di Azure insieme o se si dispone di un team separato che modifica i record DNS.

È anche possibile aggiungere il record TXT DNS per convalidare la proprietà del dominio prima di aggiungere il record CNAME per controllare il flusso del traffico. Questo approccio può essere utile per evitare di riscontrare tempi di inattività della migrazione se si dispone già di un'applicazione in produzione.

Convalida del dominio

Tutti i domini aggiunti a Frontdoor di Azure devono essere convalidati. La convalida consente di proteggere l'utente da errori di configurazione accidentali e consente anche di proteggere altri utenti dallo spoofing del dominio. In alcuni casi, i domini possono essere prevalidati da un altro servizio di Azure. In caso contrario, è necessario seguire il processo di convalida del dominio frontdoor di Azure per dimostrare la proprietà del nome di dominio.

  • I domini pre-convalidati di Azure sono domini convalidati da un altro servizio di Azure supportato. Se si esegue l'onboarding e la convalida di un dominio in un altro servizio di Azure e quindi si configura Frontdoor di Azure in un secondo momento, è possibile usare un dominio prevalidato. Non è necessario convalidare il dominio tramite Frontdoor di Azure quando si usa questo tipo di dominio.

    Nota

    Frontdoor di Azure attualmente accetta solo domini pre-convalidati configurati con App Web statiche di Azure.

  • I domini non convalidati da Azure sono domini non convalidati da un servizio di Azure supportato. Questo tipo di dominio può essere ospitato con qualsiasi servizio DNS, incluso DNS di Azure, e richiede che la proprietà del dominio sia convalidata da Frontdoor di Azure.

Convalida del record TXT

Per convalidare un dominio, è necessario creare un record TXT DNS. Il nome del record TXT deve essere nel formato _dnsauth.{subdomain}. Frontdoor di Azure fornisce un valore univoco per il record TXT quando si inizia ad aggiungere il dominio a Frontdoor di Azure.

Si supponga, ad esempio, di voler usare il sottodominio myapplication.contoso.com personalizzato con Frontdoor di Azure. Prima di tutto, è necessario aggiungere il dominio al profilo frontdoor di Azure e notare il valore del record TXT che è necessario usare. È quindi necessario configurare un record DNS con le proprietà seguenti:

Proprietà valore
Nome record _dnsauth.myapplication
Valore record usare il valore fornito da Frontdoor di Azure
Durata (TTL) 1 ora

Dopo che il dominio è stato convalidato correttamente, è possibile eliminare in modo sicuro il record TXT dal server DNS.

Per altre informazioni sull'aggiunta di un record TXT DNS per un dominio personalizzato, vedere Configurare un dominio personalizzato in Frontdoor di Azure usando il portale di Azure.

Stati di convalida del dominio

Nella tabella seguente sono elencati gli stati di convalida che un dominio potrebbe mostrare.

Stato di convalida del dominio Descrizione e azioni
Invio Viene creato il dominio personalizzato.

Attendere che la risorsa di dominio sia pronta.
In sospeso Il valore del record TXT DNS è stato generato e Frontdoor di Azure è pronto per aggiungere il record TXT DNS.

Aggiungere il record TXT DNS al provider DNS e attendere il completamento della convalida. Se lo stato rimane In sospeso anche dopo l'aggiornamento del record TXT con il provider DNS, selezionare Rigenera per aggiornare il record TXT e quindi aggiungere nuovamente il record TXT al provider DNS.
Riconvalida in sospeso Il certificato gestito è inferiore a 45 giorni dalla scadenza.

Se è già presente un record CNAME che punta all'endpoint frontdoor di Azure, non è necessaria alcuna azione per il rinnovo del certificato. Se il dominio personalizzato punta a un altro record CNAME, selezionare lo stato Di rivalutazione in sospeso e quindi selezionareRigenera nella pagina Convalidare il dominio personalizzato. Infine, selezionare Aggiungi se si usa DNS di Azure o aggiungere manualmente il record TXT con la gestione DNS del proprio provider DNS.
Aggiornamento del token di convalida Un dominio passa a uno stato Di aggiornamento del token di convalida per un breve periodo dopo che è stato selezionato il pulsante Rigenera . Dopo l'emissione di un nuovo valore di record TXT, lo stato diventa In sospeso.
Non è necessaria alcuna azione.
Approvato Il dominio è stato convalidato correttamente e Frontdoor di Azure può accettare il traffico che usa questo dominio.

Non è necessaria alcuna azione.
Rifiutato Il provider o l'autorità di certificazione ha rifiutato il rilascio per il certificato gestito. Ad esempio, il nome di dominio potrebbe non essere valido.

Selezionare il collegamento Rifiutato e quindi rigenerare nella pagina Convalida il dominio personalizzato, come illustrato negli screenshot seguenti di questa tabella. Selezionare quindi Aggiungi per aggiungere il record TXT nel provider DNS.
Timeout Il record TXT non è stato aggiunto al provider DNS entro sette giorni o è stato aggiunto un record TXT DNS non valido.

Selezionare il collegamento Timeout e quindi rigenerarenella pagina Convalida il dominio personalizzato. Selezionare quindi Aggiungi per aggiungere un nuovo record TXT al provider DNS. Assicurarsi di usare il valore aggiornato.
Errore interno Si è verificato un errore sconosciuto.

Ripetere la convalida selezionando il pulsante Aggiorna o Rigenera . Se si verificano ancora problemi, inviare una richiesta di supporto a supporto tecnico di Azure.

Nota

  • Il valore TTL predefinito per i record TXT è 1 ora. Quando è necessario rigenerare il record TXT per la riconvalida, prestare attenzione al TTL per il record TXT precedente. Se non scade, la convalida avrà esito negativo fino alla scadenza del record TXT precedente.
  • Se il pulsante Rigenera non funziona, eliminare e ricreare il dominio.
  • Se lo stato del dominio non riflette come previsto, selezionare il pulsante Aggiorna .

HTTPS per domini personalizzati

Usando il protocollo HTTPS nel dominio personalizzato, assicurarsi che i dati sensibili vengano recapitati in modo sicuro con la crittografia TLS/SSL quando vengono inviati attraverso Internet. Quando un client, come un Web browser, è connesso a un sito Web tramite HTTPS, il client convalida il certificato di sicurezza del sito Web e verifica che sia stato emesso da un'autorità di certificazione legittima. Questo processo offre sicurezza e protezione delle applicazioni Web da attacchi.

Frontdoor di Azure supporta l'uso di HTTPS con i propri domini e esegue l'offload della gestione dei certificati TLS (Transport Layer Security) dai server di origine. Quando si usano domini personalizzati, è possibile usare i certificati TLS gestiti da Azure (scelta consigliata) oppure è possibile acquistare e usare i propri certificati TLS.

Per altre informazioni sul funzionamento di Frontdoor di Azure con TLS, vedere TLS end-to-end con Frontdoor di Azure.

Certificati TLS gestiti da Frontdoor di Azure

Frontdoor di Azure può gestire automaticamente i certificati TLS per i sottodomini e i domini apex. Quando si usano certificati gestiti, non è necessario creare chiavi o richieste di firma del certificato e non è necessario caricare, archiviare o installare i certificati. Inoltre, Frontdoor di Azure può ruotare automaticamente (rinnovare) i certificati gestiti senza alcun intervento umano. Questo processo evita tempi di inattività causati da un errore durante il rinnovo dei certificati TLS.

Il processo di generazione, emissione e installazione di un certificato TLS gestito può richiedere da diversi minuti a un'ora per il completamento e occasionalmente può richiedere più tempo.

Nota

I certificati gestiti di Frontdoor di Azure (Standard e Premium) vengono ruotati automaticamente se il record CNAME del dominio punta direttamente a un endpoint frontdoor o punta indirettamente a un endpoint Gestione traffico. In caso contrario, è necessario convalidare nuovamente la proprietà del dominio per ruotare i certificati.

Tipi di dominio

La tabella seguente riepiloga le funzionalità disponibili con i certificati TLS gestiti quando si usano diversi tipi di domini:

Considerazione Sottodominio Dominio Apex Dominio con caratteri jolly
Certificati TLS gestiti disponibili Sì Sì No
I certificati TLS gestiti vengono ruotati automaticamente Sì Vedi di seguito No

Quando si usano i certificati TLS gestiti da Frontdoor di Azure con dominipex, la rotazione automatica dei certificati potrebbe richiedere di riconvalidare la proprietà del dominio. Per altre informazioni, vedere Domini Apex in Frontdoor di Azure.

Rilascio di certificati gestiti

I certificati di Frontdoor di Azure vengono emessi dall'autorità di certificazione partner DigiCert. Per alcuni domini, è necessario consentire in modo esplicito DigiCert come autorità di certificazione creando un record di dominio CAA con il valore: 0 issue digicert.com.

Azure gestisce completamente i certificati per conto dell'utente, in modo che qualsiasi aspetto del certificato gestito, incluso l'emittente radice, possa cambiare in qualsiasi momento. Queste modifiche sono esterne al controllo. Assicurarsi di evitare dipendenze difficili da qualsiasi aspetto di un certificato gestito, ad esempio la verifica dell'identificazione personale del certificato o l'aggiunta al certificato gestito o a qualsiasi parte della gerarchia di certificati. Se è necessario aggiungere certificati, è consigliabile usare un certificato TLS gestito dal cliente, come illustrato nella sezione successiva.

Certificati TLS gestiti dal cliente

In alcuni casi, potrebbe essere necessario fornire certificati TLS personalizzati. Gli scenari comuni per fornire certificati personalizzati includono:

  • L'organizzazione richiede l'uso di certificati rilasciati da un'autorità di certificazione specifica.
  • Si vuole che Azure Key Vault rilasci il certificato usando un'autorità di certificazione partner.
  • È necessario usare un certificato TLS riconosciuto da un'applicazione client.
  • È necessario usare lo stesso certificato TLS in più sistemi.
  • Si usano domini con caratteri jolly. Frontdoor di Azure non fornisce certificati gestiti per i domini con caratteri jolly.

Nota

  • A partire da settembre 2023, Frontdoor di Azure supporta Bring Your Own Certificates (BYOC) per la convalida della proprietà del dominio. Frontdoor approva la proprietà del dominio se il nome del certificato (CN) o il nome alternativo soggetto (SAN) del certificato corrisponde al dominio personalizzato. Se si seleziona il certificato gestito di Azure, la convalida del dominio usa il record TXT DNS.
  • Per i domini personalizzati creati prima della convalida basata su BYOC e lo stato di convalida del dominio non è Approvato, è necessario attivare l'approvazione automatica della convalida della proprietà del dominio selezionando lo stato di convalida e facendo clic sul pulsante Revalidate nel portale. Se si usa lo strumento da riga di comando, è possibile attivare la convalida del dominio inviando una richiesta PATCH vuota all'API di dominio.

Requisiti del certificato

Per usare il certificato con Frontdoor di Azure, deve soddisfare i requisiti seguenti:

  • Catena di certificati completa: 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. La CA radice deve far parte dell'elenco ca attendibile Microsoft. Se viene presentato un certificato senza catena completa, le richieste che coinvolgono tale certificato non funzioneranno necessariamente come previsto.
  • Nome comune: il nome comune (CN) del certificato deve corrispondere al dominio configurato in Frontdoor di Azure.
  • Algoritmo: Frontdoor di Azure non supporta i certificati con algoritmi di crittografia a curva ellittica (EC).
  • Tipo di file (contenuto): il certificato deve essere caricato nell'insieme di credenziali delle chiavi da un file PFX, che usa il application/x-pkcs12 tipo di contenuto.

Importare un certificato in Azure Key Vault

Prima di poterli usare con Frontdoor di Azure, è necessario importare certificati TLS personalizzati in Azure Key Vault. Per informazioni su come importare un certificato in un insieme di credenziali delle chiavi, vedere Esercitazione: Importare un certificato in Azure Key Vault.

L'insieme di credenziali delle chiavi deve trovarsi nella stessa sottoscrizione di Azure del profilo frontdoor di Azure.

Avviso

Frontdoor di Azure supporta solo gli insiemi di credenziali delle chiavi nella stessa sottoscrizione del profilo frontdoor. La scelta di un insieme di credenziali delle chiavi in una sottoscrizione diversa rispetto al profilo frontdoor di Azure genererà un errore.

I certificati devono essere caricati come oggetto certificato , anziché come segreto.

Concedere l'accesso a Frontdoor di Azure

Frontdoor di Azure deve accedere all'insieme di credenziali delle chiavi per leggere il certificato. È necessario configurare sia il firewall di rete dell'insieme di credenziali delle chiavi che il controllo di accesso dell'insieme di credenziali.

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.

Esistono due modi per configurare il controllo di accesso nell'insieme di credenziali delle chiavi:

  • Frontdoor di Azure può usare un'identità gestita per accedere all'insieme di credenziali delle chiavi. È possibile usare questo approccio quando l'insieme di credenziali delle chiavi usa l'autenticazione Microsoft Entra. Per altre informazioni, vedere Usare le identità gestite con Frontdoor di Azure Standard/Premium.
  • In alternativa, è possibile concedere all'entità servizio di Frontdoor di Azure l'accesso all'insieme di credenziali delle chiavi. È possibile usare questo approccio quando si usano i criteri di accesso all'insieme di credenziali.

Aggiungere il certificato personalizzato a Frontdoor di Azure

Dopo aver importato il certificato in un insieme di credenziali delle chiavi, creare una risorsa privata di Frontdoor di Azure, ovvero un riferimento al certificato aggiunto all'insieme di credenziali delle chiavi.

Configurare quindi il dominio per l'uso del segreto frontdoor di Azure per il certificato TLS.

Per una procedura guidata di questi passaggi, vedere Configurare HTTPS in un dominio personalizzato di Frontdoor di Azure usando il portale di Azure.

Passare da un tipo di certificato all'altro

È possibile modificare un dominio tra l'uso di un certificato gestito da Frontdoor di Azure e un certificato gestito dall'utente.

  • La distribuzione del nuovo certificato può richiedere fino a un'ora quando si passa da un tipo di certificato all'altro.
  • Se lo stato del dominio è Approvato, il passaggio del tipo di certificato tra un certificato gestito dall'utente e un certificato gestito non causerà tempi di inattività.
  • Quando si passa a un certificato gestito, Frontdoor di Azure continua a usare il certificato precedente finché la proprietà del dominio non viene riconvalidata e lo stato del dominio diventa Approvato.
  • Se si passa da BYOC al certificato gestito, è necessaria la riconvalida del dominio. Se si passa dal certificato gestito a BYOC, non è necessario riconvalidare il dominio.

Rinnovo dei certificati

Rinnovare i certificati gestiti da Frontdoor di Azure

Per la maggior parte dei domini personalizzati, Frontdoor di Azure rinnova automaticamente (ruota) i certificati gestiti quando sono prossimi alla scadenza e non è necessario eseguire alcuna operazione.

Tuttavia, Frontdoor di Azure non ruota automaticamente i certificati negli scenari seguenti:

  • Il record CNAME del dominio personalizzato punta a un record DNS diverso dal dominio dell'endpoint di Frontdoor di Azure.
  • Il dominio personalizzato punta all'endpoint frontdoor di Azure tramite una catena. Ad esempio, se il record DNS punta a Gestione traffico di Azure, che a sua volta si risolve in Frontdoor di Azure, la catena CNAME è contoso.com CNAME in contoso.trafficmanager.net CNAME in contoso.z01.azurefd.net. Frontdoor di Azure non è in grado di verificare l'intera catena.
  • Il dominio personalizzato usa un record A. È consigliabile usare sempre un record CNAME per puntare a Frontdoor di Azure.
  • Il dominio personalizzato è un dominiopex e usa CNAME flattening.

Se uno degli scenari precedenti si applica al dominio personalizzato, 45 giorni prima della scadenza del certificato gestito, lo stato di convalida del dominio diventa in sospeso. Lo stato di riconvalida in sospeso indica che è necessario creare un nuovo record TXT DNS per riconvalidare la proprietà del dominio.

Nota

I record TXT DNS scadono dopo sette giorni. Se in precedenza è stato aggiunto un record TXT di convalida del dominio al server DNS, è necessario sostituirlo con un nuovo record TXT. Assicurarsi di usare il nuovo valore. In caso contrario, il processo di convalida del dominio avrà esito negativo.

Se il dominio non può essere convalidato, lo stato di convalida del dominio diventa Rifiutato. Questo stato indica che l'autorità di certificazione ha rifiutato la richiesta di riemissione di un certificato gestito.

Per altre informazioni sugli stati di convalida del dominio, vedere Stati di convalida del dominio.

Rinnovare i certificati gestiti da Azure per i domini prevalidati da altri servizi di Azure

I certificati gestiti da Azure vengono ruotati automaticamente dal servizio di Azure che convalida il dominio.

Rinnovare i certificati TLS gestiti dal cliente

Quando si aggiorna il certificato nell'insieme di credenziali delle chiavi, Frontdoor di Azure può rilevare e usare automaticamente il certificato aggiornato. Per consentire il funzionamento di questa funzionalità, impostare la versione del segreto su "Latest" quando si configura il certificato in Frontdoor di Azure.

Se si seleziona una versione specifica del certificato, è necessario selezionare nuovamente la nuova versione manualmente quando si aggiorna il certificato.

La distribuzione automatica della nuova versione del certificato/segreto richiede fino a 72 ore.

Se si vuole modificare la versione del segreto da 'Latest' a una versione specificata o viceversa, aggiungere un nuovo certificato.

Criteri di sicurezza

È possibile usare web application firewall (WAF) di Frontdoor di Azure per analizzare le richieste all'applicazione per individuare le minacce e applicare altri requisiti di sicurezza.

Per usare WAF con un dominio personalizzato, usare una risorsa dei criteri di sicurezza di Frontdoor di Azure. Un criterio di sicurezza associa un dominio a un criterio WAF. Facoltativamente, è possibile creare più criteri di sicurezza in modo da poter usare criteri WAF diversi con domini diversi.

Passaggi successivi