Appliquer HTTPS dans ASP.NET Core

Par David Galvan et Rick Anderson

Ce document montre comment :

• Exiger https pour toutes les requêtes.
• Redirige toutes les requêtes HTTP vers HTTPS.

Aucune API ne peut empêcher un client d’envoyer des données sensibles lors de la première demande.

Avertissement

Projets d’API

N’utilisezRequireHttpsAttribute pas sur les API web qui reçoivent des informations sensibles. RequireHttpsAttributeutilise des codes de status HTTP pour rediriger les navigateurs de HTTP vers HTTPS. Les clients d’API peuvent ne pas comprendre ou obéir aux redirections de HTTP vers HTTPS. Ces clients peuvent envoyer des informations via HTTP. Les API web doivent :

• N’écoutez pas sur HTTP.
• Fermez la connexion avec status code 400 (requête incorrecte) et ne traitez pas la demande.

Pour désactiver la redirection HTTP dans une API, définissez la variable d’environnement ASPNETCORE_URLS ou utilisez l’indicateur de ligne de --urls commande. Pour plus d’informations, consultez Utiliser plusieurs environnements dans ASP.NET Core et 5 façons de définir les URL d’une application ASP.NET Core par Andrew Lock.

Projets HSTS et API

Les projets d’API par défaut n’incluent pas HSTS , car HSTS est généralement une instruction de navigateur uniquement. Les autres appelants, tels que les applications de téléphone ou de bureau, n’obéissent pas à l’instruction. Même dans les navigateurs, un seul appel authentifié à une API via HTTP présente des risques sur les réseaux non sécurisés. L’approche sécurisée consiste à configurer des projets d’API pour écouter et répondre uniquement via HTTPS.

La redirection HTTP vers HTTPS entraîne des ERR_INVALID_REDIRECT sur la demande de contrôle préalable CORS

Les demandes adressées à un point de terminaison utilisant HTTP qui sont redirigées vers HTTPS par UseHttpsRedirection échec avec ERR_INVALID_REDIRECT on the CORS preflight request.

Les projets d’API peuvent rejeter les requêtes HTTP au lieu de les utiliser UseHttpsRedirection pour rediriger les requêtes vers HTTPS.

Exiger HTTPS

Nous recommandons que les applications web ASP.NET Core de production utilisent :

• Middleware de redirection HTTPS (UseHttpsRedirection) pour rediriger les requêtes HTTP vers HTTPS.
• Le middleware HSTS (UseHsts) pour envoyer des en-têtes HTTP Strict Transport Security Protocol (HSTS) aux clients.

Notes

Les applications déployées dans une configuration de proxy inverse permettent au proxy de gérer la sécurité de connexion (HTTPS). Si le proxy gère également la redirection HTTPS, il n’est pas nécessaire d’utiliser le middleware de redirection HTTPS. Si le serveur proxy gère également l’écriture d’en-têtes HSTS (par exemple, prise en charge HSTS native dans IIS 10.0 (1709) ou version ultérieure), le middleware HSTS n’est pas requis par l’application. Pour plus d’informations, consultez Refuser https/HSTS lors de la création d’un projet.

UtiliserHttpsRedirection

Le code suivant appelle UseHttpsRedirection dans le Program.cs fichier :

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();

Code mis en surbrillance précédent :

• Utilise la valeur par défaut HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Utilise la valeur par défaut HttpsRedirectionOptions.HttpsPort (null), sauf si elle est remplacée par la variable d’environnement ASPNETCORE_HTTPS_PORT ou IServerAddressesFeature.

Nous vous recommandons d’utiliser des redirections temporaires plutôt que des redirections permanentes. La mise en cache des liens peut entraîner un comportement instable dans les environnements de développement. Si vous préférez envoyer une redirection permanente status code lorsque l’application se trouve dans un environnement non-développement, consultez la section Configurer les redirections permanentes en production. Nous vous recommandons d’utiliser HSTS pour signaler aux clients que seules les demandes de ressources sécurisées doivent être envoyées à l’application (uniquement en production).

Configuration du port

Un port doit être disponible pour que l’intergicieliel redirige une demande non sécurisée vers HTTPS. Si aucun port n’est disponible :

• La redirection vers HTTPS ne se produit pas.
• L’intergiciel journalise l’avertissement « Échec de la détermination du port https pour la redirection ».

Spécifiez le port HTTPS à l’aide de l’une des approches suivantes :

• Définissez HttpsRedirectionOptions.HttpsPort.

• Définissez le https_portparamètre hôte :

  • Dans la configuration de l’hôte.

  • En définissant la variable d’environnement ASPNETCORE_HTTPS_PORT .

  • En ajoutant une entrée de niveau supérieur dans appsettings.json:

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

• Indiquez un port avec le schéma sécurisé à l’aide de la variable d’environnement ASPNETCORE_URLS. La variable d’environnement configure le serveur. Le middleware découvre indirectement le port HTTPS via IServerAddressesFeature. Cette approche ne fonctionne pas dans les déploiements de proxy inverse.

• Les modèles web ASP.NET Core définissent une URL HTTPS dans Properties/launchsettings.json pour Kestrel et IIS Express. launchsettings.json est utilisé uniquement sur l’ordinateur local.

• Configurez un point de terminaison d’URL HTTPS pour un déploiement de périphérie public de Kestrel serveur ou de serveurHTTP.sys . Un seul port HTTPS est utilisé par l’application. L’intergiciel découvre le port via IServerAddressesFeature.

Notes

Lorsqu’une application est exécutée dans une configuration de proxy inverse, IServerAddressesFeature n’est pas disponible. Définissez le port à l’aide de l’une des autres approches décrites dans cette section.

Déploiements de périphérie

Lorsque Kestrel ou HTTP.sys est utilisé comme serveur edge public, Kestrel ou HTTP.sys doit être configuré pour écouter sur les deux :

• Port sécurisé où le client est redirigé (généralement 443 en production et 5001 en développement).
• Port non sécurisé (généralement 80 en production et 5 000 en développement).

Le port non sécurisé doit être accessible par le client pour que l’application reçoive une demande non sécurisée et redirige le client vers le port sécurisé.

Pour plus d’informations, consultez Kestrel Configuration du point de terminaison ou implémentation de serveur webHTTP.sys dans ASP.NET Core.

Scénarios de déploiement

Tout pare-feu entre le client et le serveur doit également disposer de ports de communication ouverts pour le trafic.

Si les requêtes sont transférées dans une configuration de proxy inverse, utilisez le middleware des en-têtes transférés avant d’appeler le middleware de redirection HTTPS. Le middleware des en-têtes transférés met à jour le Request.Scheme, à l’aide de l’en-tête X-Forwarded-Proto . L’intergiciel permet aux URI de redirection et aux autres stratégies de sécurité de fonctionner correctement. Lorsque le middleware d’en-têtes transférés n’est pas utilisé, l’application principale peut ne pas recevoir le schéma correct et se retrouver dans une boucle de redirection. Un message d’erreur de l’utilisateur final courant est que trop de redirections se sont produites.

Lors du déploiement sur Azure App Service, suivez les instructions du tutoriel : Lier un certificat SSL personnalisé existant à Azure Web Apps.

Options

Les appels AddHttpsRedirection de code mis en évidence suivants pour configurer les options de middleware :

using System.Net;

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 = (int)HttpStatusCode.TemporaryRedirect;
    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();

L’appel AddHttpsRedirection est nécessaire uniquement pour modifier les valeurs de HttpsPort ou RedirectStatusCode.

Code mis en surbrillance précédent :

• Définit HttpsRedirectionOptions.RedirectStatusCode sur Status307TemporaryRedirect, qui est la valeur par défaut. Utilisez les champs de la StatusCodes classe pour les affectations à RedirectStatusCode.
• Définit le port HTTPS sur 5001.

Configurer des redirections permanentes en production

Par défaut, le middleware envoie un Status307TemporaryRedirect avec toutes les redirections. Si vous préférez envoyer une redirection permanente status code lorsque l’application se trouve dans un environnement non-développement, encapsulez la configuration des options d’intergicieliel dans un case activée conditionnel pour un environnement non-développement.

Lors de la configuration des services dans Program.cs:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int)HttpStatusCode.PermanentRedirect;
        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();

Autre approche du middleware de redirection HTTPS

Une alternative à l’utilisation du middleware de redirection HTTPS (UseHttpsRedirection) consiste à utiliser le middleware de réécriture d’URL (AddRedirectToHttps). AddRedirectToHttpspeut également définir le code et le port status lors de l’exécution de la redirection. Pour plus d’informations, consultez Réécriture d’URL middleware.

Lorsque vous redirigez vers HTTPS sans nécessiter de règles de redirection supplémentaires, nous vous recommandons d’utiliser le middleware de redirection HTTPS (UseHttpsRedirection) décrit dans cette rubrique.

Protocole HSTS (Strict Transport Security Protocol) HTTP

Selon OWASP, HTTP Strict Transport Security (HSTS) est une amélioration de sécurité d’adhésion qui est spécifiée par une application web à l’aide d’un en-tête de réponse. Lorsqu’un navigateur qui prend en charge HSTS reçoit cet en-tête :

• Le navigateur stocke la configuration du domaine qui empêche l’envoi de toute communication via HTTP. Le navigateur force toutes les communications sur HTTPS.
• Le navigateur empêche l’utilisateur d’utiliser des certificats non approuvés ou non valides. Le navigateur désactive les invites qui permettent à un utilisateur d’approuver temporairement un tel certificat.

Étant donné que HSTS est appliqué par le client, il présente certaines limitations :

• Le client doit prendre en charge HSTS.
• HSTS nécessite au moins une requête HTTPS réussie pour établir la stratégie HSTS.
• L’application doit case activée chaque requête HTTP et rediriger ou rejeter la requête HTTP.

ASP.NET Core implémente HSTS avec la méthode d’extensionUseHsts. Le code suivant appelle UseHsts lorsque l’application n’est pas en mode développement :

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 n’est pas recommandé dans le développement, car les paramètres HSTS sont hautement mis en cache par les navigateurs. Par défaut, UseHsts exclut l’adresse de bouclage local.

Pour les environnements de production qui implémentent HTTPS pour la première fois, définissez l’initial HstsOptions.MaxAge sur une petite valeur à l’aide de l’une TimeSpan des méthodes . Définissez la valeur des heures sur un seul jour au cas où vous devrez rétablir l’infrastructure HTTPS sur HTTP. Une fois que vous êtes confiant dans la durabilité de la configuration HTTPS, augmentez la valeur HSTS max-age ; une valeur couramment utilisée est d’un an.

Le code en surbrillance suivant :

using System.Net;

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 = (int)HttpStatusCode.TemporaryRedirect;
    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();

• Définit le paramètre de préchargement de l’en-tête Strict-Transport-Security . Le préchargement ne fait pas partie de la spécification RFC HSTS, mais est pris en charge par les navigateurs web pour précharger des sites HSTS lors d’une nouvelle installation. Pour plus d’informations, consultez https://hstspreload.org/.
• Active includeSubDomain, qui applique la stratégie HSTS aux sous-domaines hôtes.
• Définit explicitement le max-age paramètre de l’en-tête Strict-Transport-Security sur 60 jours. S’il n’est pas défini, la valeur par défaut est de 30 jours. Pour plus d’informations, consultez la directive max-age.
• Ajoute example.com à la liste des hôtes à exclure.

UseHsts exclut les hôtes de bouclage suivants :

• localhost : adresse de bouclage IPv4.
• 127.0.0.1 : adresse de bouclage IPv4.
• [::1] : adresse de bouclage IPv6.

Refuser https/HSTS lors de la création d’un projet

Dans certains scénarios de service back-end où la sécurité de la connexion est gérée à la périphérie publique du réseau, la configuration de la sécurité de la connexion à chaque nœud n’est pas nécessaire. Les applications web générées à partir des modèles dans Visual Studio ou à partir de la commande dotnet new activent la redirection HTTPS et HSTS. Pour les déploiements qui ne nécessitent pas ces scénarios, vous pouvez refuser HTTPS/HSTS lorsque l’application est créée à partir du modèle.

Pour refuser HTTPS/HSTS :

Visual Studio

Décochez la case Configurer pour HTTPS .

CLI .NET Core

Utilisez l'option --no-https. Par exemple

dotnet new webapp --no-https

Approuver le certificat de développement HTTPS ASP.NET Core sur Windows et macOS

Pour le navigateur Firefox, consultez la section suivante.

Le Kit de développement logiciel (SDK) .NET Core inclut un certificat de développement HTTPS. Le certificat est installé dans le cadre de la première expérience d’exécution. Par exemple, dotnet --info produit une variante de la sortie suivante :

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’installation du kit SDK .NET Core installe le certificat de développement ASP.NET Core HTTPS dans le magasin de certificats de l’utilisateur local. Le certificat a été installé, mais il n’est pas approuvé. Pour approuver le certificat, effectuez l’étape unique pour exécuter l’outil dotnet dev-certs :

dotnet dev-certs https --trust

La commande suivante fournit de l’aide sur l’outil dev-certs :

dotnet dev-certs https --help

Avertissement

Ne créez pas de certificat de développement dans un environnement qui sera redistribué, tel qu’une image conteneur ou une machine virtuelle. Cela peut entraîner l’usurpation et l’élévation de privilèges. Pour éviter cela, définissez la DOTNET_GENERATE_ASPNET_CERTIFICATE variable d’environnement false sur avant d’appeler l’interface CLI .NET pour la première fois. Cela permet d’ignorer la génération automatique du certificat de développement ASP.NET Core lors de la première exécution de l’interface CLI.

Approuver le certificat HTTPS avec Firefox pour éviter SEC_ERROR_INADEQUATE_KEY_USAGE erreur

Le navigateur Firefox utilise son propre magasin de certificats et n’approuve donc pas le IIS Express ou Kestrel les certificats de développeur.

Il existe deux approches pour approuver le certificat HTTPS avec Firefox: créer un fichier de stratégie ou configurer avec le navigateur FireFox. La configuration avec le navigateur crée le fichier de stratégie, de sorte que les deux approches sont équivalentes.

Créer un fichier de stratégie pour approuver le certificat HTTPS avec Firefox

Créez un fichier de stratégie (policies.json) à l’adresse suivante :

• Windows : %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS : Firefox.app/Contents/Resources/distribution
• Linux : consultez Approuver le certificat avec Firefox sur Linux dans ce document.

Ajoutez la valeur ON suivante JSau fichier de stratégie Firefox :

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

Le fichier de stratégie précédent permet à Firefox d’approuver les certificats provenant des certificats approuvés dans le magasin de certificats Windows. La section suivante fournit une autre approche pour créer le fichier de stratégie précédent à l’aide du navigateur Firefox.

Configurer l’approbation du certificat HTTPS à l’aide du navigateur Firefox

Définissez security.enterprise_roots.enabled = true à l’aide des instructions suivantes :

1. Entrez about:config dans le navigateur FireFox.
2. Sélectionnez Accepter le risque et Continuer si vous acceptez le risque.
3. Sélectionner Afficher tout
4. Ensemble security.enterprise_roots.enabled = true
5. Quitter et redémarrer Firefox

Pour plus d’informations, consultez Configuration des autorités de certification (CA) dans Firefox et le fichier mozilla/policy-templates/README.

Comment configurer un certificat de développeur pour Docker

Consultez ce problème GitHub.

Approuver le certificat HTTPS sur Linux

L’établissement de l’approbation est propre à la distribution et au navigateur. Les sections suivantes fournissent des instructions pour certaines distributions populaires et les navigateurs Chromium (Edge et Chrome) et pour Firefox.

Ubuntu approuve le certificat pour la communication de service à service

Les instructions suivantes ne fonctionnent pas pour certaines versions d’Ubuntu, telles que 20.04. Pour plus d’informations, consultez Problème GitHub dotnet/AspNetCore.Docs #23686.

1. Installez OpenSSL 1.1.1h ou version ultérieure. Consultez votre distribution pour obtenir des instructions sur la mise à jour d’OpenSSL.

2. Exécutez les commandes suivantes :

   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
   

Les commandes précédentes :

• Vérifiez que le certificat de développeur de l’utilisateur actuel est créé.
• Exporte le certificat avec des autorisations élevées nécessaires pour le dossier, à l’aide ca-certificates de l’environnement de l’utilisateur actuel.
• La suppression de l’indicateur -E exporte le certificat utilisateur racine, en le générant si nécessaire. Chaque certificat nouvellement généré a une empreinte numérique différente. Lors de l’exécution en tant que racine, sudo et -E ne sont pas nécessaires.

Le chemin d’accès dans la commande précédente est spécifique à Ubuntu. Pour les autres distributions, sélectionnez un chemin d’accès approprié ou utilisez le chemin d’accès des autorités de certification.

Approuver un certificat HTTPS sur Linux à l’aide d’Edge ou de Chrome

Ubuntu

Pour les navigateurs chromium sur Linux :

• Installez le libnss3-tools pour votre distribution.

• Créez ou vérifiez que le $HOME/.pki/nssdb dossier existe sur l’ordinateur.

• Exportez le certificat avec la commande suivante :

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

  Le chemin d’accès dans la commande précédente est spécifique à Ubuntu. Pour les autres distributions, sélectionnez un chemin d’accès approprié ou utilisez le chemin d’accès des autorités de certification.

• Exécutez les commandes suivantes :

  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
  

• Quittez et redémarrez le navigateur.

Approuver le certificat avec Firefox sur Linux

• Exportez le certificat avec la commande suivante :

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

  Le chemin d’accès dans la commande précédente est spécifique à Ubuntu. Pour les autres distributions, sélectionnez un chemin d’accès approprié ou utilisez le chemin d’accès des autorités de certification.

• Créez un JSfichier ON à l’aide /usr/lib/firefox/distribution/policies.json de la commande suivante :

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

Consultez Configurer l’approbation du certificat HTTPS à l’aide du navigateur Firefox dans ce document pour obtenir une autre façon de configurer le fichier de stratégie à l’aide du navigateur.

Red Hat Enterprise Linux

Avertissement

Les instructions suivantes sont destinées uniquement à des fins de développement. N’utilisez pas les certificats générés dans ces instructions pour un environnement de production.

Ces instructions utilisent l’outil certutilhérité de Mozilla à l’adresse https://firefox-source-docs.mozilla.org/security/nss/legacy/tools/nss_tools_certutil/index.html. Les instructions peuvent être mises à jour à mesure que les utilitaires et les pratiques modernes sont découverts.

Attention

Une utilisation incorrecte des certificats TLS peut entraîner une usurpation d’identité.

Conseil

Vous trouverez des instructions pour les certificats de production valides dans la documentation RHEL. RHEL8 Certificats TLSRHEL9 Certificats TLSRHEL9 Certificate System

Installer les dépendances

dnf install nss-tools

Exporter le certificat de développement ASP.NET Core

Important

Remplacez par ${ProjectDirectory} le répertoire de vos projets. Remplacez par ${CertificateName} un nom que vous serez en mesure d’identifier à l’avenir.

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

Attention

Si vous utilisez git, ajoutez votre certificat à votre ${ProjectDirectory}/.gitignore ou ${ProjectDirectory}/.git/info/exclude. Consultez la documentation Git pour plus d’informations sur ces fichiers.

Conseil

Vous pouvez déplacer votre certificat exporté en dehors de votre dépôt Git et remplacer les occurrences de ${ProjectDirectory}, dans les instructions suivantes, par le nouvel emplacement.

Importer le certificat de développement ASP.NET Core

Important

Remplacez par ${UserProfile} le profil que vous envisagez d’utiliser. Ne remplacez $HOMEpas , il s’agit de la variable d’environnement de votre répertoire utilisateur.

Navigateurs basés sur 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

Créer un alias à tester avec Curl

Important

Ne supprimez pas le certificat exporté si vous envisagez de tester avec curl. Vous devez créer un alias qui le référence dans votre $SHELLprofil

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

Nettoyage des certificats de développement

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

Notes

Supprimer l’alias curl que vous avez créé précédemment

SUSE Linux Enterprise Server

Voir ce problème GitHub

Approuver le certificat avec Fedora 34

Consultez l'article :

• Ce commentaire GitHub
• Fedora : Utilisation de certificats système partagés
• Configurez un environnement de développement .NET sur Fedora.

Approuver le certificat avec d’autres distributions

Consultez ce problème GitHub.

Approuver le certificat HTTPS à partir de Sous-système Windows pour Linux

Les instructions suivantes ne fonctionnent pas pour certaines distributions Linux, telles que Ubuntu 20.04. Pour plus d’informations, consultez Problème GitHub dotnet/AspNetCore.Docs #23686.

Le Sous-système Windows pour Linux (WSL) génère un certificat de développement auto-signé HTTPS, qui n’est pas approuvé par défaut dans Windows. Le moyen le plus simple pour que Windows approuve le certificat WSL consiste à configurer WSL pour utiliser le même certificat que Windows :

• Sur Windows, exportez le certificat de développeur vers un fichier :

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

  Où $CREDENTIAL_PLACEHOLDER$ est un mot de passe.

• Dans une fenêtre WSL, importez le certificat exporté sur le instance WSL :

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

L’approche précédente est une opération unique par certificat et par distribution WSL. Il est plus facile d’exporter le certificat encore et encore. Si vous mettez à jour ou régénérez le certificat sur Windows, vous devrez peut-être réexécuter les commandes précédentes.

Résoudre les problèmes de certificat tels que le certificat non approuvé

Cette section fournit de l’aide lorsque le certificat de développement HTTPS ASP.NET Core a été installé et approuvé, mais que vous avez toujours des avertissements de navigateur indiquant que le certificat n’est pas approuvé. Le certificat de développement HTTPS ASP.NET Core est utilisé par Kestrel.

Pour réparer le certificat IIS Express, consultez ce problème stackoverflow.

Toutes les plateformes - certificat non approuvé

Exécutez les commandes suivantes :

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

Fermez toutes les instances de navigateur ouvertes. Ouvrez une nouvelle fenêtre de navigateur pour l’application. L’approbation de certificat est mise en cache par les navigateurs.

dotnet dev-certs https --propre Échoue

Les commandes précédentes résolvent la plupart des problèmes d’approbation de navigateur. Si le navigateur n’approuve toujours pas le certificat, suivez les suggestions spécifiques à la plateforme qui suivent.

Docker : certificat non approuvé

• Supprimez le dossier C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
• Nettoyez la solution. Supprimez les dossiers bin et obj.
• Redémarrez l’outil de développement. Par exemple, Visual Studio, Visual Studio Code ou Visual Studio pour Mac.

Windows - certificat non approuvé

• Vérifiez les certificats dans le magasin de certificats. Il doit y avoir un localhost certificat avec le ASP.NET Core HTTPS development certificate nom convivial sous Current User > Personal > Certificates et Current User > Trusted root certification authorities > Certificates
• Supprimez tous les certificats trouvés des autorités de certification racine personnelles et approuvées. Ne supprimez pas le certificat localhost IIS Express.
• Exécutez les commandes suivantes :

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

Fermez toutes les instances de navigateur ouvertes. Ouvrez une nouvelle fenêtre de navigateur pour l’application.

OS X : certificat non approuvé

• Ouvrez l’accès au trousseau.
• Sélectionnez l’keychain système.
• Vérifiez la présence d’un certificat localhost.
• Vérifiez qu’elle contient un + symbole sur l’icône pour indiquer qu’elle est approuvée pour tous les utilisateurs.
• Supprimez le certificat du keychain système.
• Exécutez les commandes suivantes :

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

Fermez toutes les instances de navigateur ouvertes. Ouvrez une nouvelle fenêtre de navigateur pour l’application.

Consultez Erreur HTTPS à l’aide de IIS Express (dotnet/AspNetCore #16892) pour résoudre les problèmes de certificat avec Visual Studio.

Certificat Linux non approuvé

Vérifiez que le certificat en cours de configuration pour l’approbation est le certificat de développeur HTTPS utilisateur qui sera utilisé par le Kestrel serveur.

Vérifiez le certificat de développeur Kestrel HTTPS par défaut de l’utilisateur actuel à l’emplacement suivant :

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

Le fichier de certificat de développeur Kestrel HTTPS est l’empreinte SHA1. Lorsque le fichier est supprimé via dotnet dev-certs https --clean, il est régénéré si nécessaire avec une autre empreinte numérique. Vérifiez que l’empreinte numérique du certificat exporté correspond à la commande suivante :

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

Si le certificat ne correspond pas, il peut s’agir de l’un des éléments suivants :

• Ancien certificat.
• Un certificat de développeur exporté pour l’utilisateur racine. Dans ce cas, exportez le certificat.

Le certificat d’utilisateur racine peut être vérifié à l’adresse suivante :

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

IIS Express certificat SSL utilisé avec Visual Studio

Pour résoudre les problèmes liés au certificat IIS Express, sélectionnez Réparer dans le programme d’installation de Visual Studio. Pour plus d’informations, consultez ce problème GitHub.

La stratégie de groupe empêche la confiance des certificats auto-signés

Dans certains cas, la stratégie de groupe peut empêcher la confiance des certificats auto-signés. Pour plus d’informations, consultez ce problème GitHub.

Informations supplémentaires

• Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge
• Hôte ASP.NET Core sur Linux avec Apache : configuration HTTPS
• Hôte ASP.NET Core sur Linux avec Nginx : configuration HTTPS
• Configuration du protocole SSL sur IIS
• Configurer des points de terminaison pour le serveur web ASP.NET Core Kestrel
• Prise en charge du navigateur OWASP HSTS