Imporre HTTPS in ASP.NET Core

Il reindirizzamento HTTP a HTTPS causa ERR_INVALID_REDIRECT nella richiesta preliminare CORS

Le richieste a un endpoint che usano HTTP reindirizzate a HTTPS UseHttpsRedirection non riescono con ERR_INVALID_REDIRECT nella richiesta preliminare CORS.

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

Richiedere HTTPS

È consigliabile usare le app Web core ASP.NET di produzione:

• Middleware di reindirizzamento HTTPS (UseHttpsRedirection) per reindirizzare le richieste HTTP a HTTPS.
• Middleware HSTS (UseHsts) per inviare intestazioni HTTP Strict Transport Security Protocol (HSTS) ai client.

UseHttpsRedirection

Nel file viene chiamato UseHttpsRedirection il Program.cs codice seguente:

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 non di sviluppo, vedere la sezione Configurare 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:

• Impostare HttpsRedirectionOptions.HttpsPort.

• Impostare l'impostazione https_port host:

  • Nella configurazione 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 distribuzioni del proxy inverso.

• I modelli Web ASP.NET Core impostano un URL HTTPS in Properties/launchsettings.json sia per Kestrel 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 Edge

Quando Kestrel o HTTP.sys viene usato come server Kestrel perimetrale pubblico 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).
• 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 altre informazioni, vedere Kestrel Configurazione dell'endpoint o HTTP.sys'implementazione del server Web 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 vengono inoltrate in una configurazione del proxy inverso, usare il middleware delle intestazioni inoltrate prima di chiamare il middleware di reindirizzamento HTTPS. Il middleware delle intestazioni inoltrate aggiorna , Request.Schemeusando 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'app back-end potrebbe non ricevere lo schema corretto e terminare in un ciclo 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.

Opzioni

Le chiamate AddHttpsRedirection di codice evidenziate seguenti 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 non di sviluppo, eseguire il wrapping della configurazione delle opzioni middleware in un controllo condizionale per un ambiente non di sviluppo.

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 altre informazioni, vedere Middleware di riscrittura 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 questa intestazione:

• 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 l'oggetto iniziale HstsOptions.MaxAge su un valore ridotto 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 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 HSTS RFC, ma è supportato dai Web browser per precaricare i siti HSTS in 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 altre informazioni, vedere la direttiva max-age.
• Aggiunge example.com all'elenco di host da escludere.

UseHsts esclude gli host di loopback seguenti:

• localhost : indirizzo di loopback IPv4.
• 127.0.0.1 : indirizzo di loopback IPv4.
• [::1] : 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 core ASP.NET

.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 monouso per eseguire lo dotnet dev-certs strumento:

dotnet dev-certs https --trust

Il comando seguente consente di visualizzare informazioni della Guida sullo strumento dotnet dev-certs:

dotnet dev-certs https --help

Come configurare un certificato per sviluppatore per Docker

Vedere il problema in GitHub.

Considerazioni specifiche di Linux

Le distribuzioni linux differiscono in modo sostanziale nel modo in cui contrassegnano i certificati come attendibili. Sebbene dotnet dev-certs sia ampiamente applicabile, è ufficialmente supportato solo in Ubuntu e Fedora e mira in particolare a garantire la fiducia nei browser basati su Firefox e Chromium (Edge, Chrome e Chromium).

Dipendenze

Per stabilire un trust OpenSSL, lo openssl strumento deve trovarsi nel percorso.

Per stabilire l'attendibilità del browser (ad esempio, in Edge o Firefox), lo certutil strumento deve trovarsi nel percorso.

Trust OpenSSL

Quando il certificato di sviluppo ASP.NET Core è attendibile, viene esportato in una cartella nella directory dell'utente home 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 eseguire questa operazione in una singola sessione eseguendo un comando come export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (il valore esatto sarà nell'output quando --verbose viene passato) o aggiungendolo (distribuzione e file di configurazione specifico della shell), ad esempio .profile.

Questo è necessario per creare strumenti come curl considerare attendibile il certificato di sviluppo. In alternativa, è possibile passare -CAfile o -CApath a ogni singola curl chiamata.

Si noti che questo richiede 1.1.1h o versione successiva o successiva o 3.0.0 o successiva, a seconda della versione principale in uso.

Se l'attendibilità OpenSSL entra in uno stato non valido (ad esempio, se dotnet dev-certs https --clean non riesce a rimuoverlo), è spesso possibile impostare gli elementi corretti usando lo c_rehash strumento.

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) a cui aggiungere il certificato di sviluppo.

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 dove si trova.

Uso di sudo

Come in altre piattaforme, i certificati di sviluppo vengono archiviati e considerati attendibili separatamente per ogni utente. Di conseguenza, se si esegue dotnet dev-certs come utente diverso (ad esempio usando sudo), si tratta dell'utente (ad esempio root) che considererà attendibile il certificato di sviluppo.

Considerare attendibile il certificato HTTPS in 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 altre informazioni o per segnalare i problemi, vedere il repository GitHub linux-dev-certs.

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 ha esito negativo

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 in Current User > Personal > Certificates che Current User > Trusted root certification authorities > Certificates
• Rimuovere tutti i certificati trovati dalle autorità di certificazione radice personali e 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

• Aprire l'accesso KeyChain.
• 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 per sviluppatori Kestrel HTTPS è l'identificazione personale SHA1. Quando il file viene eliminato tramite dotnet dev-certs https --clean, viene rigenerato quando necessario con un'identificazione personale diversa. Verificare che l'identificazione personale del certificato esportato corrisponda al 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.
• Certificato per sviluppatore esportato per l'utente radice. In questo caso, esportare il certificato.

Il certificato utente radice 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 impedisce 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 il server Web ASP.NET Core Kestrel
• Supporto del browser OWASP HSTS

Il reindirizzamento HTTP a HTTPS causa ERR_INVALID_REDIRECT nella richiesta preliminare CORS

Le richieste a un endpoint che usano HTTP reindirizzate a HTTPS UseHttpsRedirection non riescono con ERR_INVALID_REDIRECT nella richiesta preliminare CORS.

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

Richiedere HTTPS

È consigliabile usare le app Web core ASP.NET di produzione:

• Middleware di reindirizzamento HTTPS (UseHttpsRedirection) per reindirizzare le richieste HTTP a HTTPS.
• Middleware HSTS (UseHsts) per inviare intestazioni HTTP Strict Transport Security Protocol (HSTS) ai client.

UseHttpsRedirection

Nel file viene chiamato UseHttpsRedirection il Program.cs codice seguente:

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 non di sviluppo, vedere la sezione Configurare 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:

• Impostare HttpsRedirectionOptions.HttpsPort.

• Impostare l'impostazione https_port host:

  • Nella configurazione 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 distribuzioni del proxy inverso.

• I modelli Web ASP.NET Core impostano un URL HTTPS in Properties/launchsettings.json sia per Kestrel 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 Edge

Quando Kestrel o HTTP.sys viene usato come server Kestrel perimetrale pubblico 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).
• 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 altre informazioni, vedere Kestrel Configurazione dell'endpoint o HTTP.sys'implementazione del server Web 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 vengono inoltrate in una configurazione del proxy inverso, usare il middleware delle intestazioni inoltrate prima di chiamare il middleware di reindirizzamento HTTPS. Il middleware delle intestazioni inoltrate aggiorna , Request.Schemeusando 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'app back-end potrebbe non ricevere lo schema corretto e terminare in un ciclo 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.

Opzioni

Le chiamate AddHttpsRedirection di codice evidenziate seguenti 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 non di sviluppo, eseguire il wrapping della configurazione delle opzioni middleware in un controllo condizionale per un ambiente non di sviluppo.

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 altre informazioni, vedere Middleware di riscrittura 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 questa intestazione:

• 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 l'oggetto iniziale HstsOptions.MaxAge su un valore ridotto 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 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 HSTS RFC, ma è supportato dai Web browser per precaricare i siti HSTS in 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 altre informazioni, vedere la direttiva max-age.
• Aggiunge example.com all'elenco di host da escludere.

UseHsts esclude gli host di loopback seguenti:

• localhost : indirizzo di loopback IPv4.
• 127.0.0.1 : indirizzo di loopback IPv4.
• [::1] : 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 monouso per eseguire lo dotnet dev-certs strumento:

dotnet dev-certs https --trust

Il comando seguente consente di visualizzare informazioni della Guida sullo strumento dotnet dev-certs:

dotnet dev-certs https --help

Considerare attendibile il certificato HTTPS con Firefox per evitare SEC_ERROR_INADEQUATE_KEY_USAGE errore

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

Creare un file di criteri (policies.json) in:

• 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 rende attendibili i certificati di Firefox 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à è la distribuzione e specifica del 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.
• Se necessario, la rimozione del -E flag esporta il certificato utente radice, generandolo. Ogni certificato appena generato ha un'identificazione personale diversa. Quando si esegue come radice 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

Considerare attendibile il certificato con Fedora 34

Vedere:

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

Considerare attendibile il certificato con altre distribuzioni

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS da 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 una sola volta per ogni certificato e per 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 ha esito negativo

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 in Current User > Personal > Certificates che Current User > Trusted root certification authorities > Certificates
• Rimuovere tutti i certificati trovati dalle autorità di certificazione radice personali e 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

• Aprire l'accesso KeyChain.
• 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 per sviluppatori Kestrel HTTPS è l'identificazione personale SHA1. Quando il file viene eliminato tramite dotnet dev-certs https --clean, viene rigenerato quando necessario con un'identificazione personale diversa. Verificare che l'identificazione personale del certificato esportato corrisponda al 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.
• Certificato per sviluppatore esportato per l'utente radice. In questo caso, esportare il certificato.

Il certificato utente radice 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 impedisce 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 il server Web ASP.NET Core Kestrel
• Supporto del browser OWASP HSTS

Richiedere HTTPS

È consigliabile usare le app Web core ASP.NET di produzione:

• Middleware di reindirizzamento HTTPS (UseHttpsRedirection) per reindirizzare le richieste HTTP a HTTPS.
• Middleware HSTS (UseHsts) per inviare intestazioni HTTP Strict Transport Security Protocol (HSTS) ai client.

UseHttpsRedirection

Il codice seguente chiama UseHttpsRedirection la Startup classe :

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 non di sviluppo, vedere la sezione Configurare 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:

• Impostare HttpsRedirectionOptions.HttpsPort.

• Impostare l'impostazione https_port host:

  • Nella configurazione 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 distribuzioni del proxy inverso.

• In fase di sviluppo, impostare 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 Edge

Quando Kestrel o HTTP.sys viene usato come server Kestrel perimetrale pubblico 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).
• 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 altre informazioni, vedere Kestrel Configurazione dell'endpoint o HTTP.sys'implementazione del server Web 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 vengono inoltrate in una configurazione del proxy inverso, usare il middleware delle intestazioni inoltrate prima di chiamare il middleware di reindirizzamento HTTPS. Il middleware delle intestazioni inoltrate aggiorna , Request.Schemeusando 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'app back-end potrebbe non ricevere lo schema corretto e terminare in un ciclo 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.

Opzioni

Le chiamate AddHttpsRedirection di codice evidenziate seguenti 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 non di sviluppo, eseguire il wrapping della configurazione delle opzioni middleware in un controllo condizionale per un ambiente non di sviluppo.

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 altre informazioni, vedere Middleware di riscrittura 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 questa intestazione:

• 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 l'oggetto iniziale HstsOptions.MaxAge su un valore ridotto 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 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 HSTS RFC, ma è supportato dai Web browser per precaricare i siti HSTS in 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 altre informazioni, vedere la direttiva max-age.
• Aggiunge example.com all'elenco di host da escludere.

UseHsts esclude gli host di loopback seguenti:

• localhost : indirizzo di loopback IPv4.
• 127.0.0.1 : indirizzo di loopback IPv4.
• [::1] : 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 monouso per eseguire lo dotnet dev-certs strumento:

dotnet dev-certs https --trust

Il comando seguente consente di visualizzare informazioni della Guida sullo strumento dotnet dev-certs:

dotnet dev-certs https --help

Considerare attendibile il certificato HTTPS con Firefox per evitare SEC_ERROR_INADEQUATE_KEY_USAGE errore

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

Creare un file di criteri (policies.json) in:

• 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 rende attendibili i certificati di Firefox 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à è la distribuzione e specifica del 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'identificazione personale diversa. Quando si esegue come radice 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 in Linux:

• libnss3-tools Installare 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.

Considerare 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

Considerare attendibile dotnet-to-dotnet in 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 con altre distribuzioni

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS da 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 una sola volta per ogni certificato e per 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 ha esito negativo

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 in Current User > Personal > Certificates che Current User > Trusted root certification authorities > Certificates
• Rimuovere tutti i certificati trovati dalle autorità di certificazione radice personali e 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

• Aprire l'accesso KeyChain.
• 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 per sviluppatori Kestrel HTTPS è l'identificazione personale SHA1. Quando il file viene eliminato tramite dotnet dev-certs https --clean, viene rigenerato quando necessario con un'identificazione personale diversa. Verificare che l'identificazione personale del certificato esportato corrisponda al 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.
• Certificato per sviluppatore esportato per l'utente radice. In questo caso, esportare il certificato.

Il certificato utente radice 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 ERR_INVALID_REDIRECT nella richiesta preliminare CORS

Le richieste a un endpoint che usano HTTP reindirizzate a HTTPS UseHttpsRedirection non riescono con ERR_INVALID_REDIRECT nella richiesta preliminare CORS.

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

Richiedere HTTPS

È consigliabile usare le app Web core ASP.NET di produzione:

• Middleware di reindirizzamento HTTPS (UseHttpsRedirection) per reindirizzare le richieste HTTP a HTTPS.
• Middleware HSTS (UseHsts) per inviare intestazioni HTTP Strict Transport Security Protocol (HSTS) ai client.

UseHttpsRedirection

Nel file viene chiamato UseHttpsRedirection il Program.cs codice seguente:

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 non di sviluppo, vedere la sezione Configurare 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:

• Impostare HttpsRedirectionOptions.HttpsPort.

• Impostare l'impostazione https_port host:

  • Nella configurazione 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 distribuzioni del proxy inverso.

• I modelli Web ASP.NET Core impostano un URL HTTPS in Properties/launchsettings.json sia per Kestrel 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 Edge

Quando Kestrel o HTTP.sys viene usato come server Kestrel perimetrale pubblico 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).
• 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 altre informazioni, vedere Kestrel Configurazione dell'endpoint o HTTP.sys'implementazione del server Web 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 vengono inoltrate in una configurazione del proxy inverso, usare il middleware delle intestazioni inoltrate prima di chiamare il middleware di reindirizzamento HTTPS. Il middleware delle intestazioni inoltrate aggiorna , Request.Schemeusando 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'app back-end potrebbe non ricevere lo schema corretto e terminare in un ciclo 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.

Opzioni

Le chiamate AddHttpsRedirection di codice evidenziate seguenti 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 non di sviluppo, eseguire il wrapping della configurazione delle opzioni middleware in un controllo condizionale per un ambiente non di sviluppo.

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 altre informazioni, vedere Middleware di riscrittura 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 questa intestazione:

• 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 l'oggetto iniziale HstsOptions.MaxAge su un valore ridotto 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 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 HSTS RFC, ma è supportato dai Web browser per precaricare i siti HSTS in 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 altre informazioni, vedere la direttiva max-age.
• Aggiunge example.com all'elenco di host da escludere.

UseHsts esclude gli host di loopback seguenti:

• localhost : indirizzo di loopback IPv4.
• 127.0.0.1 : indirizzo di loopback IPv4.
• [::1] : 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 monouso per eseguire lo dotnet dev-certs strumento:

dotnet dev-certs https --trust

Il comando seguente consente di visualizzare informazioni della Guida sullo strumento dotnet dev-certs:

dotnet dev-certs https --help

Considerare attendibile il certificato HTTPS con Firefox per evitare SEC_ERROR_INADEQUATE_KEY_USAGE errore

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

Creare un file di criteri (policies.json) in:

• 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 rende attendibili i certificati di Firefox 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à è la distribuzione e specifica del 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.
• Se necessario, la rimozione del -E flag esporta il certificato utente radice, generandolo. Ogni certificato appena generato ha un'identificazione personale diversa. Quando si esegue come radice 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

Considerare attendibile il certificato con Fedora 34

Vedere:

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

Considerare attendibile il certificato con altre distribuzioni

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS da 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 una sola volta per ogni certificato e per 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 ha esito negativo

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 in Current User > Personal > Certificates che Current User > Trusted root certification authorities > Certificates
• Rimuovere tutti i certificati trovati dalle autorità di certificazione radice personali e 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

• Aprire l'accesso KeyChain.
• 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 per sviluppatori Kestrel HTTPS è l'identificazione personale SHA1. Quando il file viene eliminato tramite dotnet dev-certs https --clean, viene rigenerato quando necessario con un'identificazione personale diversa. Verificare che l'identificazione personale del certificato esportato corrisponda al 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.
• Certificato per sviluppatore esportato per l'utente radice. In questo caso, esportare il certificato.

Il certificato utente radice 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 impedisce 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 il server Web ASP.NET Core Kestrel
• Supporto del browser OWASP HSTS

Il reindirizzamento HTTP a HTTPS causa ERR_INVALID_REDIRECT nella richiesta preliminare CORS

Le richieste a un endpoint che usano HTTP reindirizzate a HTTPS UseHttpsRedirection non riescono con ERR_INVALID_REDIRECT nella richiesta preliminare CORS.

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

Richiedere HTTPS

È consigliabile usare le app Web core ASP.NET di produzione:

• Middleware di reindirizzamento HTTPS (UseHttpsRedirection) per reindirizzare le richieste HTTP a HTTPS.
• Middleware HSTS (UseHsts) per inviare intestazioni HTTP Strict Transport Security Protocol (HSTS) ai client.

UseHttpsRedirection

Nel file viene chiamato UseHttpsRedirection il Program.cs codice seguente:

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 non di sviluppo, vedere la sezione Configurare 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:

• Impostare HttpsRedirectionOptions.HttpsPort.

• Impostare l'impostazione https_port host:

  • Nella configurazione 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 distribuzioni del proxy inverso.

• I modelli Web ASP.NET Core impostano un URL HTTPS in Properties/launchsettings.json sia per Kestrel 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 Edge

Quando Kestrel o HTTP.sys viene usato come server Kestrel perimetrale pubblico 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).
• 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 altre informazioni, vedere Kestrel Configurazione dell'endpoint o HTTP.sys'implementazione del server Web 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 vengono inoltrate in una configurazione del proxy inverso, usare il middleware delle intestazioni inoltrate prima di chiamare il middleware di reindirizzamento HTTPS. Il middleware delle intestazioni inoltrate aggiorna , Request.Schemeusando 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'app back-end potrebbe non ricevere lo schema corretto e terminare in un ciclo 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.

Opzioni

Le chiamate AddHttpsRedirection di codice evidenziate seguenti 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 non di sviluppo, eseguire il wrapping della configurazione delle opzioni middleware in un controllo condizionale per un ambiente non di sviluppo.

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 altre informazioni, vedere Middleware di riscrittura 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 questa intestazione:

• 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 l'oggetto iniziale HstsOptions.MaxAge su un valore ridotto 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 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 HSTS RFC, ma è supportato dai Web browser per precaricare i siti HSTS in 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 altre informazioni, vedere la direttiva max-age.
• Aggiunge example.com all'elenco di host da escludere.

UseHsts esclude gli host di loopback seguenti:

• localhost : indirizzo di loopback IPv4.
• 127.0.0.1 : indirizzo di loopback IPv4.
• [::1] : 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 monouso per eseguire lo dotnet dev-certs strumento:

dotnet dev-certs https --trust

Il comando seguente consente di visualizzare informazioni della Guida sullo strumento dotnet dev-certs:

dotnet dev-certs https --help

Considerare attendibile il certificato HTTPS con Firefox per evitare SEC_ERROR_INADEQUATE_KEY_USAGE errore

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

Creare un file di criteri (policies.json) in:

• 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 rende attendibili i certificati di Firefox 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à è la distribuzione e specifica del browser. Le sezioni seguenti forniscono istruzioni per alcune distribuzioni popolari e i browser Chromium (Edge e Chrome) e per Firefox.

Considerare attendibile il certificato HTTPS in 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 altre informazioni o per segnalare i problemi, vedere 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.
• Se necessario, la rimozione del -E flag esporta il certificato utente radice, generandolo. Ogni certificato appena generato ha un'identificazione personale diversa. Quando si esegue come radice 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

Considerare attendibile il certificato con Fedora 34

Vedere:

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

Considerare attendibile il certificato con altre distribuzioni

Vedere il problema in GitHub.

Considerare attendibile il certificato HTTPS da 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 una sola volta per ogni certificato e per 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 ha esito negativo

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 in Current User > Personal > Certificates che Current User > Trusted root certification authorities > Certificates
• Rimuovere tutti i certificati trovati dalle autorità di certificazione radice personali e 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

• Aprire l'accesso KeyChain.
• 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 per sviluppatori Kestrel HTTPS è l'identificazione personale SHA1. Quando il file viene eliminato tramite dotnet dev-certs https --clean, viene rigenerato quando necessario con un'identificazione personale diversa. Verificare che l'identificazione personale del certificato esportato corrisponda al 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.
• Certificato per sviluppatore esportato per l'utente radice. In questo caso, esportare il certificato.

Il certificato utente radice 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 impedisce 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 il server Web ASP.NET Core Kestrel
• Supporto del browser OWASP HSTS