Imporre HTTPS in ASP.NET Core

Progetti API

I progetti che usano le API Web devono:

• Non ascoltare su HTTP.
• Chiudere la connessione con il codice di stato 400 (Richiesta non valida) e non gestire la richiesta.

Per disabilitare il reindirizzamento HTTP in un'API, impostare la ASPNETCORE_URLS variabile di ambiente o usare il flag della --urls riga di comando. Per ulteriori informazioni, vedere Ambienti di runtime ASP.NET Core e 8 modi per impostare gli URL per un'app ASP.NET Core di Andrew Lock.

Progetti HSTS e API

L'approccio sicuro per HTTP Strict Transport Security Protocol (HSTS) prevede di configurare i progetti API in modo che ascoltino e rispondano solo tramite HTTPS.

Reindirizzamento HTTP a HTTPS (ERR_INVALID_REDIRECT nella richiesta preflight CORS)

Quando una richiesta a un endpoint tramite HTTP viene reindirizzata a HTTPS con il metodo UseHttpsRedirection, il reindirizzamento non va a buon fine con l'errore ERR_INVALID_REDIRECT durante la richiesta preliminare CORS.

I progetti API possono rifiutare le richieste HTTP anziché usare il UseHttpsRedirection metodo per reindirizzare le richieste a HTTPS.

Richiedi HTTPS

Per le app Web di produzione ASP.NET Core, è consigliabile adottare l'approccio seguente:

• Per reindirizzare le richieste HTTP a HTTPS, usare il middleware di reindirizzamento HTTPS (UseHttpsRedirection).

• Per inviare intestazioni HSTS ai client, usare il middleware HSTS tramite il metodo UseHsts .

UseHttpsRedirection

Il codice seguente chiama il UseHttpsRedirection metodo nel file Program.cs :

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Il codice evidenziato precedente:

• Usa la proprietà predefinita HttpsRedirectionOptions.RedirectStatusCode con il Status307TemporaryRedirect codice .
• Utilizza la proprietà predefinita HttpsRedirectionOptions.HttpsPort (passando null), a meno che non venga sovrascritta dalla variabile di ambiente ASPNETCORE_HTTPS_PORT o da IServerAddressesFeature.

L'approccio consigliato consiste nell'usare reindirizzamenti temporanei anziché reindirizzamenti permanenti. La memorizzazione nella cache dei collegamenti può causare un comportamento instabile negli ambienti di sviluppo. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente nonDevelopment , vedere la sezione Configurare i reindirizzamenti permanenti nell'ambiente di produzione . Usare HSTS per segnalare ai client che devono essere inviate solo richieste di risorse sicure all'app (solo in produzione).

Configurazione della porta

Una porta deve essere disponibile per il middleware per reindirizzare una richiesta non sicura a HTTPS. Se non è disponibile alcuna porta:

• Il reindirizzamento a HTTPS non si verifica.
• Il middleware registra l'avviso Non è stato possibile determinare la porta https per il reindirizzamento.

Specificare la porta HTTPS usando uno degli approcci seguenti:

• Imposta HttpsRedirectionOptions.HttpsPort.

• Impostare le impostazioni dell'host https_port.

  • Nella configurazione dell'host.

  • Impostando la ASPNETCORE_HTTPS_PORT variabile di ambiente.

  • Aggiungendo una voce di primo livello nel file appsettings.json :

    {
      "https_port": 443,
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      },
      "AllowedHosts": "*"
    }
    

• Indicare una porta con lo schema sicuro usando la variabile di ambiente ASPNETCORE_URLS. La variabile di ambiente configura il server. Il middleware individua indirettamente la porta HTTPS tramite IServerAddressesFeature. Questo approccio non funziona nelle implementazioni di proxy inversi.

• I modelli Web di ASP.NET Core impostano un URL HTTPS nel file Properties/launchsettings.json sia per Kestrel che per IIS Express. Il filelaunchsettings.json viene usato solo nel computer locale.

• Configurare un endpoint URL HTTPS per una distribuzione perimetrale pubblica del Kestrel server o HTTP.sys server. L'app usa una sola porta HTTPS. Il middleware individua la porta tramite IServerAddressesFeature.

Distribuzioni perimetrali

Quando Kestrel o HTTP.sys viene utilizzato come server perimetrale pubblico, Kestrel o HTTP.sys deve essere configurato per l'ascolto su entrambe le porte richieste.

• Porta sicura in cui viene reindirizzato il client (in genere, 443 nell'ambiente di produzione e 5001 in fase di sviluppo).
• La porta non sicura (in genere 80 in produzione e 5000 in fase di sviluppo).

La porta non sicura deve essere accessibile dal client affinché l'app riceva una richiesta non sicura e reindirizzi il client alla porta protetta.

Per ulteriori informazioni, vedere la configurazione dell'endpoint o l'implementazione del sistema server Web HTTP.sys in ASP.NET Core.

Scenari di distribuzione

Qualsiasi firewall tra il client e il server deve anche avere porte di comunicazione aperte per il traffico.

Se le richieste sono inoltrate in una configurazione di proxy inverso, utilizzare Forwarded Headers Middleware prima di chiamare il middleware di reindirizzamento HTTPS. Il middleware delle intestazioni inoltrate aggiorna Request.Scheme usando l'intestazione X-Forwarded-Proto. Il middleware consente il corretto funzionamento degli URI di reindirizzamento e di altri criteri di sicurezza. Quando il middleware per le intestazioni inoltrate non viene usato, l'app back-end potrebbe non ricevere lo schema corretto e rimanere bloccata in un ciclo di reindirizzamento. Un messaggio di errore dell'utente finale comune è un numero eccessivo di reindirizzamenti.

Quando si esegue la distribuzione in Servizio app di Azure, seguire le indicazioni riportate in Enable HTTPS per un dominio personalizzato in Servizio app di Azure.

Options

Il codice evidenziato seguente chiama il AddHttpsRedirection metodo per configurare le opzioni del middleware:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

La chiamata AddHttpsRedirection è necessaria solo per modificare i valori di HttpsPort o RedirectStatusCode.

Il codice evidenziato precedente:

• Imposta la HttpsRedirectionOptions.RedirectStatusCode proprietà sul Status307TemporaryRedirect codice, ovvero il valore predefinito. Usare i campi della StatusCodes classe per le assegnazioni a RedirectStatusCode.
• Imposta la porta HTTPS su 5001.

Configurare reindirizzamenti permanenti nell'ambiente di produzione

Il middleware usa per impostazione predefinita l'invio di un Status307TemporaryRedirect codice con tutti i reindirizzamenti. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente diverso da Development, avvolgere la configurazione delle opzioni del middleware in un controllo condizionale per un ambiente non-Development.

Il codice seguente illustra la configurazione dei servizi nel file Program.cs :

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Approccio alternativo al middleware di reindirizzamento HTTPS

Un'alternativa all'uso del middleware di reindirizzamento HTTPS (con il metodo UseHttpsRedirection) consiste nell'usare il middleware per la riscrittura degli URL (tramite il metodo AddRedirectToHttps). AddRedirectToHttps può anche impostare il codice di stato e la porta quando viene eseguito il reindirizzamento. Per ulteriori informazioni, vedere Middleware di riscrittura degli URL.

Quando l'app reindirizza a HTTPS senza il requisito per altre regole di reindirizzamento, è consigliabile usare il middleware di reindirizzamento HTTPS (UseHttpsRedirection) come descritto in questo articolo.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP, HSTS è un miglioramento della sicurezza di consenso esplicito specificato da un'app Web tramite un'intestazione di risposta. Quando un browser che supporta HSTS riceve l'intestazione HTTP:

• Il browser archivia la configurazione per il dominio che impedisce l'invio di comunicazioni tramite HTTP. Il browser forza tutte le comunicazioni tramite HTTPS.
• Il browser impedisce all'utente di usare certificati non attendibili o non validi. Il browser disabilita le richieste che consentono a un utente di considerare temporaneamente attendibile tale certificato.

Poiché il client applica HSTS, esistono alcune limitazioni:

• Il client deve supportare HSTS.
• HSTS richiede almeno una richiesta HTTPS riuscita per stabilire i criteri HSTS.
• L'applicazione deve controllare ogni richiesta HTTP e reindirizzare o rifiutare la richiesta HTTP.

ASP.NET Core implementa HSTS con il UseHsts metodo di estensione. Il codice seguente chiama UseHsts quando l'app non è in modalità di sviluppo:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts non è consigliato in fase di sviluppo perché le impostazioni HSTS sono altamente memorizzabili nella cache dai browser. Per impostazione predefinita, UseHsts esclude l'indirizzo di loopback locale.

Per gli ambienti di produzione che implementano HTTPS per la prima volta, impostare il valore della proprietà iniziale HstsOptions.MaxAge su una piccola quantità usando uno dei TimeSpan metodi . Impostare il valore da ore a non più di un singolo giorno, nel caso in cui sia necessario ripristinare l'infrastruttura HTTPS su HTTP. Dopo aver compreso la sostenibilità della configurazione HTTPS, aumentare il valore HSTS max-age (comunemente, un anno).

Il codice evidenziato seguente:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• Imposta il parametro di precaricamento dell'intestazione Strict-Transport-Security. Il preload non fa parte della specifica HSTS definita nella RFC 6797. I browser web supportano il precaricamento dei siti HSTS in una nuova installazione. Per ulteriori informazioni, vedere https://hstspreload.org/.
• Abilita la includeSubDomain direttiva , che applica i criteri HSTS ai sottodomini host. Per altre informazioni, vedere Specifica HSTS RFC 6797 (sezione 6.1.2).
• Imposta in modo esplicito il max-age parametro dell'intestazione Strict-Transport-Security su 60 giorni. Se non è impostato, il valore predefinito è 30 giorni. Per ulteriori informazioni, vedere la direttiva max-age nella specifica HSTS RFC 6797 (Sezione 6.1.1).
• Aggiunge example.com all'elenco di host da escludere.

UseHsts esclude gli host di loopback seguenti:

• localhost: L'indirizzo di loopback IPv4.
• 127.0.0.1: L'indirizzo di loopback IPv4.
• [::1]: L'indirizzo di loopback IPv6.

Rifiutare esplicitamente HTTPS/HSTS alla creazione del progetto

In alcuni scenari di servizio back-end in cui la sicurezza della connessione viene gestita nel perimetro pubblico della rete, la configurazione della sicurezza delle connessioni in ogni nodo non è necessaria. Le app Web generate dai modelli in Visual Studio o dal comando dotnet new abilitano il reindirizzamento HTTPS e HSTS. Per le distribuzioni che non richiedono questi scenari, è possibile rifiutare esplicitamente HTTPS/HSTS quando l'app viene creata dal modello.

Per rifiutare esplicitamente HTTPS/HSTS:

dotnet new webapp --no-https

Considerare attendibile il certificato di sviluppo HTTPS ASP.NET Core

.NET SDK include un certificato di sviluppo HTTPS. Il certificato viene installato come parte dell'esperienza di prima esecuzione. Ad esempio, il dotnet --info comando produce una variante dell'output seguente:

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

L'installazione di .NET SDK installa il certificato di sviluppo HTTPS di ASP.NET Core nell'archivio certificati utente locale. Il certificato è installato, ma non è attendibile. Per considerare attendibile il certificato, eseguire il passaggio una tantum per eseguire lo strumento dotnet dev-certs.

dotnet dev-certs https --trust

Il comando seguente fornisce aiuto sullo strumento dotnet dev-certs:

dotnet dev-certs https --help

Configurare il certificato per sviluppatori per Docker

Per configurare il certificato per sviluppatori per Docker, vedere GitHub dotnet/aspnetcore.docs issue #6199 - Come configurare il certificato di sviluppo quando si usa Docker in sviluppo.

Considerazioni specifiche di Linux

Le distribuzioni di Linux differiscono in modo sostanziale nel modo in cui contrassegnano i certificati come attendibili.

Lo dotnet dev-certs strumento dovrebbe essere ampiamente applicabile, ma il supporto ufficiale è disponibile solo per Ubuntu e Fedora. Il supporto mira in particolare a garantire fiducia nei browser basati su Firefox e Chromium (Microsoft Edge, Chrome e Chromium).

Dependencies

• Per stabilire la fiducia di OpenSSL, lo strumento openssl deve trovarsi nel path di sistema.
• Per stabilire l'attendibilità del browser (ad esempio in Microsoft Edge o Firefox), lo strumento certutil deve trovarsi nel percorso.

Affidabilità di OpenSSL

Quando un certificato di sviluppo ASP.NET Core è attendibile, il certificato viene esportato in una cartella nella home directory dell'utente corrente. Per fare in modo che OpenSSL (e i client che lo usano) rilevino questa cartella, è necessario impostare la SSL_CERT_DIR variabile di ambiente. È possibile impostare la variabile in una singola sessione eseguendo un comando come export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (il valore esatto è nell'output quando viene fornito --verbose) oppure aggiungendola al proprio file di configurazione specifico della distribuzione e della shell (ad esempio .profile).

Questo approccio è necessario per rendere attendibili gli strumenti come curl il certificato di sviluppo. In alternativa, è possibile passare -CAfile o -CApath a ogni singola curl chiamata.

Se il trust OpenSSL entra in uno stato non valido,ad esempio se dotnet dev-certs https --clean non riesce a rimuoverlo, è possibile risolvere spesso la situazione usando lo strumento c_rehash .

Overrides

Se si usa un altro browser con un archivio NSS (Network Security Services), è possibile usare la DOTNET_DEV_CERTS_NSSDB_PATHS variabile di ambiente per specificare un elenco delimitato da due punti delle directory NSS , ad esempio la directory contenente cert9.db. È quindi possibile aggiungere il percorso del certificato di sviluppo all'elenco nella variabile .

Se si archiviano i certificati che si desidera che OpenSSL consideri attendibile in una directory specifica, è possibile usare la DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY variabile di ambiente per indicare il percorso del certificato.

Uso di sudo

Come in altre piattaforme, i certificati di sviluppo vengono archiviati e considerati attendibili separatamente per ogni utente.

Se si esegue dotnet dev-certs come utente diverso , ad esempio usando sudo, tale utente specifico (ad esempio root) considera attendibile il certificato di sviluppo.

Rendere attendibile il certificato HTTPS su Linux con linux-dev-certs

linux-dev-certs è uno strumento globale .NET open source supportato dalla community che offre un modo pratico per creare e considerare attendibile un certificato per sviluppatori in Linux. Microsoft non gestisce o supporta lo strumento.

I comandi seguenti installano lo strumento e creano un certificato per sviluppatori attendibile:

dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

Per ulteriori informazioni o per segnalare problemi, consulta il repository GitHub linux-dev-certs.

SUSE Linux Enterprise Server (SLES Linux)

Se la configurazione include SUSE Linux Enterprise Server, vedere GitHub dotnet/aspnetcore.docs issue #28292 - Trust HTTPS certificate on SLES.

Risolvere i problemi relativi ai certificati (certificato non attendibile)

A volte quando un certificato di sviluppo HTTPS ASP.NET Core è installato e attendibile, il browser avvisa che il certificato non è attendibile. Le sezioni seguenti forniscono assistenza per la risoluzione di questo problema.

Il certificato di sviluppo HTTPS core ASP.NET viene usato da Kestrel.

Per ripristinare il certificato IIS Express, vedere Problema di Stack Overflow #20036984/answer #20048613 - Come ripristinare un certificato SSL IIS Express mancante?

Tutte le piattaforme : certificato non attendibile

Per tutte le piattaforme, provare a risolvere i problemi di certificato non attendibili con la procedura seguente:

1. Eseguire i comandi seguenti:

   dotnet dev-certs https --clean
   dotnet dev-certs https --trust
   

2. Chiudere tutte le istanze del browser aperte e aprire l'app in una nuova finestra del browser.

   La cache del browser archivia se un certificato è attendibile. Il processo di chiusura/apertura consente di aggiornare le impostazioni della cache del browser per i certificati.

I dotnet dev-certs https comandi in genere risolvono la maggior parte dei problemi di attendibilità del browser. Se il dotnet dev-certs https --clean comando non riesce e il browser non considera attendibile il certificato, provare i suggerimenti specifici della piattaforma nelle sezioni seguenti.

Docker : certificato non attendibile

Se si usa Docker, provare a risolvere il problema con la procedura seguente:

1. Eliminare la cartella C:\Users{USER}\AppData\Roaming\ASP.NET\Https .

2. Pulire la soluzione. Eliminare le cartelle bin e obj.

3. Riavviare lo strumento di sviluppo. Ad esempio, Visual Studio o Visual Studio Code.

Windows - Certificato non attendibile

Se si lavora in Windows, completare la procedura di risoluzione dei problemi seguente:

1. Controllare i certificati nell'archivio certificati. Cercare un certificato localhost con il nome semplice ASP.NET Core HTTPS development certificate in due cartelle:

   • Certificati personali > utente corrente >
   • Utente corrente > Autorità di certificazione radice attendibili > Certificati

2. Rimuovere tutti i certificati dalle autorità di certificazione radice personali e attendibili.

   Important

   Non rimuovere il certificato localhost di IIS Express.

3. Eseguire i comandi seguenti:

   dotnet dev-certs https --clean
   dotnet dev-certs https --trust
   

4. Chiudere tutte le istanze del browser aperte e aprire l'app in una nuova finestra del browser.

OS X - Certificato non attendibile

Se si usa OS X, provare a risolvere il problema con la procedura seguente:

1. Apri Accesso Portachiavi, quindi seleziona il portachiavi di sistema.

2. Verificare la presenza di un certificato localhost.

3. Verificare che il certificato mostri il segno più (+) sull'icona, che indica che il certificato è attendibile per tutti gli utenti.

4. Rimuovere il certificato dal portachiavi di sistema.

5. Eseguire i comandi seguenti:

   dotnet dev-certs https --clean
   dotnet dev-certs https --trust
   

6. Chiudere tutte le istanze del browser aperte e aprire l'app in una nuova finestra del browser.

Per altre informazioni sulla risoluzione dei problemi relativi ai certificati con Visual Studio, vedere il problema di GitHub dotnet/aspnetcore n. 16892) - Errore HTTPS con IIS Express.

Linux - Certificato non attendibile

Se si esegue Linux, seguire questa procedura per risolvere i problemi relativi al certificato non attendibile:

1. Conferma che il certificato che stai esaminando sia il certificato HTTPS per sviluppatori dell'utente previsto per essere usato dal server Kestrel.

2. Controllare il certificato per sviluppatore Kestrel HTTPS predefinito dell'utente corrente nel percorso seguente:

   ls -la ~/.dotnet/corefx/cryptography/x509stores/my
   

   Il file del certificato di sviluppatore Kestrel HTTPS è l'impronta digitale SHA1. Quando il file viene eliminato con il comando dotnet dev-certs https --clean, il file viene rigenerato quando necessario con un'impronta digitale diversa.

3. Verificare che l’impronta digitale del certificato esportato corrisponda eseguendo il comando seguente:

   openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt
   

   Se l'impronta digitale del certificato non corrisponde, verificare le condizioni seguenti:

   • Controllare se il certificato è obsoleto.

   • Controllare se il certificato è un certificato sviluppatore esportato per l'utente root.

     • In caso affermativo, esportare il certificato.

4. Controlla il certificato dell'utente root nella cartella seguente:

   ls -la /root/.dotnet/corefx/cryptography/x509stores/my
   

Certificato SSL di IIS Express usato con Visual Studio

Per risolvere i problemi relativi al certificato IIS Express, selezionare Repair nel programma di installazione di Visual Studio. Per ulteriori informazioni, vedere il problema GitHub dotnet/aspnetcore n. 16892) - Errore HTTPS con IIS Express.

Il criterio di gruppo impedisce di considerare attendibili i certificati autofirmati

In alcuni casi, i criteri di gruppo possono impedire l'attendibilità dei certificati autofirmati. Per altre informazioni, vedi issue di GitHub dotnet/aspnetcore #21173 - Errore durante l'attendibilità del certificato HTTPS per sviluppatori.

Contenuti correlati

• Configurare ASP.NET Core per l'utilizzo di server proxy e servizi di bilanciamento del carico
• Host ASP.NET Core in Linux con Nginx: configurazione HTTPS
• Configurare SSL in IIS 7 o versione successiva
• Configurare gli endpoint per Kestrel il server Web
• Supporto del browser OWASP HSTS

Il reindirizzamento HTTP a HTTPS causa l'errore ERR_INVALID_REDIRECT nella richiesta preliminare CORS.

Richieste a un endpoint che usano HTTP e che vengono reindirizzate a HTTPS UseHttpsRedirection falliscono con ERR_INVALID_REDIRECT sulla richiesta preliminare CORS.

I progetti API possono rifiutare le richieste HTTP anziché usarle UseHttpsRedirection per reindirizzare le richieste a HTTPS.

Richiedi HTTPS

Consigliamo di usare app Web ASP.NET Core in ambienti di produzione:

• Middleware di reindirizzamento HTTPS (UseHttpsRedirection) per reindirizzare le richieste HTTP a HTTPS.
• Middleware di HSTS (UseHsts) per l'invio delle intestazioni del protocollo di sicurezza HTTP Strict Transport Security (HSTS) ai client.

UseHttpsRedirection

Il codice seguente chiama UseHttpsRedirection nel file Program.cs.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Il codice evidenziato precedente:

• Usa il valore predefinito HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Usa il valore predefinito HttpsRedirectionOptions.HttpsPort (null) a meno che non venga sottoposto a override dalla ASPNETCORE_HTTPS_PORT variabile di ambiente o IServerAddressesFeature.

È consigliabile usare reindirizzamenti temporanei anziché reindirizzamenti permanenti. La memorizzazione nella cache dei collegamenti può causare un comportamento instabile negli ambienti di sviluppo. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente nonDevelopment , vedere la sezione Configurare i reindirizzamenti permanenti nell'ambiente di produzione . È consigliabile usare HSTS per segnalare ai client che devono essere inviate solo richieste di risorse sicure all'app (solo in produzione).

Configurazione della porta

Una porta deve essere disponibile per il middleware per reindirizzare una richiesta non sicura a HTTPS. Se non è disponibile alcuna porta:

• Il reindirizzamento a HTTPS non si verifica.
• Il middleware registra l'avviso "Impossibile determinare la porta https per il reindirizzamento".

Specificare la porta HTTPS usando uno degli approcci seguenti:

• Imposta HttpsRedirectionOptions.HttpsPort.

• Impostare le impostazioni dell'host https_port.

  • Nella configurazione dell'host.

  • Impostando la ASPNETCORE_HTTPS_PORT variabile di ambiente.

  • Aggiungendo una voce di primo livello in appsettings.json:

    {
      "https_port": 443,
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      },
      "AllowedHosts": "*"
    }
    

• Indicare una porta con lo schema sicuro usando la variabile di ambiente ASPNETCORE_URLS. La variabile di ambiente configura il server. Il middleware individua indirettamente la porta HTTPS tramite IServerAddressesFeature. Questo approccio non funziona nelle implementazioni di proxy inversi.

• I modelli web ASP.NET Core configurano un URL HTTPS in Properties/launchsettings.json sia per Kestrel che per IIS Express. launchsettings.json viene usato solo nel computer locale.

• Configurare un endpoint URL HTTPS per una distribuzione perimetrale pubblica del Kestrel server o HTTP.sys server. L'app usa una sola porta HTTPS. Il middleware individua la porta tramite IServerAddressesFeature.

Distribuzioni perimetrali

Quando Kestrel o HTTP.sys viene utilizzato come server perimetrale pubblico, Kestrel o HTTP.sys deve essere configurato per l'ascolto su entrambe le porte richieste.

• Porta sicura in cui viene reindirizzato il client (in genere, 443 nell'ambiente di produzione e 5001 in fase di sviluppo).
• La porta non sicura (in genere 80 in produzione e 5000 in fase di sviluppo).

La porta non sicura deve essere accessibile dal client per consentire all'app di ricevere una richiesta non sicura e reindirizzare il client alla porta protetta.

Per ulteriori informazioni, vedere la configurazione dell'endpoint o l'implementazione del sistema server Web HTTP.sys in ASP.NET Core.

Scenari di distribuzione

Qualsiasi firewall tra il client e il server deve anche avere porte di comunicazione aperte per il traffico.

Se le richieste sono inoltrate in una configurazione di proxy inverso, utilizzare Forwarded Headers Middleware prima di chiamare il middleware di reindirizzamento HTTPS. Il Middleware delle Intestazioni Inoltrate aggiorna Request.Scheme usando l'intestazione X-Forwarded-Proto. Il middleware consente il corretto funzionamento degli URI di reindirizzamento e di altri criteri di sicurezza. Quando il middleware delle intestazioni inoltrate non viene usato, l'applicazione back-end potrebbe non ricevere lo schema corretto e finire in un loop di reindirizzamento. Un messaggio di errore comune dell'utente finale è che si sono verificati troppi reindirizzamenti.

Quando si esegue la distribuzione nel servizio app Azure, seguire le indicazioni riportate in Esercitazione: Associare un certificato SSL personalizzato esistente ad Azure App Web.

Options

Il seguente codice evidenziato chiama AddHttpsRedirection per configurare le opzioni del middleware.

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

La chiamata AddHttpsRedirection è necessaria solo per modificare i valori di HttpsPort o RedirectStatusCode.

Il codice evidenziato precedente:

• Imposta HttpsRedirectionOptions.RedirectStatusCode su Status307TemporaryRedirect, ovvero il valore predefinito. Usare i campi della StatusCodes classe per le assegnazioni a RedirectStatusCode.
• Imposta la porta HTTPS su 5001.

Configurare reindirizzamenti permanenti nell'ambiente di produzione

Il middleware usa per impostazione predefinita l'invio di un oggetto Status307TemporaryRedirect con tutti i reindirizzamenti. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente diverso da Development, avvolgere la configurazione delle opzioni del middleware in un controllo condizionale per un ambiente non-Development.

Quando si configurano i servizi in Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Approccio alternativo al middleware di reindirizzamento HTTPS

Un'alternativa all'uso del middleware di reindirizzamento HTTPS (UseHttpsRedirection) consiste nell'usare il middleware di riscrittura URL (AddRedirectToHttps). AddRedirectToHttps può anche impostare il codice di stato e la porta quando viene eseguito il reindirizzamento. Per ulteriori informazioni, vedere Middleware di riscrittura degli URL.

Quando si reindirizza a HTTPS senza il requisito di regole di reindirizzamento aggiuntive, è consigliabile usare il middleware di reindirizzamento HTTPS (UseHttpsRedirection) descritto in questo articolo.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP, HTTP Strict Transport Security (HSTS) è un miglioramento della sicurezza di consenso esplicito specificato da un'app Web tramite l'uso di un'intestazione di risposta. Quando un browser che supporta HSTS riceve l'intestazione HTTP:

• Il browser archivia la configurazione per il dominio che impedisce l'invio di comunicazioni tramite HTTP. Il browser forza tutte le comunicazioni tramite HTTPS.
• Il browser impedisce all'utente di usare certificati non attendibili o non validi. Il browser disabilita le richieste che consentono a un utente di considerare temporaneamente attendibile tale certificato.

Poiché HSTS viene applicato dal client, presenta alcune limitazioni:

• Il client deve supportare HSTS.
• HSTS richiede almeno una richiesta HTTPS riuscita per stabilire i criteri HSTS.
• L'applicazione deve controllare ogni richiesta HTTP e reindirizzare o rifiutare la richiesta HTTP.

ASP.NET Core implementa HSTS con il UseHsts metodo di estensione. Il codice seguente chiama UseHsts quando l'app non è in modalità di sviluppo:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts non è consigliato in fase di sviluppo perché le impostazioni HSTS sono altamente memorizzabili nella cache dai browser. Per impostazione predefinita, UseHsts esclude l'indirizzo di loopback locale.

Per gli ambienti di produzione che implementano HTTPS per la prima volta, impostare il valore iniziale HstsOptions.MaxAge su un valore ridotto usando uno dei metodi TimeSpan. Impostare il valore da ore a non più di un singolo giorno nel caso in cui sia necessario ripristinare l'infrastruttura HTTPS su HTTP. Dopo aver fiducia nella sostenibilità della configurazione HTTPS, aumentare il valore HSTS max-age ; un valore comunemente usato è un anno.

Il codice evidenziato seguente:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• Imposta il parametro di precaricamento dell'intestazione Strict-Transport-Security. Il precaricamento non fa parte della specifica RFC HSTS, ma è supportato dai browser web per precaricare i siti HSTS in seguito a una nuova installazione. Per ulteriori informazioni, vedere https://hstspreload.org/.
• Abilita includeSubDomain, che applica il criterio HSTS ai sottodomini host.
• Imposta in modo esplicito il max-age parametro dell'intestazione Strict-Transport-Security su 60 giorni. Se non è impostato, il valore predefinito è 30 giorni. Per ulteriori informazioni, vedere la direttiva max-age.
• Aggiunge example.com all'elenco di host da escludere.

UseHsts esclude gli host di loopback seguenti:

• localhost : l'indirizzo di loopback IPv4.
• 127.0.0.1 : l'indirizzo di loopback IPv4.
• [::1] : L'indirizzo di loopback IPv6.

Rifiutare esplicitamente HTTPS/HSTS alla creazione del progetto

In alcuni scenari di servizio back-end in cui la sicurezza della connessione viene gestita nel perimetro pubblico della rete, la configurazione della sicurezza delle connessioni in ogni nodo non è necessaria. Le app Web generate dai modelli in Visual Studio o dal comando dotnet new abilitano il reindirizzamento HTTPS e HSTS. Per le distribuzioni che non richiedono questi scenari, è possibile rifiutare esplicitamente HTTPS/HSTS quando l'app viene creata dal modello.

Per rifiutare esplicitamente HTTPS/HSTS:

dotnet new webapp --no-https

Considerare attendibile il certificato di sviluppo HTTPS di ASP.NET Core in Windows e macOS

Per il browser Firefox, vedere la sezione successiva.

.NET Core SDK include un certificato di sviluppo HTTPS. Il certificato viene installato come parte dell'esperienza di prima esecuzione. Ad esempio, dotnet --info produce una variante dell'output seguente:

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

L'installazione di .NET Core SDK include l'installazione del certificato di sviluppo HTTPS ASP.NET Core nell'archivio certificati utente locale. Il certificato è stato installato, ma non è attendibile. Per considerare attendibile il certificato, eseguire il passaggio una tantum per eseguire lo strumento dotnet dev-certs.

dotnet dev-certs https --trust

Il comando seguente fornisce aiuto sullo strumento dotnet dev-certs:

dotnet dev-certs https --help

Accettare come attendibile il certificato HTTPS con Firefox per evitare l'errore SEC_ERROR_INADEQUATE_KEY_USAGE.

Il browser Firefox usa il proprio archivio certificati e pertanto non considera attendibili i certificati IIS Express o Kestrel developer.

Esistono due approcci per considerare attendibile il certificato HTTPS con Firefox, creare un file di criteri o configurarlo con il browser FireFox. La configurazione con il browser crea il file di criteri, quindi i due approcci sono equivalenti.

Creare un file di criteri per considerare attendibile il certificato HTTPS con Firefox

Crea un file di criteri (policies.json) presso:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• Macos: Firefox.app/Contents/Resources/distribution
• Linux: vedere Considerare attendibile il certificato con Firefox in Linux in questo articolo.

Aggiungere il codice JSON seguente al file dei criteri di Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Il file di criteri precedente fa sì che Firefox consideri attendibili i certificati provenienti dai certificati attendibili nell'archivio certificati di Windows. La sezione successiva fornisce un approccio alternativo per creare il file di criteri precedente usando il browser Firefox.

Configurare l'attendibilità del certificato HTTPS tramite il browser Firefox

Impostare security.enterprise_roots.enabled = true usando le istruzioni seguenti:

1. Immettere about:config nel browser FireFox.
2. Selezionare Accettare il rischio e continuare se si accetta il rischio.
3. Selezionare Mostra tutto
4. Impostare security.enterprise_roots.enabled = true
5. Uscire e riavviare Firefox

Per altre informazioni, vedere Configurazione di autorità di certificazione (CA) in Firefox e il file mozilla/policy-templates/README.

Come configurare un certificato per sviluppatore per Docker

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS in Linux

Stabilire l'attendibilità è specifico alla distribuzione e al browser. Le sezioni seguenti forniscono istruzioni per alcune distribuzioni popolari e i browser Chromium (Edge e Chrome) e per Firefox.

Ubuntu considera attendibile il certificato per la comunicazione da servizio a servizio

Le istruzioni seguenti non funzionano per alcune versioni di Ubuntu, ad esempio 20.04. Per altre informazioni, vedere Problema di GitHub dotnet/AspNetCore.Docs #23686.

1. Installare OpenSSL 1.1.1h o versione successiva. Per istruzioni su come aggiornare OpenSSL, vedere la distribuzione.

2. Eseguire i comandi seguenti:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

I comandi precedenti:

• Verificare che il certificato per sviluppatore dell'utente corrente sia stato creato.
• Esporta il certificato con autorizzazioni elevate necessarie per la ca-certificates cartella, usando l'ambiente dell'utente corrente.
• La rimozione della bandiera -E esporta il certificato utente radice, generandolo se necessario. Ogni certificato appena generato ha un'impronta digitale diversa. Quando si esegue come root, sudo e -E non sono necessari.

Il percorso nel comando precedente è specifico per Ubuntu. Per altre distribuzioni, selezionare un percorso appropriato o usare il percorso per le autorità di certificazione (CA).

Considerare attendibile il certificato HTTPS in Linux usando Edge o Chrome

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

dnf install nss-tools

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Rendere attendibile il certificato con Fedora 34

See:

• Questo commento di GitHub
• Fedora: Uso di certificati di sistema condivisi
• Configurare un ambiente di sviluppo .NET in Fedora.

Considerare attendibile il certificato per altre distribuzioni

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS nel sottosistema Windows per Linux

Le istruzioni seguenti non funzionano per alcune distribuzioni linux, ad esempio Ubuntu 20.04. Per altre informazioni, vedere Problema di GitHub dotnet/AspNetCore.Docs #23686.

Il sottosistema Windows per Linux (WSL) genera un certificato di sviluppo autofirmato HTTPS, che per impostazione predefinita non è attendibile in Windows. Il modo più semplice per considerare attendibile il certificato WSL di Windows consiste nel configurare WSL per l'uso dello stesso certificato di Windows:

• In Windows esportare il certificato per sviluppatore in un file:

  dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
  

  Dove $CREDENTIAL_PLACEHOLDER$ è una password.

• In una finestra WSL importare il certificato esportato nell'istanza WSL:

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

L'approccio precedente è un'operazione da eseguire una sola volta per ogni certificato e per ogni distribuzione WSL. È più semplice che esportare il certificato più volte. Se si aggiorna o si rigenera il certificato in Windows, potrebbe essere necessario eseguire di nuovo i comandi precedenti.

Risolvi i problemi relativi ai certificati, ad esempio il certificato non attendibile

Questa sezione fornisce informazioni utili quando il certificato di sviluppo HTTPS core ASP.NET è stato installato e attendibile, ma sono ancora presenti avvisi del browser che il certificato non è attendibile. Il certificato di sviluppo HTTPS core ASP.NET viene usato da Kestrel.

Per ripristinare il certificato IIS Express, vedere questo problema di Stackoverflow .

Tutte le piattaforme : certificato non attendibile

Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app. L'attendibilità del certificato viene memorizzata nella cache dai browser.

dotnet dev-certs https --clean non riesce

I comandi precedenti risolveranno la maggior parte dei problemi di attendibilità del browser. Se il browser non considera attendibile il certificato, seguire i suggerimenti specifici della piattaforma che seguono.

Docker : certificato non attendibile

• Eliminare la cartella C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
• Pulire la soluzione. Eliminare le cartelle bin e obj.
• Riavviare lo strumento di sviluppo. Ad esempio, Visual Studio o Visual Studio Code.

Windows - Certificato non attendibile

• Controllare i certificati nell'archivio certificati. Deve essere presente un localhost certificato con il ASP.NET Core HTTPS development certificate nome descrittivo sia sotto Current User > Personal > Certificates che sotto Current User > Trusted root certification authorities > Certificates
• Rimuovere tutti i certificati trovati sia dalle autorità di certificazione personali sia da quelle di radice attendibili. Non rimuovere il certificato localhost di IIS Express.
• Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app.

OS X - Certificato non attendibile

• Apri Accesso Portachiavi.
• Selezionare il portachiavi di sistema.
• Verificare la presenza di un certificato localhost.
• Verificare che contenga un + simbolo sull'icona per indicare che è attendibile per tutti gli utenti.
• Rimuovere il certificato dal portachiavi di sistema.
• Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app.

Per la risoluzione dei problemi relativi ai certificati con Visual Studio, vedere Errore HTTPS con IIS Express (dotnet/AspNetCore #16892 ).

Certificato Linux non attendibile

Verificare che il certificato configurato per l'attendibilità sia il certificato per sviluppatore HTTPS utente che verrà usato dal Kestrel server.

Controllare il certificato per sviluppatore Kestrel HTTPS predefinito dell'utente corrente nel percorso seguente:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

Il file del certificato di sviluppatore Kestrel HTTPS è l'impronta digitale SHA1. Quando il file viene eliminato tramite dotnet dev-certs https --clean, viene rigenerato quando necessario con un'impronta digitale diversa. Verificare che l'impronta digitale del certificato esportato corrisponda a quanto ottenuto con il comando seguente.

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Se il certificato non corrisponde, potrebbe essere uno dei seguenti:

• Un certificato precedente.
• Un certificato sviluppatore è stato esportato per l'utente root. In questo caso, esportare il certificato.

Il certificato root utente può essere controllato all'indirizzo:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

Certificato SSL di IIS Express usato con Visual Studio

Per risolvere i problemi relativi al certificato IIS Express, selezionare Ripristina dal programma di installazione di Visual Studio. Per altre informazioni, vedere questo problema in GitHub.

Criteri di gruppo impediscono l'attendibilità dei certificati autofirmati

In alcuni casi, i criteri di gruppo potrebbero impedire l'attendibilità dei certificati autofirmati. Per altre informazioni, vedere questo problema in GitHub.

Informazioni aggiuntive

• Configurare ASP.NET Core per l'utilizzo di server proxy e servizi di bilanciamento del carico
• Host ASP.NET Core in Linux con Nginx: configurazione HTTPS
• Come configurare SSL in IIS
• Configurare gli endpoint per Kestrel il server Web
• Supporto del browser OWASP HSTS

Richiedi HTTPS

Consigliamo di usare app Web ASP.NET Core in ambienti di produzione:

• Middleware di reindirizzamento HTTPS (UseHttpsRedirection) per reindirizzare le richieste HTTP a HTTPS.
• Middleware di HSTS (UseHsts) per l'invio delle intestazioni del protocollo di sicurezza HTTP Strict Transport Security (HSTS) ai client.

UseHttpsRedirection

Il codice seguente chiama UseHttpsRedirection nella classe Startup:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

Il codice evidenziato precedente:

• Usa il valore predefinito HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Usa il valore predefinito HttpsRedirectionOptions.HttpsPort (null) a meno che non venga sottoposto a override dalla ASPNETCORE_HTTPS_PORT variabile di ambiente o IServerAddressesFeature.

È consigliabile usare reindirizzamenti temporanei anziché reindirizzamenti permanenti. La memorizzazione nella cache dei collegamenti può causare un comportamento instabile negli ambienti di sviluppo. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente nonDevelopment , vedere la sezione Configurare i reindirizzamenti permanenti nell'ambiente di produzione . È consigliabile usare HSTS per segnalare ai client che devono essere inviate solo richieste di risorse sicure all'app (solo in produzione).

Configurazione della porta

Una porta deve essere disponibile per il middleware per reindirizzare una richiesta non sicura a HTTPS. Se non è disponibile alcuna porta:

• Il reindirizzamento a HTTPS non si verifica.
• Il middleware registra l'avviso "Impossibile determinare la porta https per il reindirizzamento".

Specificare la porta HTTPS usando uno degli approcci seguenti:

• Imposta HttpsRedirectionOptions.HttpsPort.

• Impostare le impostazioni dell'host https_port.

  • Nella configurazione dell'host.

  • Impostando la ASPNETCORE_HTTPS_PORT variabile di ambiente.

  • Aggiungendo una voce di primo livello in appsettings.json:

    {
        "https_port": 443,
        "Logging": {
            "LogLevel": {
                "Default": "Information",
                "Microsoft": "Warning",
                "Microsoft.Hosting.Lifetime": "Information"
            }
        },
        "AllowedHosts": "*"
    }
    

• Indicare una porta con lo schema sicuro usando la variabile di ambiente ASPNETCORE_URLS. La variabile di ambiente configura il server. Il middleware individua indirettamente la porta HTTPS tramite IServerAddressesFeature. Questo approccio non funziona nelle implementazioni di proxy inversi.

• In fase di sviluppo, configurare un URL HTTPS in launchsettings.json. Abilitare HTTPS quando si usa IIS Express.

• Configurare un endpoint URL HTTPS per una distribuzione perimetrale pubblica del Kestrel server o HTTP.sys server. L'app usa una sola porta HTTPS. Il middleware individua la porta tramite IServerAddressesFeature.

Distribuzioni perimetrali

Quando Kestrel o HTTP.sys viene usato come server perimetrale pubblico, Kestrel o HTTP.sys deve essere configurato per l'ascolto su entrambi:

• Porta sicura in cui viene reindirizzato il client (in genere, 443 nell'ambiente di produzione e 5001 in fase di sviluppo).
• La porta non sicura (in genere 80 in produzione e 5000 in fase di sviluppo).

La porta non sicura deve essere accessibile dal client per consentire all'app di ricevere una richiesta non sicura e reindirizzare il client alla porta protetta.

Per ulteriori informazioni, vedere la configurazione dell'endpoint o l'implementazione del sistema server Web HTTP.sys in ASP.NET Core.

Scenari di distribuzione

Qualsiasi firewall tra il client e il server deve anche avere porte di comunicazione aperte per il traffico.

Se le richieste sono inoltrate in una configurazione di proxy inverso, utilizzare Forwarded Headers Middleware prima di chiamare il middleware di reindirizzamento HTTPS. Il Middleware delle Intestazioni Inoltrate aggiorna Request.Scheme usando l'intestazione X-Forwarded-Proto. Il middleware consente il corretto funzionamento degli URI di reindirizzamento e di altri criteri di sicurezza. Quando il middleware delle intestazioni inoltrate non viene usato, l'applicazione back-end potrebbe non ricevere lo schema corretto e finire in un loop di reindirizzamento. Un messaggio di errore comune dell'utente finale è che si sono verificati troppi reindirizzamenti.

Quando si esegue la distribuzione nel servizio app Azure, seguire le indicazioni riportate in Esercitazione: Associare un certificato SSL personalizzato esistente ad Azure App Web.

Options

Il seguente codice evidenziato chiama AddHttpsRedirection per configurare le opzioni del middleware.

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();

    services.AddHsts(options =>
    {
        options.Preload = true;
        options.IncludeSubDomains = true;
        options.MaxAge = TimeSpan.FromDays(60);
        options.ExcludedHosts.Add("example.com");
        options.ExcludedHosts.Add("www.example.com");
    });

    services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
        options.HttpsPort = 5001;
    });
}

La chiamata AddHttpsRedirection è necessaria solo per modificare i valori di HttpsPort o RedirectStatusCode.

Il codice evidenziato precedente:

• Imposta HttpsRedirectionOptions.RedirectStatusCode su Status307TemporaryRedirect, ovvero il valore predefinito. Usare i campi della StatusCodes classe per le assegnazioni a RedirectStatusCode.
• Imposta la porta HTTPS su 5001.

Configurare reindirizzamenti permanenti nell'ambiente di produzione

Il middleware usa per impostazione predefinita l'invio di un oggetto Status307TemporaryRedirect con tutti i reindirizzamenti. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente diverso da Development, avvolgere la configurazione delle opzioni del middleware in un controllo condizionale per un ambiente non-Development.

Quando si configurano i servizi in Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
    // IWebHostEnvironment (stored in _env) is injected into the Startup class.
    if (!_env.IsDevelopment())
    {
        services.AddHttpsRedirection(options =>
        {
            options.RedirectStatusCode = (int) HttpStatusCode.PermanentRedirect;
            options.HttpsPort = 443;
        });
    }
}

Approccio alternativo al middleware di reindirizzamento HTTPS

Un'alternativa all'uso del middleware di reindirizzamento HTTPS (UseHttpsRedirection) consiste nell'usare il middleware di riscrittura URL (AddRedirectToHttps). AddRedirectToHttps può anche impostare il codice di stato e la porta quando viene eseguito il reindirizzamento. Per ulteriori informazioni, vedere Middleware di riscrittura degli URL.

Quando si reindirizza a HTTPS senza il requisito di regole di reindirizzamento aggiuntive, è consigliabile usare il middleware di reindirizzamento HTTPS (UseHttpsRedirection) descritto in questo articolo.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP, HTTP Strict Transport Security (HSTS) è un miglioramento della sicurezza di consenso esplicito specificato da un'app Web tramite l'uso di un'intestazione di risposta. Quando un browser che supporta HSTS riceve l'intestazione HTTP:

• Il browser archivia la configurazione per il dominio che impedisce l'invio di comunicazioni tramite HTTP. Il browser forza tutte le comunicazioni tramite HTTPS.
• Il browser impedisce all'utente di usare certificati non attendibili o non validi. Il browser disabilita le richieste che consentono a un utente di considerare temporaneamente attendibile tale certificato.

Poiché HSTS viene applicato dal client, presenta alcune limitazioni:

• Il client deve supportare HSTS.
• HSTS richiede almeno una richiesta HTTPS riuscita per stabilire i criteri HSTS.
• L'applicazione deve controllare ogni richiesta HTTP e reindirizzare o rifiutare la richiesta HTTP.

ASP.NET Core implementa HSTS con il UseHsts metodo di estensione. Il codice seguente chiama UseHsts quando l'app non è in modalità di sviluppo:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

UseHsts non è consigliato in fase di sviluppo perché le impostazioni HSTS sono altamente memorizzabili nella cache dai browser. Per impostazione predefinita, UseHsts esclude l'indirizzo di loopback locale.

Per gli ambienti di produzione che implementano HTTPS per la prima volta, impostare il valore iniziale HstsOptions.MaxAge su un valore ridotto usando uno dei metodi TimeSpan. Impostare il valore da ore a non più di un singolo giorno nel caso in cui sia necessario ripristinare l'infrastruttura HTTPS su HTTP. Dopo aver fiducia nella sostenibilità della configurazione HTTPS, aumentare il valore HSTS max-age ; un valore comunemente usato è un anno.

Il codice seguente:

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();

    services.AddHsts(options =>
    {
        options.Preload = true;
        options.IncludeSubDomains = true;
        options.MaxAge = TimeSpan.FromDays(60);
        options.ExcludedHosts.Add("example.com");
        options.ExcludedHosts.Add("www.example.com");
    });

    services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
        options.HttpsPort = 5001;
    });
}

• Imposta il parametro di precaricamento dell'intestazione Strict-Transport-Security. Il precaricamento non fa parte della specifica RFC HSTS, ma è supportato dai browser web per precaricare i siti HSTS in seguito a una nuova installazione. Per ulteriori informazioni, vedere https://hstspreload.org/.
• Abilita includeSubDomain, che applica il criterio HSTS ai sottodomini host.
• Imposta in modo esplicito il max-age parametro dell'intestazione Strict-Transport-Security su 60 giorni. Se non è impostato, il valore predefinito è 30 giorni. Per ulteriori informazioni, vedere la direttiva max-age.
• Aggiunge example.com all'elenco di host da escludere.

UseHsts esclude gli host di loopback seguenti:

• localhost : l'indirizzo di loopback IPv4.
• 127.0.0.1 : l'indirizzo di loopback IPv4.
• [::1] : L'indirizzo di loopback IPv6.

Rifiutare esplicitamente HTTPS/HSTS alla creazione del progetto

In alcuni scenari di servizio back-end in cui la sicurezza della connessione viene gestita nel perimetro pubblico della rete, la configurazione della sicurezza delle connessioni in ogni nodo non è necessaria. Le app Web generate dai modelli in Visual Studio o dal comando dotnet new abilitano il reindirizzamento HTTPS e HSTS. Per le distribuzioni che non richiedono questi scenari, è possibile rifiutare esplicitamente HTTPS/HSTS quando l'app viene creata dal modello.

Per rifiutare esplicitamente HTTPS/HSTS:

dotnet new webapp --no-https

Considerare attendibile il certificato di sviluppo HTTPS di ASP.NET Core in Windows e macOS

Per il browser Firefox, vedere la sezione successiva.

.NET Core SDK include un certificato di sviluppo HTTPS. Il certificato viene installato come parte dell'esperienza di prima esecuzione. Ad esempio, l'esecuzione dotnet new webapp per la prima volta produce una variazione dell'output seguente:

Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'
Learn about HTTPS: https://aka.ms/dotnet-https

L'installazione di .NET Core SDK include l'installazione del certificato di sviluppo HTTPS ASP.NET Core nell'archivio certificati utente locale. Il certificato è stato installato, ma non è attendibile. Per considerare attendibile il certificato, eseguire il passaggio una tantum per eseguire lo strumento dotnet dev-certs.

dotnet dev-certs https --trust

Il comando seguente fornisce aiuto sullo strumento dotnet dev-certs:

dotnet dev-certs https --help

Accettare come attendibile il certificato HTTPS con Firefox per evitare l'errore SEC_ERROR_INADEQUATE_KEY_USAGE.

Il browser Firefox usa il proprio archivio certificati e pertanto non considera attendibili i certificati IIS Express o Kestrel developer.

Esistono due approcci per considerare attendibile il certificato HTTPS con Firefox, creare un file di criteri o configurarlo con il browser FireFox. La configurazione con il browser crea il file di criteri, quindi i due approcci sono equivalenti.

Creare un file di criteri per considerare attendibile il certificato HTTPS con Firefox

Crea un file di criteri (policies.json) presso:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: vedere Considerare attendibile il certificato con Firefox in Linux più avanti in questo articolo.

Aggiungere il codice JSON seguente al file dei criteri di Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Il file di criteri precedente fa sì che Firefox consideri attendibili i certificati provenienti dai certificati attendibili nell'archivio certificati di Windows. La sezione successiva fornisce un approccio alternativo per creare il file di criteri precedente usando il browser Firefox.

Configurare l'attendibilità del certificato HTTPS tramite il browser Firefox

Impostare security.enterprise_roots.enabled = true usando le istruzioni seguenti:

1. Immettere about:config nel browser FireFox.
2. Selezionare Accettare il rischio e continuare se si accetta il rischio.
3. Selezionare Mostra tutto.
4. Impostare security.enterprise_roots.enabled = true.
5. Uscire e riavviare Firefox.

Per altre informazioni, vedere Configurazione di autorità di certificazione (CA) in Firefox e il file mozilla/policy-templates/README.

Come configurare un certificato per sviluppatore per Docker

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS in Linux

Stabilire l'attendibilità è specifico alla distribuzione e al browser. Le sezioni seguenti forniscono istruzioni per alcune distribuzioni popolari e i browser Chromium (Edge e Chrome) e per Firefox.

Ubuntu considera attendibile il certificato per la comunicazione da servizio a servizio

1. Installare OpenSSL 1.1.1h o versione successiva. Per istruzioni su come aggiornare OpenSSL, vedere la distribuzione.

2. Eseguire i comandi seguenti:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

I comandi precedenti:

• Verificare che il certificato per sviluppatore dell'utente corrente sia stato creato.
• Esportare il certificato con autorizzazioni elevate necessarie per la ca-certificates cartella usando l'ambiente dell'utente corrente.
• Rimuovere il -E flag per esportare il certificato utente radice, generandolo se necessario. Ogni certificato appena generato ha un'impronta digitale diversa. Quando si esegue come root, sudo e -E non sono necessari.

Il percorso nel comando precedente è specifico per Ubuntu. Per altre distribuzioni, selezionare un percorso appropriato o usare il percorso per le autorità di certificazione (CA).

Considerare attendibile il certificato HTTPS in Linux usando Edge o Chrome

Per i browser Chromium su Linux:

• Installa il libnss3-tools per la distribuzione.

• Creare o verificare che la $HOME/.pki/nssdb cartella esista nel computer.

• Esportare il certificato con il comando seguente:

  dotnet dev-certs https
  sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
  

  Il percorso nel comando precedente è specifico per Ubuntu. Per altre distribuzioni, selezionare un percorso appropriato o usare il percorso per le autorità di certificazione (CA).

• Eseguire i comandi seguenti:

  certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
  

• Uscire e riavviare il browser.

Considerare attendibile il certificato con Firefox in Linux

• Esportare il certificato con il comando seguente:

  dotnet dev-certs https
  sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
  

  Il percorso nel comando precedente è specifico per Ubuntu. Per altre distribuzioni, selezionare un percorso appropriato o usare il percorso per le autorità di certificazione (CA).

• Creare un file JSON in /usr/lib/firefox/distribution/policies.json con il contenuto seguente:

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

Vedere Configurare l'attendibilità del certificato HTTPS usando il browser Firefox in questo articolo per un modo alternativo per configurare il file di criteri usando il browser.

Rendere attendibile il certificato con Fedora 34

Firefox su Fedora

echo 'pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);' > ./autoconfig.js

echo '//Enable policies.json
lockPref("browser.policies.perUserDir", false);' > firefox.cfg

echo "{
    \"policies\": {
        \"Certificates\": {
            \"Install\": [
                \"aspnetcore-localhost-https.crt\"
            ]
        }
    }
}" > policies.json

dotnet dev-certs https -ep localhost.crt --format PEM

sudo mv autoconfig.js /usr/lib64/firefox/
sudo mv firefox.cfg /usr/lib64/firefox/
sudo mv policies.json /usr/lib64/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt
rm localhost.crt

Autorizza dotnet-to-dotnet su Fedora

sudo cp localhost.crt /etc/pki/tls/certs/localhost.pem
sudo update-ca-trust
rm localhost.crt

Per altre informazioni, vedere questo commento di GitHub.

Considerare attendibile il certificato per altre distribuzioni

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS nel sottosistema Windows per Linux

Il sottosistema Windows per Linux (WSL) genera un certificato di sviluppo autofirmato HTTPS. Per configurare l'archivio certificati di Windows in modo che consideri attendibile il certificato WSL:

• Esportare il certificato per sviluppatore in un file in Windows:

  dotnet dev-certs https -ep C:\<<path-to-folder>>\aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$
  

  Dove $CREDENTIAL_PLACEHOLDER$ è una password.

• In una finestra WSL importare il certificato esportato nell'istanza WSL:

  dotnet dev-certs https --clean --import /mnt/c/<<path-to-folder>>/aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$
  

L'approccio precedente è un'operazione da eseguire una sola volta per ogni certificato e per ogni distribuzione WSL. È più semplice che esportare il certificato più volte. Se si aggiorna o si rigenera il certificato in Windows, potrebbe essere necessario eseguire di nuovo i comandi precedenti.

Risolvi i problemi relativi ai certificati, ad esempio il certificato non attendibile

Questa sezione fornisce informazioni utili quando il certificato di sviluppo HTTPS core ASP.NET è stato installato e attendibile, ma sono ancora presenti avvisi del browser che il certificato non è attendibile. Il certificato di sviluppo HTTPS core ASP.NET viene usato da Kestrel.

Per ripristinare il certificato IIS Express, vedere questo problema di Stackoverflow .

Tutte le piattaforme : certificato non attendibile

Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app. L'attendibilità del certificato viene memorizzata nella cache dai browser.

dotnet dev-certs https --clean fallisce

I comandi precedenti risolveranno la maggior parte dei problemi di attendibilità del browser. Se il browser non considera attendibile il certificato, seguire i suggerimenti specifici della piattaforma che seguono.

Docker : certificato non attendibile

• Eliminare la cartella C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
• Pulire la soluzione. Eliminare le cartelle bin e obj.
• Riavviare lo strumento di sviluppo. Ad esempio, Visual Studio, Visual Studio Code o Visual Studio per Mac.

Windows - Certificato non attendibile

• Controllare i certificati nell'archivio certificati. Deve essere presente un localhost certificato con il ASP.NET Core HTTPS development certificate nome descrittivo sia sotto Current User > Personal > Certificates che sotto Current User > Trusted root certification authorities > Certificates
• Rimuovere tutti i certificati trovati sia dalle autorità di certificazione personali sia da quelle di radice attendibili. Non rimuovere il certificato localhost di IIS Express.
• Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app. L'attendibilità del certificato viene memorizzata nella cache dai browser.

OS X - Certificato non attendibile

• Apri Accesso Portachiavi.
• Selezionare il portachiavi di sistema.
• Verificare la presenza di un certificato localhost.
• Verificare che contenga un + simbolo sull'icona per indicare che è attendibile per tutti gli utenti.
• Rimuovere il certificato dal portachiavi di sistema.
• Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app. L'attendibilità del certificato viene memorizzata nella cache dai browser.

Per la risoluzione dei problemi relativi ai certificati con Visual Studio, vedere Errore HTTPS con IIS Express (dotnet/AspNetCore #16892 ).

Certificato Linux non attendibile

Verificare che il certificato configurato per l'attendibilità sia il certificato per sviluppatore HTTPS utente che verrà usato dal Kestrel server.

Controllare il certificato per sviluppatore Kestrel HTTPS predefinito dell'utente corrente nel percorso seguente:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

Il file del certificato di sviluppatore Kestrel HTTPS è l'impronta digitale SHA1. Quando il file viene eliminato tramite dotnet dev-certs https --clean, viene rigenerato quando necessario con un'impronta digitale diversa. Verificare che l'impronta digitale del certificato esportato corrisponda a quanto ottenuto con il comando seguente.

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Se il certificato non corrisponde, potrebbe essere uno dei seguenti:

• Un certificato precedente.
• Un certificato sviluppatore è stato esportato per l'utente root. In questo caso, esportare il certificato.

Il certificato root utente può essere controllato all'indirizzo:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

Certificato SSL di IIS Express usato con Visual Studio

Per risolvere i problemi relativi al certificato IIS Express, selezionare Ripristina dal programma di installazione di Visual Studio. Per altre informazioni, vedere questo problema in GitHub.

Informazioni aggiuntive

• Configurare ASP.NET Core per l'utilizzo di server proxy e servizi di bilanciamento del carico
• Host ASP.NET Core in Linux con Nginx: configurazione HTTPS
• Come configurare SSL in IIS
• Supporto del browser OWASP HSTS
• dotnet dev-certs

Il reindirizzamento HTTP a HTTPS causa l'errore ERR_INVALID_REDIRECT nella richiesta preliminare CORS.

Richieste a un endpoint che usano HTTP e che vengono reindirizzate a HTTPS UseHttpsRedirection falliscono con ERR_INVALID_REDIRECT sulla richiesta preliminare CORS.

I progetti API possono rifiutare le richieste HTTP anziché usarle UseHttpsRedirection per reindirizzare le richieste a HTTPS.

Richiedi HTTPS

Consigliamo di usare app Web ASP.NET Core in ambienti di produzione:

• Middleware di reindirizzamento HTTPS (UseHttpsRedirection) per reindirizzare le richieste HTTP a HTTPS.
• Middleware di HSTS (UseHsts) per l'invio delle intestazioni del protocollo di sicurezza HTTP Strict Transport Security (HSTS) ai client.

UseHttpsRedirection

Il codice seguente chiama UseHttpsRedirection nel file Program.cs.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Il codice evidenziato precedente:

• Usa il valore predefinito HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Usa il valore predefinito HttpsRedirectionOptions.HttpsPort (null) a meno che non venga sottoposto a override dalla ASPNETCORE_HTTPS_PORT variabile di ambiente o IServerAddressesFeature.

È consigliabile usare reindirizzamenti temporanei anziché reindirizzamenti permanenti. La memorizzazione nella cache dei collegamenti può causare un comportamento instabile negli ambienti di sviluppo. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente nonDevelopment , vedere la sezione Configurare i reindirizzamenti permanenti nell'ambiente di produzione . È consigliabile usare HSTS per segnalare ai client che devono essere inviate solo richieste di risorse sicure all'app (solo in produzione).

Configurazione della porta

Una porta deve essere disponibile per il middleware per reindirizzare una richiesta non sicura a HTTPS. Se non è disponibile alcuna porta:

• Il reindirizzamento a HTTPS non si verifica.
• Il middleware registra l'avviso "Impossibile determinare la porta https per il reindirizzamento".

Specificare la porta HTTPS usando uno degli approcci seguenti:

• Imposta HttpsRedirectionOptions.HttpsPort.

• Impostare le impostazioni dell'host https_port.

  • Nella configurazione dell'host.

  • Impostando la ASPNETCORE_HTTPS_PORT variabile di ambiente.

  • Aggiungendo una voce di primo livello in appsettings.json:

    {
      "https_port": 443,
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      },
      "AllowedHosts": "*"
    }
    

• Indicare una porta con lo schema sicuro usando la variabile di ambiente ASPNETCORE_URLS. La variabile di ambiente configura il server. Il middleware individua indirettamente la porta HTTPS tramite IServerAddressesFeature. Questo approccio non funziona nelle implementazioni di proxy inversi.

• I modelli web ASP.NET Core configurano un URL HTTPS in Properties/launchsettings.json sia per Kestrel che per IIS Express. launchsettings.json viene usato solo nel computer locale.

• Configurare un endpoint URL HTTPS per una distribuzione perimetrale pubblica del Kestrel server o HTTP.sys server. L'app usa una sola porta HTTPS. Il middleware individua la porta tramite IServerAddressesFeature.

Distribuzioni perimetrali

Quando Kestrel o HTTP.sys viene utilizzato come server perimetrale pubblico, Kestrel o HTTP.sys deve essere configurato per l'ascolto su entrambe le porte richieste.

• Porta sicura in cui viene reindirizzato il client (in genere, 443 nell'ambiente di produzione e 5001 in fase di sviluppo).
• La porta non sicura (in genere 80 in produzione e 5000 in fase di sviluppo).

La porta non sicura deve essere accessibile dal client per consentire all'app di ricevere una richiesta non sicura e reindirizzare il client alla porta protetta.

Per ulteriori informazioni, vedere la configurazione dell'endpoint o l'implementazione del sistema server Web HTTP.sys in ASP.NET Core.

Scenari di distribuzione

Qualsiasi firewall tra il client e il server deve anche avere porte di comunicazione aperte per il traffico.

Se le richieste sono inoltrate in una configurazione di proxy inverso, utilizzare Forwarded Headers Middleware prima di chiamare il middleware di reindirizzamento HTTPS. Il Middleware delle Intestazioni Inoltrate aggiorna Request.Scheme usando l'intestazione X-Forwarded-Proto. Il middleware consente il corretto funzionamento degli URI di reindirizzamento e di altri criteri di sicurezza. Quando il middleware delle intestazioni inoltrate non viene usato, l'applicazione back-end potrebbe non ricevere lo schema corretto e finire in un loop di reindirizzamento. Un messaggio di errore comune dell'utente finale è che si sono verificati troppi reindirizzamenti.

Quando si esegue la distribuzione nel servizio app Azure, seguire le indicazioni riportate in Esercitazione: Associare un certificato SSL personalizzato esistente ad Azure App Web.

Options

Il seguente codice evidenziato chiama AddHttpsRedirection per configurare le opzioni del middleware.

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

La chiamata AddHttpsRedirection è necessaria solo per modificare i valori di HttpsPort o RedirectStatusCode.

Il codice evidenziato precedente:

• Imposta HttpsRedirectionOptions.RedirectStatusCode su Status307TemporaryRedirect, ovvero il valore predefinito. Usare i campi della StatusCodes classe per le assegnazioni a RedirectStatusCode.
• Imposta la porta HTTPS su 5001.

Configurare reindirizzamenti permanenti nell'ambiente di produzione

Il middleware usa per impostazione predefinita l'invio di un oggetto Status307TemporaryRedirect con tutti i reindirizzamenti. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente diverso da Development, avvolgere la configurazione delle opzioni del middleware in un controllo condizionale per un ambiente non-Development.

Quando si configurano i servizi in Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Approccio alternativo al middleware di reindirizzamento HTTPS

Un'alternativa all'uso del middleware di reindirizzamento HTTPS (UseHttpsRedirection) consiste nell'usare il middleware di riscrittura URL (AddRedirectToHttps). AddRedirectToHttps può anche impostare il codice di stato e la porta quando viene eseguito il reindirizzamento. Per ulteriori informazioni, vedere Middleware di riscrittura degli URL.

Quando si reindirizza a HTTPS senza il requisito di regole di reindirizzamento aggiuntive, è consigliabile usare il middleware di reindirizzamento HTTPS (UseHttpsRedirection) descritto in questo articolo.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP, HTTP Strict Transport Security (HSTS) è un miglioramento della sicurezza di consenso esplicito specificato da un'app Web tramite l'uso di un'intestazione di risposta. Quando un browser che supporta HSTS riceve l'intestazione HTTP:

• Il browser archivia la configurazione per il dominio che impedisce l'invio di comunicazioni tramite HTTP. Il browser forza tutte le comunicazioni tramite HTTPS.
• Il browser impedisce all'utente di usare certificati non attendibili o non validi. Il browser disabilita le richieste che consentono a un utente di considerare temporaneamente attendibile tale certificato.

Poiché HSTS viene applicato dal client, presenta alcune limitazioni:

• Il client deve supportare HSTS.
• HSTS richiede almeno una richiesta HTTPS riuscita per stabilire i criteri HSTS.
• L'applicazione deve controllare ogni richiesta HTTP e reindirizzare o rifiutare la richiesta HTTP.

ASP.NET Core implementa HSTS con il UseHsts metodo di estensione. Il codice seguente chiama UseHsts quando l'app non è in modalità di sviluppo:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts non è consigliato in fase di sviluppo perché le impostazioni HSTS sono altamente memorizzabili nella cache dai browser. Per impostazione predefinita, UseHsts esclude l'indirizzo di loopback locale.

Per gli ambienti di produzione che implementano HTTPS per la prima volta, impostare il valore iniziale HstsOptions.MaxAge su un valore ridotto usando uno dei metodi TimeSpan. Impostare il valore da ore a non più di un singolo giorno nel caso in cui sia necessario ripristinare l'infrastruttura HTTPS su HTTP. Dopo aver fiducia nella sostenibilità della configurazione HTTPS, aumentare il valore HSTS max-age ; un valore comunemente usato è un anno.

Il codice evidenziato seguente:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• Imposta il parametro di precaricamento dell'intestazione Strict-Transport-Security. Il precaricamento non fa parte della specifica RFC HSTS, ma è supportato dai browser web per precaricare i siti HSTS in seguito a una nuova installazione. Per ulteriori informazioni, vedere https://hstspreload.org/.
• Abilita includeSubDomain, che applica il criterio HSTS ai sottodomini host.
• Imposta in modo esplicito il max-age parametro dell'intestazione Strict-Transport-Security su 60 giorni. Se non è impostato, il valore predefinito è 30 giorni. Per ulteriori informazioni, vedere la direttiva max-age.
• Aggiunge example.com all'elenco di host da escludere.

UseHsts esclude gli host di loopback seguenti:

• localhost : l'indirizzo di loopback IPv4.
• 127.0.0.1 : l'indirizzo di loopback IPv4.
• [::1] : L'indirizzo di loopback IPv6.

Rifiutare esplicitamente HTTPS/HSTS alla creazione del progetto

In alcuni scenari di servizio back-end in cui la sicurezza della connessione viene gestita nel perimetro pubblico della rete, la configurazione della sicurezza delle connessioni in ogni nodo non è necessaria. Le app Web generate dai modelli in Visual Studio o dal comando dotnet new abilitano il reindirizzamento HTTPS e HSTS. Per le distribuzioni che non richiedono questi scenari, è possibile rifiutare esplicitamente HTTPS/HSTS quando l'app viene creata dal modello.

Per rifiutare esplicitamente HTTPS/HSTS:

dotnet new webapp --no-https

Considerare attendibile il certificato di sviluppo HTTPS di ASP.NET Core in Windows e macOS

Per il browser Firefox, vedere la sezione successiva.

.NET Core SDK include un certificato di sviluppo HTTPS. Il certificato viene installato come parte dell'esperienza di prima esecuzione. Ad esempio, dotnet --info produce una variante dell'output seguente:

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

L'installazione di .NET Core SDK include l'installazione del certificato di sviluppo HTTPS ASP.NET Core nell'archivio certificati utente locale. Il certificato è stato installato, ma non è attendibile. Per considerare attendibile il certificato, eseguire il passaggio una tantum per eseguire lo strumento dotnet dev-certs.

dotnet dev-certs https --trust

Il comando seguente fornisce aiuto sullo strumento dotnet dev-certs:

dotnet dev-certs https --help

Accettare come attendibile il certificato HTTPS con Firefox per evitare l'errore SEC_ERROR_INADEQUATE_KEY_USAGE.

Il browser Firefox usa il proprio archivio certificati e pertanto non considera attendibili i certificati IIS Express o Kestrel developer.

Esistono due approcci per considerare attendibile il certificato HTTPS con Firefox, creare un file di criteri o configurarlo con il browser FireFox. La configurazione con il browser crea il file di criteri, quindi i due approcci sono equivalenti.

Creare un file di criteri per considerare attendibile il certificato HTTPS con Firefox

Crea un file di criteri (policies.json) presso:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: vedere Considerare attendibile il certificato con Firefox in Linux in questo articolo.

Aggiungere il codice JSON seguente al file dei criteri di Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Il file di criteri precedente fa sì che Firefox consideri attendibili i certificati provenienti dai certificati attendibili nell'archivio certificati di Windows. La sezione successiva fornisce un approccio alternativo per creare il file di criteri precedente usando il browser Firefox.

Configurare l'attendibilità del certificato HTTPS tramite il browser Firefox

Impostare security.enterprise_roots.enabled = true usando le istruzioni seguenti:

1. Immettere about:config nel browser FireFox.
2. Selezionare Accettare il rischio e continuare se si accetta il rischio.
3. Selezionare Mostra tutto
4. Impostare security.enterprise_roots.enabled = true
5. Uscire e riavviare Firefox

Per altre informazioni, vedere Configurazione di autorità di certificazione (CA) in Firefox e il file mozilla/policy-templates/README.

Come configurare un certificato per sviluppatore per Docker

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS in Linux

Stabilire l'attendibilità è specifico alla distribuzione e al browser. Le sezioni seguenti forniscono istruzioni per alcune distribuzioni popolari e i browser Chromium (Edge e Chrome) e per Firefox.

Ubuntu considera attendibile il certificato per la comunicazione da servizio a servizio

Le istruzioni seguenti non funzionano per alcune versioni di Ubuntu, ad esempio 20.04. Per altre informazioni, vedere Problema di GitHub dotnet/AspNetCore.Docs #23686.

1. Installare OpenSSL 1.1.1h o versione successiva. Per istruzioni su come aggiornare OpenSSL, vedere la distribuzione.

2. Eseguire i comandi seguenti:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

I comandi precedenti:

• Verificare che il certificato per sviluppatore dell'utente corrente sia stato creato.
• Esporta il certificato con autorizzazioni elevate necessarie per la ca-certificates cartella, usando l'ambiente dell'utente corrente.
• La rimozione della bandiera -E esporta il certificato utente radice, generandolo se necessario. Ogni certificato appena generato ha un'impronta digitale diversa. Quando si esegue come root, sudo e -E non sono necessari.

Il percorso nel comando precedente è specifico per Ubuntu. Per altre distribuzioni, selezionare un percorso appropriato o usare il percorso per le autorità di certificazione (CA).

Considerare attendibile il certificato HTTPS in Linux usando Edge o Chrome

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

dnf install nss-tools

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Rendere attendibile il certificato con Fedora 34

See:

• Questo commento di GitHub
• Fedora: Uso di certificati di sistema condivisi
• Configurare un ambiente di sviluppo .NET in Fedora.

Considerare attendibile il certificato per altre distribuzioni

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS nel sottosistema Windows per Linux

Le istruzioni seguenti non funzionano per alcune distribuzioni linux, ad esempio Ubuntu 20.04. Per altre informazioni, vedere Problema di GitHub dotnet/AspNetCore.Docs #23686.

Il sottosistema Windows per Linux (WSL) genera un certificato di sviluppo autofirmato HTTPS, che per impostazione predefinita non è attendibile in Windows. Il modo più semplice per considerare attendibile il certificato WSL di Windows consiste nel configurare WSL per l'uso dello stesso certificato di Windows:

• In Windows esportare il certificato per sviluppatore in un file:

  dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
  

  Dove $CREDENTIAL_PLACEHOLDER$ è una password.

• In una finestra WSL importare il certificato esportato nell'istanza WSL:

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

L'approccio precedente è un'operazione da eseguire una sola volta per ogni certificato e per ogni distribuzione WSL. È più semplice che esportare il certificato più volte. Se si aggiorna o si rigenera il certificato in Windows, potrebbe essere necessario eseguire di nuovo i comandi precedenti.

Risolvi i problemi relativi ai certificati, ad esempio il certificato non attendibile

Questa sezione fornisce informazioni utili quando il certificato di sviluppo HTTPS core ASP.NET è stato installato e attendibile, ma sono ancora presenti avvisi del browser che il certificato non è attendibile. Il certificato di sviluppo HTTPS core ASP.NET viene usato da Kestrel.

Per ripristinare il certificato IIS Express, vedere questo problema di Stackoverflow .

Tutte le piattaforme : certificato non attendibile

Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app. L'attendibilità del certificato viene memorizzata nella cache dai browser.

dotnet dev-certs https --clean non riesce

I comandi precedenti risolveranno la maggior parte dei problemi di attendibilità del browser. Se il browser non considera attendibile il certificato, seguire i suggerimenti specifici della piattaforma che seguono.

Docker : certificato non attendibile

• Eliminare la cartella C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
• Pulire la soluzione. Eliminare le cartelle bin e obj.
• Riavviare lo strumento di sviluppo. Ad esempio, Visual Studio o Visual Studio Code.

Windows - Certificato non attendibile

• Controllare i certificati nell'archivio certificati. Deve essere presente un localhost certificato con il ASP.NET Core HTTPS development certificate nome descrittivo sia sotto Current User > Personal > Certificates che sotto Current User > Trusted root certification authorities > Certificates
• Rimuovere tutti i certificati trovati sia dalle autorità di certificazione personali sia da quelle di radice attendibili. Non rimuovere il certificato localhost di IIS Express.
• Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app.

OS X - Certificato non attendibile

• Apri Accesso Portachiavi.
• Selezionare il portachiavi di sistema.
• Verificare la presenza di un certificato localhost.
• Verificare che contenga un + simbolo sull'icona per indicare che è attendibile per tutti gli utenti.
• Rimuovere il certificato dal portachiavi di sistema.
• Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app.

Per la risoluzione dei problemi relativi ai certificati con Visual Studio, vedere Errore HTTPS con IIS Express (dotnet/AspNetCore #16892 ).

Certificato Linux non attendibile

Verificare che il certificato configurato per l'attendibilità sia il certificato per sviluppatore HTTPS utente che verrà usato dal Kestrel server.

Controllare il certificato per sviluppatore Kestrel HTTPS predefinito dell'utente corrente nel percorso seguente:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

Il file del certificato di sviluppatore Kestrel HTTPS è l'impronta digitale SHA1. Quando il file viene eliminato tramite dotnet dev-certs https --clean, viene rigenerato quando necessario con un'impronta digitale diversa. Verificare che l'impronta digitale del certificato esportato corrisponda a quanto ottenuto con il comando seguente.

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Se il certificato non corrisponde, potrebbe essere uno dei seguenti:

• Un certificato precedente.
• Un certificato sviluppatore è stato esportato per l'utente root. In questo caso, esportare il certificato.

Il certificato root utente può essere controllato all'indirizzo:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

Certificato SSL di IIS Express usato con Visual Studio

Per risolvere i problemi relativi al certificato IIS Express, selezionare Ripristina dal programma di installazione di Visual Studio. Per altre informazioni, vedere questo problema in GitHub.

Criteri di gruppo impediscono l'attendibilità dei certificati autofirmati

In alcuni casi, i criteri di gruppo potrebbero impedire l'attendibilità dei certificati autofirmati. Per altre informazioni, vedere questo problema in GitHub.

Informazioni aggiuntive

• Configurare ASP.NET Core per l'utilizzo di server proxy e servizi di bilanciamento del carico
• Host ASP.NET Core in Linux con Nginx: configurazione HTTPS
• Come configurare SSL in IIS
• Configurare gli endpoint per Kestrel il server Web
• Supporto del browser OWASP HSTS

Il reindirizzamento HTTP a HTTPS causa l'errore ERR_INVALID_REDIRECT nella richiesta preliminare CORS.

Richieste a un endpoint che usano HTTP e che vengono reindirizzate a HTTPS UseHttpsRedirection falliscono con ERR_INVALID_REDIRECT sulla richiesta preliminare CORS.

I progetti API possono rifiutare le richieste HTTP anziché usarle UseHttpsRedirection per reindirizzare le richieste a HTTPS.

Richiedi HTTPS

Consigliamo di usare app Web ASP.NET Core in ambienti di produzione:

• Middleware di reindirizzamento HTTPS (UseHttpsRedirection) per reindirizzare le richieste HTTP a HTTPS.
• Middleware di HSTS (UseHsts) per l'invio delle intestazioni del protocollo di sicurezza HTTP Strict Transport Security (HSTS) ai client.

UseHttpsRedirection

Il codice seguente chiama UseHttpsRedirection nel file Program.cs.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Il codice evidenziato precedente:

• Usa il valore predefinito HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Usa il valore predefinito HttpsRedirectionOptions.HttpsPort (null) a meno che non venga sottoposto a override dalla ASPNETCORE_HTTPS_PORT variabile di ambiente o IServerAddressesFeature.

È consigliabile usare reindirizzamenti temporanei anziché reindirizzamenti permanenti. La memorizzazione nella cache dei collegamenti può causare un comportamento instabile negli ambienti di sviluppo. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente nonDevelopment , vedere la sezione Configurare i reindirizzamenti permanenti nell'ambiente di produzione . È consigliabile usare HSTS per segnalare ai client che devono essere inviate solo richieste di risorse sicure all'app (solo in produzione).

Configurazione della porta

Una porta deve essere disponibile per il middleware per reindirizzare una richiesta non sicura a HTTPS. Se non è disponibile alcuna porta:

• Il reindirizzamento a HTTPS non si verifica.
• Il middleware registra l'avviso "Impossibile determinare la porta https per il reindirizzamento".

Specificare la porta HTTPS usando uno degli approcci seguenti:

• Imposta HttpsRedirectionOptions.HttpsPort.

• Impostare le impostazioni dell'host https_port.

  • Nella configurazione dell'host.

  • Impostando la ASPNETCORE_HTTPS_PORT variabile di ambiente.

  • Aggiungendo una voce di primo livello in appsettings.json:

    {
      "https_port": 443,
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      },
      "AllowedHosts": "*"
    }
    

• Indicare una porta con lo schema sicuro usando la variabile di ambiente ASPNETCORE_URLS. La variabile di ambiente configura il server. Il middleware individua indirettamente la porta HTTPS tramite IServerAddressesFeature. Questo approccio non funziona nelle implementazioni di proxy inversi.

• I modelli web ASP.NET Core configurano un URL HTTPS in Properties/launchsettings.json sia per Kestrel che per IIS Express. launchsettings.json viene usato solo nel computer locale.

• Configurare un endpoint URL HTTPS per una distribuzione perimetrale pubblica del Kestrel server o HTTP.sys server. L'app usa una sola porta HTTPS. Il middleware individua la porta tramite IServerAddressesFeature.

Distribuzioni perimetrali

Quando Kestrel o HTTP.sys viene utilizzato come server perimetrale pubblico, Kestrel o HTTP.sys deve essere configurato per l'ascolto su entrambe le porte richieste.

• Porta sicura in cui viene reindirizzato il client (in genere, 443 nell'ambiente di produzione e 5001 in fase di sviluppo).
• La porta non sicura (in genere 80 in produzione e 5000 in fase di sviluppo).

La porta non sicura deve essere accessibile dal client per consentire all'app di ricevere una richiesta non sicura e reindirizzare il client alla porta protetta.

Per ulteriori informazioni, vedere la configurazione dell'endpoint o l'implementazione del sistema server Web HTTP.sys in ASP.NET Core.

Scenari di distribuzione

Qualsiasi firewall tra il client e il server deve anche avere porte di comunicazione aperte per il traffico.

Se le richieste sono inoltrate in una configurazione di proxy inverso, utilizzare Forwarded Headers Middleware prima di chiamare il middleware di reindirizzamento HTTPS. Il Middleware delle Intestazioni Inoltrate aggiorna Request.Scheme usando l'intestazione X-Forwarded-Proto. Il middleware consente il corretto funzionamento degli URI di reindirizzamento e di altri criteri di sicurezza. Quando il middleware delle intestazioni inoltrate non viene usato, l'applicazione back-end potrebbe non ricevere lo schema corretto e finire in un loop di reindirizzamento. Un messaggio di errore comune dell'utente finale è che si sono verificati troppi reindirizzamenti.

Quando si esegue la distribuzione nel servizio app Azure, seguire le indicazioni riportate in Esercitazione: Associare un certificato SSL personalizzato esistente ad Azure App Web.

Options

Il seguente codice evidenziato chiama AddHttpsRedirection per configurare le opzioni del middleware.

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

La chiamata AddHttpsRedirection è necessaria solo per modificare i valori di HttpsPort o RedirectStatusCode.

Il codice evidenziato precedente:

• Imposta HttpsRedirectionOptions.RedirectStatusCode su Status307TemporaryRedirect, ovvero il valore predefinito. Usare i campi della StatusCodes classe per le assegnazioni a RedirectStatusCode.
• Imposta la porta HTTPS su 5001.

Configurare reindirizzamenti permanenti nell'ambiente di produzione

Il middleware usa per impostazione predefinita l'invio di un oggetto Status307TemporaryRedirect con tutti i reindirizzamenti. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente diverso da Development, avvolgere la configurazione delle opzioni del middleware in un controllo condizionale per un ambiente non-Development.

Quando si configurano i servizi in Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Approccio alternativo al middleware di reindirizzamento HTTPS

Un'alternativa all'uso del middleware di reindirizzamento HTTPS (UseHttpsRedirection) consiste nell'usare il middleware di riscrittura URL (AddRedirectToHttps). AddRedirectToHttps può anche impostare il codice di stato e la porta quando viene eseguito il reindirizzamento. Per ulteriori informazioni, vedere Middleware di riscrittura degli URL.

Quando si reindirizza a HTTPS senza il requisito di regole di reindirizzamento aggiuntive, è consigliabile usare il middleware di reindirizzamento HTTPS (UseHttpsRedirection) descritto in questo articolo.

HTTP Strict Transport Security Protocol (HSTS)

Per OWASP, HTTP Strict Transport Security (HSTS) è un miglioramento della sicurezza di consenso esplicito specificato da un'app Web tramite l'uso di un'intestazione di risposta. Quando un browser che supporta HSTS riceve l'intestazione HTTP:

• Il browser archivia la configurazione per il dominio che impedisce l'invio di comunicazioni tramite HTTP. Il browser forza tutte le comunicazioni tramite HTTPS.
• Il browser impedisce all'utente di usare certificati non attendibili o non validi. Il browser disabilita le richieste che consentono a un utente di considerare temporaneamente attendibile tale certificato.

Poiché HSTS viene applicato dal client, presenta alcune limitazioni:

• Il client deve supportare HSTS.
• HSTS richiede almeno una richiesta HTTPS riuscita per stabilire i criteri HSTS.
• L'applicazione deve controllare ogni richiesta HTTP e reindirizzare o rifiutare la richiesta HTTP.

ASP.NET Core implementa HSTS con il UseHsts metodo di estensione. Il codice seguente chiama UseHsts quando l'app non è in modalità di sviluppo:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts non è consigliato in fase di sviluppo perché le impostazioni HSTS sono altamente memorizzabili nella cache dai browser. Per impostazione predefinita, UseHsts esclude l'indirizzo di loopback locale.

Per gli ambienti di produzione che implementano HTTPS per la prima volta, impostare il valore iniziale HstsOptions.MaxAge su un valore ridotto usando uno dei metodi TimeSpan. Impostare il valore da ore a non più di un singolo giorno nel caso in cui sia necessario ripristinare l'infrastruttura HTTPS su HTTP. Dopo aver fiducia nella sostenibilità della configurazione HTTPS, aumentare il valore HSTS max-age ; un valore comunemente usato è un anno.

Il codice evidenziato seguente:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• Imposta il parametro di precaricamento dell'intestazione Strict-Transport-Security. Il precaricamento non fa parte della specifica RFC HSTS, ma è supportato dai browser web per precaricare i siti HSTS in seguito a una nuova installazione. Per ulteriori informazioni, vedere https://hstspreload.org/.
• Abilita includeSubDomain, che applica il criterio HSTS ai sottodomini host.
• Imposta in modo esplicito il max-age parametro dell'intestazione Strict-Transport-Security su 60 giorni. Se non è impostato, il valore predefinito è 30 giorni. Per ulteriori informazioni, vedere la direttiva max-age.
• Aggiunge example.com all'elenco di host da escludere.

UseHsts esclude gli host di loopback seguenti:

• localhost : l'indirizzo di loopback IPv4.
• 127.0.0.1 : l'indirizzo di loopback IPv4.
• [::1] : L'indirizzo di loopback IPv6.

Rifiutare esplicitamente HTTPS/HSTS alla creazione del progetto

In alcuni scenari di servizio back-end in cui la sicurezza della connessione viene gestita nel perimetro pubblico della rete, la configurazione della sicurezza delle connessioni in ogni nodo non è necessaria. Le app Web generate dai modelli in Visual Studio o dal comando dotnet new abilitano il reindirizzamento HTTPS e HSTS. Per le distribuzioni che non richiedono questi scenari, è possibile rifiutare esplicitamente HTTPS/HSTS quando l'app viene creata dal modello.

Per rifiutare esplicitamente HTTPS/HSTS:

dotnet new webapp --no-https

Considerare attendibile il certificato di sviluppo HTTPS di ASP.NET Core in Windows e macOS

Per il browser Firefox, vedere la sezione successiva.

.NET SDK include un certificato di sviluppo HTTPS. Il certificato viene installato come parte dell'esperienza di prima esecuzione. Ad esempio, dotnet --info produce una variante dell'output seguente:

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

L'installazione di .NET SDK installa il certificato di sviluppo HTTPS di ASP.NET Core nell'archivio certificati utente locale. Il certificato è stato installato, ma non è attendibile. Per considerare attendibile il certificato, eseguire il passaggio una tantum per eseguire lo strumento dotnet dev-certs.

dotnet dev-certs https --trust

Il comando seguente fornisce aiuto sullo strumento dotnet dev-certs:

dotnet dev-certs https --help

Accettare come attendibile il certificato HTTPS con Firefox per evitare l'errore SEC_ERROR_INADEQUATE_KEY_USAGE.

Il browser Firefox usa il proprio archivio certificati e pertanto non considera attendibili i certificati IIS Express o Kestrel developer.

Esistono due approcci per considerare attendibile il certificato HTTPS con Firefox, creare un file di criteri o configurarlo con il browser FireFox. La configurazione con il browser crea il file di criteri, quindi i due approcci sono equivalenti.

Creare un file di criteri per considerare attendibile il certificato HTTPS con Firefox

Crea un file di criteri (policies.json) presso:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: vedere Considerare attendibile il certificato con Firefox in Linux in questo articolo.

Aggiungere il codice JSON seguente al file dei criteri di Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

Il file di criteri precedente fa sì che Firefox consideri attendibili i certificati provenienti dai certificati attendibili nell'archivio certificati di Windows. La sezione successiva fornisce un approccio alternativo per creare il file di criteri precedente usando il browser Firefox.

Configurare l'attendibilità del certificato HTTPS tramite il browser Firefox

Impostare security.enterprise_roots.enabled = true usando le istruzioni seguenti:

1. Immettere about:config nel browser FireFox.
2. Selezionare Accettare il rischio e continuare se si accetta il rischio.
3. Selezionare Mostra tutto
4. Impostare security.enterprise_roots.enabled = true
5. Uscire e riavviare Firefox

Per altre informazioni, vedere Configurazione di autorità di certificazione (CA) in Firefox e il file mozilla/policy-templates/README.

Come configurare un certificato per sviluppatore per Docker

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS in Linux

Stabilire l'attendibilità è specifico alla distribuzione e al browser. Le sezioni seguenti forniscono istruzioni per alcune distribuzioni popolari e i browser Chromium (Edge e Chrome) e per Firefox.

Rendere attendibile il certificato HTTPS su Linux con linux-dev-certs

linux-dev-certs è uno strumento globale .NET open source supportato dalla community che offre un modo pratico per creare e considerare attendibile un certificato per sviluppatori in Linux. Lo strumento non è gestito o supportato da Microsoft.

I comandi seguenti installano lo strumento e creano un certificato per sviluppatori attendibile:

dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

Per ulteriori informazioni o per segnalare problemi, consulta il repository GitHub linux-dev-certs.

Ubuntu considera attendibile il certificato per la comunicazione da servizio a servizio

Le istruzioni seguenti non funzionano per alcune versioni di Ubuntu, ad esempio 20.04. Per altre informazioni, vedere Problema di GitHub dotnet/AspNetCore.Docs #23686.

1. Installare OpenSSL 1.1.1h o versione successiva. Per istruzioni su come aggiornare OpenSSL, vedere la distribuzione.

2. Eseguire i comandi seguenti:

   dotnet dev-certs https
   sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
   sudo update-ca-certificates
   

I comandi precedenti:

• Verificare che il certificato per sviluppatore dell'utente corrente sia stato creato.
• Esporta il certificato con autorizzazioni elevate necessarie per la ca-certificates cartella, usando l'ambiente dell'utente corrente.
• La rimozione della bandiera -E esporta il certificato utente radice, generandolo se necessario. Ogni certificato appena generato ha un'impronta digitale diversa. Quando si esegue come root, sudo e -E non sono necessari.

Il percorso nel comando precedente è specifico per Ubuntu. Per altre distribuzioni, selezionare un percorso appropriato o usare il percorso per le autorità di certificazione (CA).

Considerare attendibile il certificato HTTPS in Linux usando Edge o Chrome

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

dnf install nss-tools

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Rendere attendibile il certificato con Fedora 34

See:

• Questo commento di GitHub
• Fedora: Uso di certificati di sistema condivisi
• Configurare un ambiente di sviluppo .NET in Fedora.

Considerare attendibile il certificato per altre distribuzioni

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS nel sottosistema Windows per Linux

Le istruzioni seguenti non funzionano per alcune distribuzioni linux, ad esempio Ubuntu 20.04. Per altre informazioni, vedere Problema di GitHub dotnet/AspNetCore.Docs #23686.

Il sottosistema Windows per Linux (WSL) genera un certificato di sviluppo autofirmato HTTPS, che per impostazione predefinita non è attendibile in Windows. Il modo più semplice per considerare attendibile il certificato WSL di Windows consiste nel configurare WSL per l'uso dello stesso certificato di Windows:

• In Windows esportare il certificato per sviluppatore in un file:

  dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
  

  Dove $CREDENTIAL_PLACEHOLDER$ è una password.

• In una finestra WSL importare il certificato esportato nell'istanza WSL:

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

L'approccio precedente è un'operazione da eseguire una sola volta per ogni certificato e per ogni distribuzione WSL. È più semplice che esportare il certificato più volte. Se si aggiorna o si rigenera il certificato in Windows, potrebbe essere necessario eseguire di nuovo i comandi precedenti.

Risolvi i problemi relativi ai certificati, ad esempio il certificato non attendibile

Questa sezione fornisce informazioni utili quando il certificato di sviluppo HTTPS core ASP.NET è stato installato e attendibile, ma sono ancora presenti avvisi del browser che il certificato non è attendibile. Il certificato di sviluppo HTTPS core ASP.NET viene usato da Kestrel.

Per ripristinare il certificato IIS Express, vedere questo problema di Stackoverflow .

Tutte le piattaforme : certificato non attendibile

Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app. L'attendibilità del certificato viene memorizzata nella cache dai browser.

dotnet dev-certs https --clean non riesce

I comandi precedenti risolveranno la maggior parte dei problemi di attendibilità del browser. Se il browser non considera attendibile il certificato, seguire i suggerimenti specifici della piattaforma che seguono.

Docker : certificato non attendibile

• Eliminare la cartella C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
• Pulire la soluzione. Eliminare le cartelle bin e obj.
• Riavviare lo strumento di sviluppo. Ad esempio, Visual Studio o Visual Studio Code.

Windows - Certificato non attendibile

• Controllare i certificati nell'archivio certificati. Deve essere presente un localhost certificato con il ASP.NET Core HTTPS development certificate nome descrittivo sia sotto Current User > Personal > Certificates che sotto Current User > Trusted root certification authorities > Certificates
• Rimuovere tutti i certificati trovati sia dalle autorità di certificazione personali sia da quelle di radice attendibili. Non rimuovere il certificato localhost di IIS Express.
• Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app.

OS X - Certificato non attendibile

• Apri Accesso Portachiavi.
• Selezionare il portachiavi di sistema.
• Verificare la presenza di un certificato localhost.
• Verificare che contenga un + simbolo sull'icona per indicare che è attendibile per tutti gli utenti.
• Rimuovere il certificato dal portachiavi di sistema.
• Eseguire i comandi seguenti:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Chiudere tutte le istanze del browser aperte. Aprire una nuova finestra del browser per l'app.

Per la risoluzione dei problemi relativi ai certificati con Visual Studio, vedere Errore HTTPS con IIS Express (dotnet/AspNetCore #16892 ).

Certificato Linux non attendibile

Verificare che il certificato configurato per l'attendibilità sia il certificato per sviluppatore HTTPS utente che verrà usato dal Kestrel server.

Controllare il certificato per sviluppatore Kestrel HTTPS predefinito dell'utente corrente nel percorso seguente:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

Il file del certificato di sviluppatore Kestrel HTTPS è l'impronta digitale SHA1. Quando il file viene eliminato tramite dotnet dev-certs https --clean, viene rigenerato quando necessario con un'impronta digitale diversa. Verificare che l'impronta digitale del certificato esportato corrisponda a quanto ottenuto con il comando seguente.

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Se il certificato non corrisponde, potrebbe essere uno dei seguenti:

• Un certificato precedente.
• Un certificato sviluppatore è stato esportato per l'utente root. In questo caso, esportare il certificato.

Il certificato root utente può essere controllato all'indirizzo:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

Certificato SSL di IIS Express usato con Visual Studio

Per risolvere i problemi relativi al certificato IIS Express, selezionare Ripristina dal programma di installazione di Visual Studio. Per altre informazioni, vedere questo problema in GitHub.

Criteri di gruppo impediscono l'attendibilità dei certificati autofirmati

In alcuni casi, i criteri di gruppo potrebbero impedire l'attendibilità dei certificati autofirmati. Per altre informazioni, vedere questo problema in GitHub.

Informazioni aggiuntive

• Configurare ASP.NET Core per l'utilizzo di server proxy e servizi di bilanciamento del carico
• Host ASP.NET Core in Linux con Nginx: configurazione HTTPS
• Come configurare SSL in IIS
• Configurare gli endpoint per Kestrel il server Web
• Supporto del browser OWASP HSTS