Condividi tramite

Certificati e ambiente del servizio app v2

  • Articolo

Importante

Questo articolo riguarda l'ambiente del servizio app v2, usato con i piani del servizio app Isolato. L'ambiente del servizio app v1 e v2 è stato ritirato il 31 agosto 2024. È disponibile una nuova versione dell'ambiente del servizio app più facile da usare, che viene eseguita in un'infrastruttura più potente. Per altre informazioni sulla nuova versione, vedere Introduzione all'ambiente del servizio app. Se al momento si usa l'ambiente del servizio app v1, seguire la procedura descritta in questo articolo per eseguire la migrazione alla nuova versione.

A partire dal 31 agosto 2024, il Contratto di servizio e i crediti di servizio non si applicano più ai carichi di lavoro dell'ambiente del servizio app v1 e v2 che continuano a essere in produzione, perché sono prodotti ritirati. È stata avviata la dismissione dell'hardware dell'ambiente del servizio app v1 e v2, il che può influire sulla disponibilità e sulle prestazioni di app e dati.

È necessario completare immediatamente la migrazione all'ambiente del servizio app v3 oppure è possibile che le app e le risorse vengano eliminate. Si tenterà con il massimo impegno di eseguire automaticamente la migrazione di qualsiasi ambiente del servizio app v1 e v2 rimanente usando la funzionalità di migrazione sul posto, ma Microsoft non dichiara né garantisce la disponibilità delle applicazioni dopo la migrazione automatica. Può essere necessario eseguire una configurazione manuale per completare la migrazione e ottimizzare la scelta di SKU del piano di servizio app in base a specifiche esigenze. Se la migrazione automatica non è fattibile, le risorse e i dati delle app associati verranno eliminati. È consigliabile agire tempestivamente per evitare uno di questi scenari estremi.

Se è necessario più tempo, è possibile usufruire di un periodo di tolleranza di 30 giorni una tantum per completare la migrazione. Per altre informazioni e per richiedere questo periodo di tolleranza, vedere la panoramica del periodo di tolleranza, quindi passare al portale di Azure e visitare il pannello Migrazione per ogni ambiente del servizio app.

Per le informazioni più aggiornate sul ritiro dell'ambiente del servizio app v1/v2, vedere l'Aggiornamento sul ritiro dall'ambiente del servizio app v1 e v2.

L'Ambiente del servizio app (ASE) è una distribuzione del servizio app di Azure che viene eseguita nella rete virtuale di Azure (VNet). Può essere distribuita con un endpoint applicazione accessibile da Internet o un endpoint applicazione che si trova in una rete virtuale. Se l'Ambiente del servizio app viene distribuito con un endpoint accessibile da Internet, la distribuzione viene chiamata Ambiente del servizio app esterno. Se l'ambiente del servizio app viene distribuito con un endpoint nella rete virtuale, la distribuzione viene chiamata ambiente del servizio app con bilanciamento del carico interno. Per altre informazioni sull'Ambiente del servizio app con bilanciamento del carico interno, vedere il documento Creazione e uso di un Ambiente del servizio app con bilanciamento del carico interno.

L'ambiente del servizio app è un sistema a tenant singolo. Poiché si tratta di un tenant singolo, esistono alcune funzionalità disponibili solo con un ambiente del servizio app che non sono disponibili nel servizio app multi-tenant.

Certificati di Ambiente del servizio app con bilanciamento del carico interno

Se si usa un ambiente del servizio app esterno, le app vengono raggiunte in <appname>.<asename>.p.azurewebsites.net. Per impostazione predefinita tutti gli Ambienti del servizio app, anche gli Ambienti del servizio App ILB, vengono creati con i certificati che seguono tale formato. Quando si dispone di un Ambiente del servizio app con bilanciamento del carico interno, le app vengono raggiunte in base al nome di dominio specificato durante la creazione dell'Ambiente del servizio app con bilanciamento del carico interno. Affinché le app supportino TLS, è necessario caricare i certificati. Ottenere un certificato TLS/SSL valido usando le autorità di certificazione interne, acquistando un certificato da un'autorità di certificazione esterna o usando un certificato autofirmato.

Sono disponibili due opzioni di configurazione dei certificati con l'Ambiente del servizio app con bilanciamento del carico interno. È possibile impostare un certificato predefinito con caratteri jolly per l'Ambiente del servizio app con bilanciamento del carico interno o impostare i certificati per le singole app Web nell'Ambiente del servizio app. Indipendentemente dalla scelta, è necessario configurare correttamente gli attributi del certificato seguenti:

  • Soggetto: questo attributo deve essere impostato su *.[your-root-domain-here] per un certificato con caratteri jolly dell'Ambiente del servizio app con bilanciamento del carico interno. Se si crea il certificato per l'app, dovrà quindi essere [appname].[your-root-domain-here]
  • Nome alternativo del soggetto: questo attributo deve includere .[your-root-domain-here] e.scm.[your-root-domain-here] per il certificato con caratteri jolly dell'ambiente del servizio app con bilanciamento del carico interno. Se si crea il certificato per l'app, dovrà quindi essere [appname].[your-root-domain-here] e [appname].scm.[your-root-domain-here].

Come terza variante, è possibile creare un certificato Ambiente del servizio app con bilanciamento del carico interno che include tutti i nomi delle singole app nella rete SAN del certificato anziché un riferimento con caratteri jolly. Il problema con questo metodo è che è necessario conoscere in anticipo i nomi delle app che vengono inserite nell'ambiente del servizio app o è necessario aggiornare continuamente il certificato dell'ambiente del servizio app con bilanciamento del carico interno.

Caricare il certificato sull'Ambiente del servizio app con bilanciamento del carico interno

Dopo aver creato un Ambiente del servizio app con bilanciamento del carico interno nel portale, il certificato deve essere impostato per l'Ambiente del servizio app con bilanciamento del carico interno. Finché il certificato non viene impostato, nell'ambiente del servizio app verrà visualizzato un banner che indica che il certificato non è stato impostato.

Il certificato caricato deve essere un file con estensione .pfx. Dopo il caricamento del certificato, si verifica un ritardo di circa 20 minuti prima dell'uso del certificato.

Non è possibile creare l'ambiente del servizio app e caricare il certificato come un'unica azione nel portale o anche in un modello. Come azione separata, è possibile caricare il certificato usando un modello come descritto nel documento Creare un Ambiente del servizio app da un modello.

Se si desidera creare rapidamente un certificato autofirmato per il test, è possibile usare il seguente bit di PowerShell:

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $password

Quando si crea un certificato autofirmato, è necessario assicurarsi che il nome del soggetto abbia il formato CN={ASE_NAME_HERE}_InternalLoadBalancingASE.

Certificati delle applicazioni

Le app ospitate in un ambiente del servizio app possono usare le funzionalità relative ai certificati basati sull'applicazione che sono disponibili nel servizio app multi-tenant. Queste funzionalità includono:

  • Certificati SNI
  • SSL basato su IP, supportato solo con un Ambiente del servizio app esterno. Un ambiente del servizio app con bilanciamento del carico interno non supporta SSL basato su IP.
  • Certificati di Key Vault ospitato

Le istruzioni per caricare e gestire tali certificati sono disponibili in Aggiungere un certificato TLS/SSL nel Servizio app di Azure. Se si configurano semplicemente i certificati in modo che corrispondano a un nome di dominio personalizzato assegnato all'app Web, tali istruzioni saranno sufficienti. Se si carica il certificato per un'app Web dell'ambiente del servizio app con bilanciamento del carico interno con il nome di dominio predefinito, specificare il sito scm nella rete SAN del certificato come indicato in precedenza.

Impostazioni di TLS

A livello di app, è possibile configurare l'impostazione di TLS.

Certificato client privato

Un caso d'uso comune è quello in cui l'app viene configurata come client in un modello client-server. Se si protegge il server con un certificato della CA privato, è necessario caricare il certificato client nell'app. Nelle istruzioni seguenti verranno caricati i certificati truststore dei ruoli di lavoro su cui è in esecuzione l'app. Se si carica il certificato da un'app, è possibile usarlo con le altre app nello stesso piano di servizio app senza caricare nuovamente il certificato.

Per caricare il certificato nell'app dell'Ambiente di servizio app:

  1. Generare un file .cer per il certificato.
  2. Passare all'app che richiede il certificato nel portale di Azure
  3. Passare alle impostazioni SSL nell'app. Fare clic su Carica certificato. Selezionare Pubblico. Selezionare Computer locale. Specificare un nome. Esplorare e selezionare i file .cer. Selezionare Carica.
  4. Copiare l'identificazione personale.
  5. Passare alle impostazioni applicazione. Creare un'impostazione app WEBSITE_LOAD_ROOT_CERTIFICATES con l'identificazione personale come valore. Se si hanno più certificati, è possibile inserirli nella stessa impostazione separata da virgole e senza spazi vuoti, ad esempio

84EC242A4EC7957817B8E48913E50953552DAFA6,6A5C65DC9247F762FE17BF8D4906E04FE6B31819

Il certificato sarà disponibile per tutte le app nello stesso piano di servizio app come l'app che ha permesso di configurare tale impostazione. Se è necessario che sia disponibile per le app in un piano di servizio app diverso, è necessario ripetere l'operazione di impostazione dell'app in un'app nel piano di servizio app. Per verificare che il certificato sia impostato, passare alla console Kudu ed eseguire il comando seguente nella console di debug di PowerShell:

dir cert:\localmachine\root

Per eseguire il test, è possibile creare un certificato autofirmato e generare un file CER con il comando PowerShell seguente:

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.cer"
export-certificate -Cert $certThumbprint -FilePath $fileName -Type CERT