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.
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_PORTvariable 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.jsonn'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-Securityen-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-agedeStrict-Transport-Securityen-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.coms’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 :
Décochez la case Configurer pour HTTPS.
Faire confiance au certificat de développement HTTPS ASP.NET Core
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.
Comment configurer un certificat de développeur pour Docker
Consultez ce problème GitHub.
Considérations spécifiques à Linux
Les distributions Linux diffèrent considérablement dans la façon dont elles marquent les certificats comme approuvés. Bien que dotnet dev-certs soit en principe largement applicable, il n’est officiellement pris en charge que sur Ubuntu et Fedora, et vise spécifiquement à garantir la confiance dans les navigateurs Firefox et basés sur Chromium (Edge, Chrome et Chromium).
Les dépendances
Pour établir une confiance OpenSSL, l’outil openssl doit se trouver sur le chemin.
Pour établir une confiance de navigateur (par exemple, dans Edge ou Firefox), l’outil certutil doit se trouver sur le chemin.
Confiance OpenSSL
Lorsque le certificat de développement ASP.NET Core est approuvé, il est exporté vers un dossier dans le répertoire de home de l’utilisateur actuel. Pour que OpenSSL (et les clients qui le consomment) utilise ce dossier, vous devez définir la variable d’environnement SSL_CERT_DIR. Vous pouvez effectuer cette opération dans une seule session en exécutant une commande comme export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (la valeur exacte se trouve dans la sortie lorsque --verbose est transmis) ou en l’ajoutant à votre fichier de configuration (spécifique à la distribution et à l’interpréteur de commandes, par exemple .profile).
Cela est nécessaire pour que des outils comme curl approuvent le certificat de développement. Sinon, vous pouvez transmettre -CAfile ou -CApath à chaque appel curl individuel.
Notez que cela nécessite la version 1.1.1h ou ultérieure, ou 3.0.0 ou ultérieure, selon la version principale que vous utilisez.
Si la confiance OpenSSL est dans un état incorrect (par exemple, si dotnet dev-certs https --clean ne parvient pas à la supprimer), il est souvent possible de la définir correctement à l’aide de l’outil c_rehash.
Remplacements
Si vous utilisez un autre navigateur avec son propre magasin NSS (Network Security Services), vous pouvez utiliser la variable d’environnement DOTNET_DEV_CERTS_NSSDB_PATHS pour spécifier une liste délimitée par deux-points des répertoires NSS (c’est-à-dire le répertoire contenant cert9.db) auxquels ajouter le certificat de développement.
Si vous stockez les certificats que vous souhaitez qu’OpenSSL approuve dans un répertoire spécifique, vous pouvez utiliser la variable d’environnement DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY pour indiquer où il se trouve.
Avertissement
Si vous définissez l’une de ces variables, il est important qu’elles soient définies sur les mêmes valeurs chaque fois que l’approbation est mise à jour. Si elles changent, l’outil n’aura pas connaissance des certificats dans les anciens emplacements (par exemple, pour les nettoyer).
Utiliser sudo
Comme sur les autres plateformes, les certificats de développement sont stockés et approuvés séparément pour chaque utilisateur. Par conséquent, si vous exécutez dotnet dev-certs en tant qu’utilisateur différent (par exemple, en utilisant sudo), c’est cet utilisateur (par exemple root) qui approuvera le certificat de développement.
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.
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
localhostavec le nom convivialASP.NET Core HTTPS development certificateà la fois sousCurrent User > Personal > CertificatesetCurrent 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
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_PORTvariable 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.jsonn'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-Securityen-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-agedeStrict-Transport-Securityen-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.coms’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 :
Décochez la case Configurer pour 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 :
- Entrez
about:configdans le navigateur FireFox. - Sélectionnez Accepter le risque et continuer si vous acceptez le risque.
- Sélectionnez Afficher tout
- Définir
security.enterprise_roots.enabled=true - 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.
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.
Installez OpenSSL 1.1.1h ou une version ultérieure. Consultez votre distribution pour savoir comment mettre à jour OpenSSL.
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
-Eexporte 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,sudoet-Ene 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
Pour les navigateurs chrome sous Linux :
Installez le
libnss3-toolspour votre distribution.Créez ou vérifiez que le dossier
$HOME/.pki/nssdbexiste 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 PEMLe 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.crtQuittez 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 PEMLe 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.jsonavec 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.
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$ --trustOù
$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
localhostavec le nom convivialASP.NET Core HTTPS development certificateà la fois sousCurrent User > Personal > CertificatesetCurrent 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
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 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 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.
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 la classe Startup :
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Error");
// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapRazorPages();
});
}
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_PORTvariable 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": "Warning", "Microsoft.Hosting.Lifetime": "Information" } }, "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.
En développement, définissez une URL HTTPS dans
launchsettings.json. Activez HTTPS lorsque IIS Express est utilisé.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 :
public void ConfigureServices(IServiceCollection services)
{
services.AddRazorPages();
services.AddHsts(options =>
{
options.Preload = true;
options.IncludeSubDomains = true;
options.MaxAge = TimeSpan.FromDays(60);
options.ExcludedHosts.Add("example.com");
options.ExcludedHosts.Add("www.example.com");
});
services.AddHttpsRedirection(options =>
{
options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
options.HttpsPort = 5001;
});
}
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 Startup.cs :
public void ConfigureServices(IServiceCollection services)
{
// IWebHostEnvironment (stored in _env) is injected into the Startup class.
if (!_env.IsDevelopment())
{
services.AddHttpsRedirection(options =>
{
options.RedirectStatusCode = (int) HttpStatusCode.PermanentRedirect;
options.HttpsPort = 443;
});
}
}
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 :
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Error");
// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapRazorPages();
});
}
UseHsts 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 suivant :
public void ConfigureServices(IServiceCollection services)
{
services.AddRazorPages();
services.AddHsts(options =>
{
options.Preload = true;
options.IncludeSubDomains = true;
options.MaxAge = TimeSpan.FromDays(60);
options.ExcludedHosts.Add("example.com");
options.ExcludedHosts.Add("www.example.com");
});
services.AddHttpsRedirection(options =>
{
options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
options.HttpsPort = 5001;
});
}
- Définit le paramètre de préchargement de
Strict-Transport-Securityen-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-agedeStrict-Transport-Securityen-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.coms’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 :
Décochez la case Configurer pour 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,exécuter dotnet new webapp pour la première fois produit une variante de la sortie suivante :
Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'
Learn about HTTPS: https://aka.ms/dotnet-https
L’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 plus loin 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 :
- Entrez
about:configdans le navigateur FireFox. - Sélectionnez Accepter le risque et continuer si vous acceptez le risque.
- Sélectionnez Afficher tout.
- Définissez
security.enterprise_roots.enabled=true. - 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.
Ubuntu fait confiance au certificat pour la communication de service à service
Installez OpenSSL 1.1.1h ou une version ultérieure. Consultez votre distribution pour savoir comment mettre à jour OpenSSL.
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éé.
- Exportez le certificat avec les autorisations élevées nécessaires pour le dossier
ca-certificates, en utilisant l'environnement de l’utilisateur actuel. - Supprimez l’indicateur
-Epour exporter 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,sudoet-Ene 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
Pour les navigateurs chrome sous Linux :
Installez le
libnss3-toolspour votre distribution.Créez ou vérifiez que le dossier
$HOME/.pki/nssdbexiste 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 PEMLe 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.crtQuittez 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 PEMLe 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.jsonavec le contenu suivant :
cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
"policies": {
"Certificates": {
"Install": [
"/usr/local/share/ca-certificates/aspnet/https.crt"
]
}
}
}
EOF
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.
Faire confiance au certificat avec Fedora 34
Firefox sur Fedora
echo 'pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);' > ./autoconfig.js
echo '//Enable policies.json
lockPref("browser.policies.perUserDir", false);' > firefox.cfg
echo "{
\"policies\": {
\"Certificates\": {
\"Install\": [
\"aspnetcore-localhost-https.crt\"
]
}
}
}" > policies.json
dotnet dev-certs https -ep localhost.crt --format PEM
sudo mv autoconfig.js /usr/lib64/firefox/
sudo mv firefox.cfg /usr/lib64/firefox/
sudo mv policies.json /usr/lib64/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt
rm localhost.crt
Faites confiance à dotnet-to-dotnet sur Fedora
sudo cp localhost.crt /etc/pki/tls/certs/localhost.pem
sudo update-ca-trust
rm localhost.crt
Voir ce commentaire GitHub pour plus d'informations.
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
Le Sous-système Windows pour Linux (WSL) génère un certificat de développement auto-signé HTTPS. Pour configurer le magasin de certificats Windows pour approuver le certificat WSL :
Exportez le certificat développeur vers un fichier sous Windows :
dotnet dev-certs https -ep C:\<<path-to-folder>>\aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$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 /mnt/c/<<path-to-folder>>/aspnetcore.pfx -p $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 --échec du nettoyage
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, Visual Studio Code ou Visual Studio pour Mac.
Windows – certificat non approuvé
- Vérifiez les certificats dans le magasin de certificats. Il devrait y avoir un certificat
localhostavec le nom convivialASP.NET Core HTTPS development certificateà la fois sousCurrent User > Personal > CertificatesetCurrent 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. La confiance du certificat est mise en cache par les navigateurs.
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. La confiance du certificat est mise en cache par les navigateurs.
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.
Informations supplémentaires
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_PORTvariable 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.jsonn'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-Securityen-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-agedeStrict-Transport-Securityen-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.coms’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 :
Décochez la case Configurer pour 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 :
- Entrez
about:configdans le navigateur FireFox. - Sélectionnez Accepter le risque et continuer si vous acceptez le risque.
- Sélectionnez Afficher tout
- Définir
security.enterprise_roots.enabled=true - 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.
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.
Installez OpenSSL 1.1.1h ou une version ultérieure. Consultez votre distribution pour savoir comment mettre à jour OpenSSL.
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
-Eexporte 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,sudoet-Ene 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
Pour les navigateurs chrome sous Linux :
Installez le
libnss3-toolspour votre distribution.Créez ou vérifiez que le dossier
$HOME/.pki/nssdbexiste 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 PEMLe 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.crtQuittez 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 PEMLe 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.jsonavec 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.
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$ --trustOù
$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
localhostavec le nom convivialASP.NET Core HTTPS development certificateà la fois sousCurrent User > Personal > CertificatesetCurrent 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
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_PORTvariable 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.jsonn'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-Securityen-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-agedeStrict-Transport-Securityen-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.coms’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 :
Décochez la case Configurer pour 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 :
- Entrez
about:configdans le navigateur FireFox. - Sélectionnez Accepter le risque et continuer si vous acceptez le risque.
- Sélectionnez Afficher tout
- Définir
security.enterprise_roots.enabled=true - 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.
Installez OpenSSL 1.1.1h ou une version ultérieure. Consultez votre distribution pour savoir comment mettre à jour OpenSSL.
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
-Eexporte 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,sudoet-Ene 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
Pour les navigateurs chrome sous Linux :
Installez le
libnss3-toolspour votre distribution.Créez ou vérifiez que le dossier
$HOME/.pki/nssdbexiste 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 PEMLe 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.crtQuittez 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 PEMLe 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.jsonavec 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.
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$ --trustOù
$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
localhostavec le nom convivialASP.NET Core HTTPS development certificateà la fois sousCurrent User > Personal > CertificatesetCurrent 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
