Imporre HTTPS in ASP.NET Core

Di David Galvan e Rick Anderson

questo articolo illustra come:

• Richiedi HTTPS per tutte le richieste.
• Reindirizzare tutte le richieste HTTP a HTTPS.

Nessuna API può impedire a un client di inviare dati sensibili alla prima richiesta.

Avviso

Progetti API

Non utilizzareRequireHttpsAttribute nelle API Web che ricevono informazioni riservate. RequireHttpsAttribute usa i codici di stato HTTP per reindirizzare i browser da HTTP a HTTPS. I client API potrebbero non comprendere o obbedire ai reindirizzamenti da HTTP a HTTPS. Tali client possono inviare informazioni su HTTP. Le API Web devono:

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

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

Progetti HSTS e API

I progetti API predefiniti non includono HSTS perché HSTS è in genere un'istruzione solo browser. Altri chiamanti, ad esempio le app per telefono o desktop, non obbediscono all'istruzione. Anche all'interno dei browser, una singola chiamata autenticata a un'API tramite HTTP presenta rischi per le reti non sicure. L'approccio sicuro consiste nel configurare i progetti API in modo che ascoltino e rispondano solo tramite HTTPS.

Il reindirizzamento HTTP a HTTPS causa ERR_INVALID_REDIRECT nella richiesta preliminare CORS

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

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

Richiedere HTTPS

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

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

Nota

Le app distribuite in una configurazione del proxy inverso consentono al proxy di gestire la sicurezza delle connessioni (HTTPS). Se il proxy gestisce anche il reindirizzamento HTTPS, non è necessario usare il middleware di reindirizzamento HTTPS. Se il server proxy gestisce anche la scrittura di intestazioni HSTS (ad esempio, il supporto HSTS nativo in IIS 10.0 (1709) o versione successiva, il middleware HSTS non è richiesto dall'app. Per altre informazioni, vedere Escludere HTTPS/HSTS durante la creazione del progetto.

UseHttpsRedirection

Il codice seguente chiama UseHttpsRedirection nel file Program.cs.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Il codice evidenziato precedente:

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

È consigliabile usare reindirizzamenti temporanei anziché reindirizzamenti permanenti. La memorizzazione nella cache dei collegamenti può causare un comportamento instabile negli ambienti di sviluppo. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente 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 le impostazioni dell'host https_port.

  • 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 implementazioni di proxy inversi.

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

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

Nota

Quando un'app viene eseguita in una configurazione del proxy inverso, IServerAddressesFeature non è disponibile. Impostare la porta usando uno degli altri approcci descritti in questa sezione.

Implementazioni Edge

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

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

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

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

Scenari di distribuzione

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

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

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

Opzioni

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

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

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

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

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

Il codice evidenziato precedente:

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

Configurare reindirizzamenti permanenti nell'ambiente di produzione

Il middleware usa per impostazione predefinita l'invio di un oggetto Status307TemporaryRedirect con tutti i reindirizzamenti. Se si preferisce inviare un codice di stato di reindirizzamento permanente quando l'app si trova in un ambiente non di sviluppo, avvolgere la configurazione delle opzioni del middleware in un controllo condizionale per un ambiente diverso dallo 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 ulteriori informazioni, vedere Middleware di riscrittura degli URL.

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

HTTP Strict Transport Security Protocol (HSTS)

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

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

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

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

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

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

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

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

Il codice evidenziato seguente:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

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

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

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

UseHsts esclude gli host di loopback seguenti:

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

Rifiutare esplicitamente HTTPS/HSTS alla creazione del progetto

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

Per rifiutare esplicitamente HTTPS/HSTS:

Visual Studio

Deseleziona la checkbox Configura per HTTPS.

CLI .NET

Usare l'opzione --no-https. Ad esempio:

dotnet new webapp --no-https

Considerare attendibile il certificato di sviluppo HTTPS ASP.NET Core

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

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

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

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

Avviso

Non creare un certificato di sviluppo in un ambiente che verrà ridistribuito, ad esempio un'immagine del contenitore o una macchina virtuale. Questo può portare allo spoofing e all'elevazione dei privilegi. Per evitare questo problema, impostare la DOTNET_GENERATE_ASPNET_CERTIFICATE variabile di ambiente su false prima di chiamare l'interfaccia della riga di comando di .NET per la prima volta. Questa operazione ignora la generazione automatica del certificato di sviluppo ASP.NET Core durante la prima esecuzione dell'interfaccia della riga di comando.

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 la fiducia di OpenSSL, lo strumento openssl deve trovarsi nel path di sistema.

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

Fiducia OpenSSL

Quando il certificato di sviluppo ASP.NET Core è attendibile, viene esportato in una cartella nella home directory dell'utente corrente. Per fare in modo che OpenSSL (e i client che lo usano) rilevino questa cartella, è necessario impostare la SSL_CERT_DIR variabile di ambiente. È possibile 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 al file di configurazione specifico della tua distribuzione e shell (ad esempio .profile).

Questo è necessario per far sì che strumenti come curl considerino attendibile il certificato di sviluppo. In alternativa, è possibile passare -CAfile o -CApath a ogni singola curl chiamata.

Si noti che questo richiede la versione 1.1.1h o successiva oppure la 3.0.0 o successiva, a seconda della versione principale che stai usando.

Se l'attendibilità di OpenSSL entra in uno stato non valido (ad esempio, se dotnet dev-certs https --clean non riesce a rimuoverlo), spesso si possono correggere la situazione usando lo strumento c_rehash.

Sostituzioni

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.

Avviso

Se si imposta una di queste variabili, è importante che vengano impostate sullo stesso valore ogni volta che viene aggiornata l'attendibilità. Se le posizioni cambiano, lo strumento non sarà in grado di riconoscere i certificati nelle vecchie posizioni, ad esempio, per ripulirli.

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), è quell'utente (ad esempio root) che si fiderà del certificato di sviluppo.

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

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

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

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

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

SUSE Linux Enterprise Server

Vedere questo problema di GitHub

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

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

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

Tutte le piattaforme : certificato non attendibile

Eseguire i comandi seguenti:

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

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

dotnet dev-certs https --clean non riesce

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

Docker : certificato non attendibile

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

Windows - Certificato non attendibile

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

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

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

OS X - Certificato non attendibile

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

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

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

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

Certificato Linux non attendibile

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

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

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

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

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

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

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

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

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

Certificato SSL di IIS Express usato con Visual Studio

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

Criteri di gruppo impediscono l'attendibilità dei certificati autofirmati

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

Informazioni aggiuntive

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