Appliquer HTTPS dans ASP.NET Core

Par David Galvan et Rick Anderson

cet article explique 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 à la première requête.

Remarque

Si vous utilisez le kit de développement logiciel (SDK) .NET 9 ou version ultérieure, consultez les procédures Linux mises à jour dans la version .NET 9 de cet article.

Avertissement

Projets d'API

Ne pas utiliser RequireHttpsAttribute sur les API Web qui reçoivent des informations sensibles. RequireHttpsAttribute utilise des codes d'état HTTP pour rediriger les navigateurs de HTTP vers HTTPS. Les clients 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 :

• Ne pas écouter sur HTTP.
• Fermez la connexion avec le code d'état 400 (requête incorrecte) et ne répondez 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 commande --urls. Pour plus d'informations, consultez Utiliser plusieurs environnements dans ASP.NET Core et 8 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 téléphones ou les applications de bureau, n'obéissent pas aux instructions. 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 les projets d'API pour écouter et répondre uniquement via HTTPS.

La redirection HTTP vers HTTPS provoque ERR_INVALID_REDIRECT sur la requête de contrôle en amont CORS

Les requêtes à un point de terminaison utilisant HTTP qui sont redirigées vers HTTPS par UseHttpsRedirection échouent avec ERR_INVALID_REDIRECT dans la requête préliminaire CORS.

Les projets d'API peuvent rejeter les requêtes HTTP plutôt que 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 :

• Intergiciel de redirection HTTPS (UseHttpsRedirection) pour rediriger les requêtes HTTP vers HTTPS.
• Intergiciel 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 la 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 des en-têtes HSTS (par exemple, la prise en charge native de HSTS dans IIS 10.0 (1709) ou version ultérieure), HSTS Middleware n'est pas requis par l'application. Pour plus d'informations, consultez Désactivation de HTTPS/HSTS lors de la création de projet.

UseHttpsRedirection

Le code suivant appelle UseHttpsRedirection dans le fichier 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();

Le code 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 ASPNETCORE_HTTPS_PORT variable d'environnement 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 un code d'état de redirection permanent lorsque l'application se trouve dans un environnement de 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 le middleware redirige une requête non sécurisée vers HTTPS. Si aucun port n'est disponible :

• La redirection vers HTTPS ne se produit pas.
• Le middleware enregistre l'avertissement "Échec de la détermination du port https pour la redirection".

Spécifiez le port HTTPS en utilisant l'une des approches suivantes :

• Définissez HttpsRedirectionOptions.HttpsPort.

• Définissez le paramètre d’hôte https_port :

  • 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 pour Properties/launchsettings.json à la fois Kestrel et pour IIS Express. launchsettings.json n'est utilisé que sur la machine locale.

• Configurez un point de terminaison d'URL HTTPS pour un déploiement périphérique public d'un serveur Kestrel ou d'un serveur HTTP.sys. Un seul port HTTPS est utilisé par l'application. Le middleware 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 en utilisant 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 que HTTP.sys doit être configuré pour écouter sur les deux :

• Le port sécurisé où le client est redirigé (typiquement, 443 en production et 5001 en développement).
• Le port non sécurisé (typiquement, 80 en production et 5000 en développement).

Le port non sécurisé doit être accessible par le client pour que l'application reçoive une requête 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 du serveur Web HTTP.sys dans ASP.NET Core.

Scénarios de déploiement

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

Si les demandes sont transférées dans une configuration de proxy inverse, utilisez le middleware d'en-têtes transférés avant d'appeler le middleware de redirection HTTPS. L'intergiciel d'en-têtes transférés met à jour le Request.Scheme, à l'aide de X-Forwarded-Proto en-tête. Le middleware permet aux URI de redirection et aux autres politiques de sécurité de fonctionner correctement. Lorsque l'intergiciel 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 courant pour l'utilisateur final est que trop de redirections se sont produites.

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

Options

Les appels de code en surbrillance suivants AddHttpsRedirection pour configurer les options du 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();

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

Le code en surbrillance précédent :

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

Configurer des redirections permanentes en production

Le middleware envoie par défaut un Status307TemporaryRedirect avec toutes les redirections. Si vous préférez envoyer un code d'état de redirection permanent lorsque l'application se trouve dans un environnement de non-développement, encapsulez la configuration des options du middleware dans une vérification conditionnelle pour un environnement de non-développement.

Lors de la configuration des services dans 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();

Approche alternative 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). AddRedirectToHttps peut également définir le code d'état et le port lorsque la redirection est exécutée. Pour plus d'informations, consultez Intergiciel de réécriture d'URL.

Lors d’une redirection vers HTTPS sans exigence de règles de redirection supplémentaires, nous vous recommandons d’utiliser le middleware de redirection HTTPS (UseHttpsRedirection) décrit dans cet article.

Protocole de sécurité de transport strict HTTP (HSTS)

Selon OWASP, HTTP Strict Transport Security (HSTS) est une amélioration de sécurité opt-in qui est spécifiée par une application Web via l'utilisation d'un en-tête de réponse. Lorsqu'un navigateur prenant 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 via 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 limites :

• 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 vérifier chaque requête HTTP et rediriger ou rejeter la requête HTTP.

ASP.NET Core implémente HSTS avec la méthode d'extension UseHsts. Le code suivant s'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é en développement car les paramètres HSTS sont hautement cacheables 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, HstsOptions.MaxAge définissez la valeur initiale sur une petite valeur à l'aide de l'une des méthodes TimeSpan. Définissez la valeur de heures à pas plus d'un jour au cas où vous auriez besoin de rétablir l'infrastructure HTTPS sur HTTP. Une fois que vous êtes sûr de la durabilité de la configuration HTTPS, augmentez la valeur HSTS max-age ; une valeur couramment utilisée est un an.

Le code en surbrillance suivant :

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

• Définit le paramètre de préchargement de Strict-Transport-Security en-tête. 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 les 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 de l'hôte.
• Définit explicitement le paramètre max-age de Strict-Transport-Security en-tête à 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.
• example.com s’ajoute à la liste des hôtes à exclure.

UseHsts exclut les hôtes de bouclage suivants :

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

Désactiver HTTPS/HSTS lors de la création de projet

Dans certains scénarios de service backend où la sécurité de la connexion est gérée à la périphérie du réseau face au public, la configuration de la sécurité de la connexion à chaque nœud n'est pas requise. Les applications Web générées à partir des modèles dans Visual Studio ou à partir de la nouvelle commande dotnet activent la redirection HTTPS et HSTS. Pour les déploiements qui ne nécessitent pas ces scénarios, vous pouvez désactiver HTTPS/HSTS lorsque l'application est créée à partir du modèle.

Pour désactiver HTTPS/HSTS :

Visual Studio

Décochez la case Configurer pour HTTPS.

CLI .NET

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

dotnet new webapp --no-https

Faites confiance au certificat de développement HTTPS ASP.NET Core sur Windows et macOS

Pour le navigateur Firefox, consultez la section suivante.

Le 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 d'exécution de l’outil dotnet dev-certs :

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

Avertissement

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

Faites confiance au certificat HTTPS avec Firefox pour éviter l'erreur SEC_ERROR_INADEQUATE_KEY_USAGE

Le navigateur Firefox utilise son propre magasin de certificats et ne fait donc pas confiance aux certificats IIS Express ou Kestrel de développeur.

Il existe deux approches pour faire confiance au 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 faire confiance au certificat HTTPS avec Firefox

Créez un fichier de stratégie (policies.json) à :

• Windows : %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS : Firefox.app/Contents/Resources/distribution
• Linux : consultez Faire confiance au certificat avec Firefox sur Linux dans cet article.

Ajoutez le JSON suivant au fichier de stratégie de Firefox :

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

Le fichier de stratégie précédent crée des certificats de confiance Firefox à partir des certificats de confiance dans le magasin de certificats Windows. La section suivante fournit une approche alternative pour créer le fichier de stratégie précédent à l'aide du navigateur Firefox.

Configurer la confiance du certificat HTTPS à l'aide du navigateur Firefox

Réglez security.enterprise_roots.enabled = true en suivant les 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électionnez Afficher tout
4. Définir security.enterprise_roots.enabled = true
5. Quittez et redémarrez 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.

Faire confiance au certificat HTTPS sous Linux

L'établissement de la confiance est spécifique à 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.

Approuver un certificat HTTPS sur Linux avec linux-dev-certs

linux-dev-certs est un outil .NET global pris en charge par la communauté open source qui propose un moyen pratique de créer et d’approuver un certificat de développeur sur Linux. L’outil n’est pas géré ou pris en charge par Microsoft.

Les commandes suivantes installent l’outil et créent un certificat de développeur approuvé :

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

Pour plus d’informations ou pour signaler des problèmes, consultez le référentiel GitHub linux-dev-certs.

Ubuntu fait confiance au 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 le problème GitHub dotnet/AspNetCore.Docs #23686.

1. Installez OpenSSL 1.1.1h ou une version ultérieure. Consultez votre distribution pour savoir comment mettre à jour 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 :

• Assurez-vous que le certificat de développeur de l'utilisateur actuel est créé.
• Exporte le certificat avec les autorisations élevées nécessaires pour le dossier ca-certificates, en utilisant l'environnement de l'utilisateur actuel.
• La suppression de l'indicateur -E exporte le certificat d'utilisateur racine, en le générant si nécessaire. Chaque certificat nouvellement généré a une empreinte digitale différente. Lors de l'exécution en tant que root, sudo et -E ne sont pas nécessaires.

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

Faire confiance au certificat HTTPS sur Linux en utilisant Edge ou Chrome

Ubuntu

Pour les navigateurs chrome sous Linux :

• Installez le libnss3-tools pour votre distribution.

• Créez ou vérifiez que le dossier $HOME/.pki/nssdb existe sur la machine.

• 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 dans la commande précédente est spécifique à Ubuntu. Pour les autres distributions, sélectionnez un chemin approprié ou utilisez le chemin des autorités de certification (CA).

• 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
  

• Quittez et redémarrez le navigateur.

Faites confiance au 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 dans la commande précédente est spécifique à Ubuntu. Pour les autres distributions, sélectionnez un chemin approprié ou utilisez le chemin des autorités de certification (CA).

• Créez un fichier JSON sur /usr/lib/firefox/distribution/policies.json avec 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

Remarque : Ubuntu 21.10 Firefox est fourni en tant que snap et le dossier d’installation est /snap/firefox/current/usr/lib/firefox.

Consultez Configurer la confiance du certificat HTTPS à l’aide du navigateur Firefox dans cet article pour une autre manière de configurer le fichier de stratégie à l’aide du navigateur.

Red Hat Enterprise Linux

Avertissement

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

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

Attention

Une mauvaise utilisation des certificats TLS peut entraîner une usurpation d'identité.

Conseil

Les instructions pour les certificats de production valides se trouvent dans la documentation RHEL. Certificats TLS RHEL8 CertificatsTLS RHEL9 Système de certificats RHEL9

Installer les dépendances

dnf install nss-tools

Exporter le certificat de développement ASP.NET Core

Important

Remplacez ${ProjectDirectory} par votre répertoire de projets. Remplacez ${CertificateName} par un nom que vous pourrez 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 de git pour plus d'informations sur ces fichiers.

Conseil

Vous pouvez déplacer votre certificat exporté en dehors de votre référentiel 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 ${UserProfile} par le profil que vous avez l'intention d'utiliser. Ne remplacez pas $HOME, 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 prévoyez de tester avec curl. Vous devrez créer un alias le référençant dans votre profil de $SHELL

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

Supprimez l'alias curl que vous avez créé précédemment

SUSE Linux Enterprise Server

Voir ce problème GitHub

Faire confiance au certificat avec Fedora 34

Consultez l'article :

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

Faire confiance au certificat avec d'autres distributions

Consultez ce problème GitHub.

Faire confiance au certificat HTTPS du Sous-système Windows pour Linux

Les instructions suivantes ne fonctionnent pas pour certaines distributions Linux, comme Ubuntu 20.04. Pour plus d'informations, consultez le 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 par défaut n'est pas approuvé dans Windows. Le moyen le plus simple pour que Windows approuve le certificat WSL consiste à configurer WSL pour qu'il utilise le même certificat que Windows :

• Sous Windows, exportez le certificat de développeur dans 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 l'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. C'est plus facile que d'exporter le certificat encore et encore. Si vous mettez à jour ou régénérez le certificat sous Windows, vous devrez peut-être exécuter à nouveau les commandes précédentes.

Résoudre les problèmes de certificat, comme un 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 recevez 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. La confiance du certificat est mise en cache par les navigateurs.

dotnet dev-certs https --clean échoue

Les commandes précédentes résolvent la plupart des problèmes de confiance du navigateur. Si le navigateur ne fait toujours pas confiance au certificat, suivez les suggestions spécifiques à la plate-forme 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 ou Visual Studio Code.

Windows – certificat non approuvé

• Vérifiez les certificats dans le magasin de certificats. Il devrait y avoir un certificat localhost avec le nom convivial ASP.NET Core HTTPS development certificate à la fois 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 de confiance. Ne supprimez pas le certificat IIS Express localhost.
• 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 le trousseau Système.
• Vérifiez la présence d'un certificat localhost.
• Vérifiez qu'il contient un symbole + sur l'icône pour indiquer qu'il est approuvé pour tous les utilisateurs.
• Supprimez le certificat du trousseau 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.

Voir Erreur HTTPS lors de l'utilisation d'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 configuré pour la confiance est le certificat de développeur HTTPS de l'utilisateur qui sera utilisé par le serveur Kestrel.

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

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

Le fichier de certificat de développeur HTTPS Kestrel 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 empreinte digitale différente. 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 :

• Un 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é sur :

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

Certificat SSL IIS Express utilisé avec Visual Studio

Pour résoudre les problèmes avec le 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 les certificats auto-signés d'être approuvés

Dans certains cas, la stratégie de groupe peut empêcher l'approbation 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éberger 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