Panoramica della terminazione TLS e di TLS end-to-end con il gateway applicazione

Transport Layer Security (TLS), noto in precedenza come Secure Sockets Layer (SSL), è la tecnologia di sicurezza standard per stabilire un collegamento crittografato tra un server Web e un browser. Questo collegamento garantisce che tutti i dati passati tra il server Web e i browser rimangano privati e crittografati. Il gateway applicazione supporta sia la terminazione TLS nel gateway che la crittografia TLS end-to-end.

Importante

A partire dal 31 agosto 2025, tutti i client e i server back-end che interagiscono con il Gateway applicazione di Azure devono usare Transport Layer Security (TLS) 1.2 o versione successiva, perché il supporto per TLS 1.0 e 1.1 verrà sospeso.

Terminazione TLS

Il gateway applicazione supporta la terminazione TLS nel gateway, dopo la quale il traffico scorre generalmente non crittografato verso i server back-end. La terminazione TLS nel gateway applicazione offre numerosi vantaggi:

• Miglioramento delle prestazioni - L'operazione con l'impatto maggiore sulle prestazioni quando si esegue la decrittografia TLS è l'handshake iniziale. Per migliorare le prestazioni, il server che esegue la decrittografia memorizza nella cache gli ID di sessione TLS e gestisce i ticket della sessione TLS. Se questa operazione viene eseguita nel gateway applicazione, tutte le richieste dallo stesso client possono usare i valori memorizzati nella cache. Se viene eseguita nei server back-end, ogni volta che le richieste del client passano a un server diverso, il client deve ripetere l'autenticazione. L'uso di ticket TLS può aiutare a mitigare questo problema, ma non sono supportati da tutti i client e possono essere difficili da configurare e gestire.
• Utilizzo migliore dei server back-end - L'elaborazione SSL/TLS richiede un utilizzo intensivo della CPU, che aumenta con l'aumentare delle dimensioni delle chiavi. La rimozione di questa operazione dai server back-end consente loro di concentrarsi sull'operazione per cui sono più efficienti, ovvero la distribuzione di contenuti.
• Routing intelligente - Tramite la decrittografia del traffico il gateway applicazione ha accesso al contenuto delle richieste, ad esempio intestazioni, URI e così via, e può usare questi dati per il routing delle richieste.
• Gestione dei certificati - I certificati devono essere acquistati e installati solo nel gateway applicazione e non in tutti i server back-end. Questo consente di risparmiare tempo e denaro.

Per configurare la terminazione TLS, è necessario aggiungere un certificato TLS/SSL al listener. In questo modo il gateway applicazione può decrittografare il traffico in ingresso e crittografare il traffico di risposta al client. Il certificato fornito al gateway applicazione deve essere in formato PFX (Personal Information Exchange), che contiene sia le chiavi private che pubbliche. Gli algoritmi PFX supportati sono elencati nella funzione PFXImportCertStore.

Importante

Il certificato nel listener richiede il caricamento dell'intera catena di certificati (il certificato radice dalla CA, gli intermedi e il certificato foglia) per stabilire la catena di attendibilità.

Note

Il gateway applicazione non offre alcuna funzionalità per creare un nuovo certificato o inviare una richiesta di certificato a un'autorità di certificazione.

Per il corretto funzionamento della connessione TLS, è necessario assicurarsi che il certificato TLS/SSL soddisfi le condizioni seguenti:

• La data e l'ora corrente devono trovarsi all'interno dell'intervallo "Valido da" e "Valido fino a" del certificato.
• Il "nome comune" del certificato deve corrispondere all'intestazione host nella richiesta. Se ad esempio il client effettua una richiesta a https://www.contoso.com/, il nome comune del certificato deve essere www.contoso.com.

Se si verificano errori con il nome comune del certificato back-end, vedere la guida alla risoluzione dei problemi.

Certificati supportati per la terminazione TLS

Il gateway applicazione supporta i tipi di certificati seguenti:

• Certificato CA (autorità di certificazione): un certificato CA è un certificato digitale emesso da un'autorità di certificazione (CA)
• Certificato EV (convalida estesa): un certificato EV è un certificato conforme alle linee guida dei certificati standard del settore. In questo modo la barra del localizzatore del browser diventa verde e viene pubblicato anche il nome della società.
• Certificato jolly: questo certificato supporta un numero qualsiasi di sottodomini basati su *.site.com, in cui il sottodominio sostituirà *. Tuttavia, non supporta site.com, quindi, nel caso in cui gli utenti accedano al sito Web senza digitare "www", il certificato jolly non lo coprirà.
• Certificati autofirmati: i browser client non considerano attendibili questi certificati e avvisano l'utente che il certificato del servizio virtuale non fa parte di una catena attendibile. I certificati autofirmati sono utili per i test o gli ambienti in cui gli amministratori controllano i client e possono ignorare in modo sicuro gli avvisi di sicurezza del browser. I carichi di lavoro di produzione non devono mai usare certificati autofirmati.

Per altre informazioni, vedere Configurare la terminazione TLS con il gateway applicazione.

Dimensioni del certificato

Per informazioni sulle dimensioni massime supportate per i certificati TLS/SSL, vedere la sezione Limiti del gateway applicazione.

Crittografia TLS end-to-end

È possibile che si vogliano evitare comunicazioni non crittografate con i server back-end, per soddisfare requisiti di sicurezza o di conformità specifici o perché l'applicazione può accettare solo connessioni sicure. Il gateway applicazione di Azure include la crittografia TLS end-to-end per supportare questi requisiti.

TLS end-to-end consente di crittografare e trasmettere in modo sicuro i dati sensibili al back-end mentre si usano le funzionalità di bilanciamento del carico di livello 7 del gateway applicazione. Queste funzionalità includono l'affinità di sessione basata su cookie, il routing basato su URL, il supporto per il routing basato su siti, la possibilità di riscrivere o inserire intestazioni X-Forwarded-* e così via.

Se configurato con la modalità di comunicazione TLS end-to-end, il gateway applicazione termina le sessioni TLS nel gateway ed esegue la decrittografia del traffico utente. Applica quindi le regole configurate per selezionare un'istanza del pool di back-end adeguata su cui instradare il traffico. Il gateway applicazione avvia a questo punto una nuova connessione TLS al server back-end e crittografa nuovamente i dati usando il certificato di chiave pubblica del server back-end prima di trasmettere la richiesta al back-end. Eventuali risposte dal server Web subiscono lo stesso processo in ritorno verso l'utente finale. Per abilitare TLS end-to-end si imposta la configurazione del protocollo nell'impostazione HTTP di back-end su HTTPS. Questa impostazione viene quindi applicata a un pool back-end.

Nei gateway SKU del gateway applicazione v1, i criteri TLS applicano la versione TLS solo al traffico front-end e alle crittografie definite sia alle destinazioni front-end che back-end. Nei gateway SKU del gateway applicazione v2, i criteri TLS si applicano solo al traffico front-end, le connessioni TLS back-end verranno sempre negoziate tramite TLS 1.0 alle versioni di TLS 1.2.

Il gateway applicazione comunica solo con i server back-end che hanno autorizzato il proprio certificato ad essere nell’elenco riconosciuto dal gateway applicazione o i cui certificati sono firmati da autorità CA note e il nome comune del certificato corrisponde al nome host nelle impostazioni back-end HTTP. Questi includono i servizi di Azure attendibili, come Servizio app di Azure/App Web e Gestione API di Azure.

Se i certificati dei membri nel pool back-end non sono firmati da autorità CA note, ogni istanza del pool back-end con TLS end-to-end abilitata deve essere configurata con un certificato per consentire la comunicazione sicura. L'aggiunta del certificato garantisce che il gateway applicazione comunichi solo con istanze back-end note. proteggendo ulteriormente la comunicazione end-to-end.

Note

Il certificato aggiunto all'impostazione HTTP di back-end per autenticare i server back-end può essere lo stesso del certificato aggiunto al listener per la terminazione TLS nel gateway applicazione o diverso per maggiore sicurezza.

In questo esempio, le richieste che usano TLS1.2 vengono instradate ai server back-end in Pool1 con TLS end-to-end.

TLS end-to-end e consentire l'elenco dei certificati

Il gateway applicazione comunica solo con i server back-end che hanno autorizzato il proprio certificato ad essere nell’elenco riconosciuto dal gateway applicazione o i cui certificati sono firmati da autorità CA note e il nome comune del certificato corrisponde al nome host nelle impostazioni back-end HTTP. Esistono alcune differenze nel processo di configurazione di TLS end-to-end a seconda della versione del gateway applicazione usata. La sezione seguente illustra le versioni singolarmente.

TLS end-to-end con lo SKU v1

Per abilitare TLS end-to-end con i server back-end e in modo che il gateway applicazione instradi le richieste a tali server, i probe di integrità devono avere esito positivo e restituire una risposta di integrità.

Per i probe di integrità HTTPS, lo SKU v1 del gateway applicazione usa una corrispondenza esatta del certificato di autenticazione (chiave pubblica del certificato del server back-end e non del certificato radice) da caricare nelle impostazioni HTTP.

Sono quindi consentite solo le connessioni ai back-end noti e consentiti. I backend rimanenti sono considerati non integri dai probe di integrità. I certificati autofirmati vengono usati a scopo di test e non sono consigliati per i carichi di lavoro. Questi certificati devono essere aggiunti all'elenco dei consentiti nel gateway applicazione, come descritto nei passaggi precedenti, prima di poter essere usati.

Note

L'autenticazione e la configurazione del certificato radice attendibile non sono necessarie per i servizi di Azure attendibili, ad esempio il servizio app di Azure. Vengono considerati attendibili per impostazione predefinita.

TLS end-to-end con lo SKU v2

I certificati di autenticazione sono stati deprecati e sostituiti da certificati radice attendibili nello SKU v2 gateway applicazione. Funzionano in modo analogo ai certificati di autenticazione con alcune differenze principali:

• I certificati firmati da autorità CA note il cui CN corrisponde al nome host nelle impostazioni back-end HTTP non richiedono alcun passaggio aggiuntivo per il funzionamento di TLS end-to-end.

  Ad esempio, se i certificati di back-end sono rilasciati da un'autorità di certificazione nota il cui nome comune è contoso.com e anche il campo host delle impostazioni HTTP di back-end è impostato su contoso.com, non sono necessarie altre operazioni. Se si configura il protocollo HTTPS nell'impostazione HTTP di back-end, sia il probe di integrità che il percorso dei dati saranno abilitati per TLS. Se si usano Servizio app di Azure o altri servizi Web di Azure come back-end, anche questi sono considerati implicitamente attendibili e non sono necessari altri passaggi per TLS end-to-end.

Note

Affinché un certificato TLS/SSL venga considerato attendibile, tale certificato del server back-end deve essere stato emesso da un'autorità di certificazione nota. Se il certificato non è stato emesso da un'autorità di certificazione attendibile, il gateway applicazione verificherà quindi se il certificato della CA emittente è stato emesso da una CA attendibile e così via fino a quando non viene rilevata una CA attendibile (e a questo punto viene stabilita una connessione sicura attendibile) o non è possibile trovare una CA attendibile (e a questo punto il gateway applicazione contrassegna il back-end come non integro). È quindi consigliabile che il certificato del server back-end contenga sia la CA radice che le CA intermedie.

• Se il certificato del server back-end è autofirmato o firmato da autorità di certificazione/intermediari sconosciuti, per abilitare TLS end-to-end nel gateway applicazione v2 è necessario caricare un certificato radice attendibile. Il gateway applicazione comunicherà solo con back-end il cui certificato radice del certificato del server corrisponde a uno dei certificati dell'elenco dei certificati radice attendibili nell'impostazione HTTP di back-end associata al pool.

• Oltre alla corrispondenza del certificato radice, il gateway applicazione v2 verifica anche se l'impostazione Host specificata nell'impostazione HTTP di back-end corrisponde a quella del nome comune presentata dal certificato TLS/SSL del server back-end. Quando si tenta di stabilire una connessione TLS al back-end, il gateway applicazione v2 imposta l'estensione Indicazione nome server (SNI) sull'host specificato nell'impostazione HTTP di back-end.

• Se si sceglie selezionare il nome host dal target back-end invece del campo Host nell'impostazione http back-end, l'intestazione SNI viene sempre impostata sul nome di dominio completo del pool back-end e il nome di dominio completo del server back-end TLS/SSL deve corrispondere al nome di dominio completo. I membri del pool di back-end con indirizzi IP non sono supportati in questo scenario.

• Il certificato radice è un certificato radice con codifica base64 dai certificati del server back-end.

Differenze di SNI per gli SKU v1 e v2

Come indicato in precedenza, il gateway applicazione termina il traffico TLS dal client nel listener del gateway applicazione (o connessione front-end), decrittografa il traffico, applica le regole necessarie per determinare il server back-end a cui deve essere inoltrata la richiesta e stabilisce una nuova sessione TLS con il server back-end (o connessione back-end).

Le tabelle seguenti illustrano le differenze di SNI tra lo SKU v1 e v2 in termini di connessioni front-end e back-end.

Connessione TLS front-end (dal client al gateway applicazione)

Scenario	v1	v2
Se il client specifica l'intestazione SNI e tutti i listener multisito sono abilitati con il flag "Require SNI" (Richiedi SNI)	Il certificato appropriato viene restituito e se il sito non esiste (in base al server_name), la connessione viene reimpostata.	Il certificato appropriato viene restituito, se disponibile, in caso contrario, restituisce il certificato del primo listener HTTPS in base all'ordine specificato dalle regole di routing delle richieste associate ai listener HTTPS
Se il client non specifica un'intestazione SNI e se tutte le intestazioni multisito sono abilitate con "Require SNI" (Richiedi SNI)	Reimposta la connessione	Il certificato del primo listener HTTPS viene restituito in base all'ordine specificato dalle regole di routing delle richieste associate ai listener HTTPS
Se il client non specifica l'intestazione SNI e se è configurato un listener di base con un certificato	Restituisce il certificato configurato nel listener di base al client (certificato predefinito o di fallback)	Il certificato configurato nel listener di base viene restituito

Note

Quando il client non specifica un'intestazione SNI, si consiglia all'utente di aggiungere un listener di base e una regola per presentare un certificato SSL/TLS predefinito.

Suggerimento

Il flag SNI può essere configurato con PowerShell o usando un modello di Resource Manager. Per altre informazioni, vedere RequireServerNameIndication e Avvio rapido: Indirizzare il traffico Web con il gateway applicazione di Azure - Modello di Resource Manager.

Connessione TLS back-end (gateway applicazione al server back-end)

Per il traffico probe

Scenario	v1	v2
Quando è configurato un FQDN o un SNI	Imposta come FQDN dal pool back-end. In base a RFC 6066, gli indirizzi letterali IPv4 e IPv6 non sono consentiti nel nome host SNI.	Il valore SNI viene impostato in base al tipo di convalida TLS nelle impostazioni back-end. 1. Convalida completa – Le sonde usano l'SNI nell'ordine di precedenza seguente: a) Nome host del probe di integrità personalizzato b) Nome host dell'impostazione back-end (Valore sottoposto a override o Seleziona dal server back-end) 2. Configurabile Usa SNI specifico: le sonde usano questo hostname fisso per la convalida. Ignora SNI: Nessuna convalida del nome del soggetto.
Quando un FQDN o SNI non è configurato (è disponibile solo l'indirizzo IP)	SNI (server_name) non verrà impostato. Nota: In questo caso, il server back-end deve essere in grado di restituire un certificato di fallback predefinito e deve essere nell’elenco delle impostazioni HTTP come certificato di autenticazione. Se nel server back-end non sono configurati certificati predefiniti/di fallback ed è previsto SNI, il server potrebbe reimpostare la connessione con conseguenti errori di probe	Se la sonda personalizzata o le impostazioni del back-end usano un indirizzo IP nel campo hostname, l'SNI non è impostato, in base a RFC 6066. Sono inclusi i casi in cui il probe predefinito usa la versione 127.0.0.1.

Per il traffico in tempo reale

Scenario	v1	v2
Quando è disponibile un FQDN o un SNI	L'SNI viene impostato usando il nome di dominio completo del server back-end.	Il valore SNI viene impostato in base al tipo di convalida TLS nelle impostazioni back-end. 1. Convalida completa : SNI viene impostato in base all'ordine di precedenza seguente: a) Nome host dell'impostazione back-end (Valore sottoposto a override o Seleziona dal server back-end) b) Intestazione host della richiesta client in ingresso 2. Configurabile Usa SNI specifico: usa questo nome host fisso per la convalida. Ignora SNI: Nessuna convalida del nome del soggetto.
Quando un FQDN o SNI non è disponibile (è disponibile solo l'indirizzo IP)	SNI non verrà impostato in base a RFC 6066 se la voce del pool back-end non è un nome di dominio completo	SNI non verrà impostato in base a RFC 6066.

Passaggi successivi

Dopo avere appreso i concetti di TLS end-to-end, passare a Configurare TLS end-to-end usando un gateway applicazione con PowerShell per creare un gateway applicazione usando TLS end-to-end.