Imporre HTTPS in ASP.NET Core

Di David Galvan e Rick Anderson

Questo documento 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 usare RequireHttpsAttribute 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 è in ascolto 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

Le richieste a un endpoint che usano HTTP reindirizzate a HTTPS UseHttpsRedirection hanno esito negativo con ERR_INVALID_REDIRECT on the CORS preflight request.

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.

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 Rifiutare esplicitamente HTTPS/HSTS per la creazione del progetto.

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_PORTS 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_porthost:

  • Nella configurazione host.

  • Impostando la ASPNETCORE_HTTPS_PORTS 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.

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.

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 esegue il reindirizzamento a HTTPS senza il requisito di regole di reindirizzamento aggiuntive, è consigliabile usare il middleware di reindirizzamento HTTPS (UseHttpsRedirection) descritto in questo argomento.

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:

Visual Studio

Deselezionare la casella di controllo Configura per HTTPS .

Interfaccia della riga di comando di .NET Core

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

dotnet new webapp --no-https

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

Per il browser Firefox, vedere la sezione successiva.

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

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

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

dotnet dev-certs https --trust

Il comando seguente consente di visualizzare informazioni della Guida sullo strumento 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. In questo modo, lo spoofing e l'elevazione dei privilegi possono comportare lo spoofing e l'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.

Considerare attendibile il certificato HTTPS con Firefox per evitare edizione StandardC_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 documento.

Aggiungere il codice ON seguente JSal 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

Ubuntu

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
  certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -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 JSfile ON in /usr/lib/firefox/distribution/policies.json con il comando seguente:

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

Nota: Ubuntu 21.10 Firefox viene fornito come pacchetto snap e la cartella di installazione è /snap/firefox/current/usr/lib/firefox.

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

Red Hat Enterprise Linux

Avviso

Le istruzioni seguenti sono destinate solo a scopi di sviluppo. Non usare i certificati generati in queste istruzioni per un ambiente di produzione.

Queste istruzioni usano lo strumento legacy di Mozilla in https://firefox-source-docs.mozilla.org/security/nss/legacy/tools/nss_tools_certutil/index.html.certutil Le istruzioni possono essere aggiornate man mano che vengono individuate utilità e procedure moderne.

Attenzione

L'uso improprio dei certificati TLS potrebbe causare lo spoofing.

Suggerimento

Le istruzioni per i certificati di produzione validi sono disponibili nella documentazione di RHEL. RHEL8 Tls CertificatesRHEL9 TLS CertificatesRHEL9 Certificate System

Installare le dipendenze

dnf install nss-tools

Esportare il certificato di sviluppo principale ASP.NET

Importante

Sostituire ${ProjectDirectory} con la directory dei progetti. Sostituire ${CertificateName} con un nome che sarà possibile identificare in futuro.

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

Attenzione

Se si usa Git, aggiungere il certificato a ${ProjectDirectory}/.gitignore o ${ProjectDirectory}/.git/info/exclude. Per informazioni su questi file, vedere la documentazione git.

Suggerimento

È possibile spostare il certificato esportato all'esterno del repository Git e sostituire le occorrenze di ${ProjectDirectory}, nelle istruzioni seguenti, con il nuovo percorso.

Importare il certificato di sviluppo principale ASP.NET

Importante

Sostituire ${UserProfile} con il profilo che si intende usare. Non sostituire $HOME, è la variabile di ambiente nella directory utente.

Browser basati su Chromium

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

Mozilla Firefox

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

Creare un alias da testare con Curl

Importante

Non eliminare il certificato esportato se si prevede di eseguire il test con curl. Dovrai creare un alias che fa riferimento al profilo del tuo $SHELL

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

Pulizia dei certificati di sviluppo

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

Nota

Rimuovere l'alias curl creato in precedenza

SUSE Linux Enterprise Server

Vedere questo problema di GitHub

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.

Risolvere 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{U edizione Standard R}\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
• Ospitare ASP.NET Core in Linux con Apache: configurazione HTTPS
• 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