Récemment, lorsque vous avez examiné comment configurer l’authentification à l’aide de fournisseurs de connexion externes (par exemple Google, Facebook) avec ASP.NET Core J’ai remarqué que https est maintenant une exigence pour certains d’entre eux.
Une autre chose que j’ai remarquée était à quel point il était difficile de trouver des ressources pour activer HTTPS sur ASP.NET Noyau.
Cet article de blog traite du processus de création d’un ASP local.Site Web NET Core fonctionnant avec HTTPS sans erreur dans Chrome (montrant le cadenas vert dans la barre d’adresse) pour votre heure de développement locale. Et puis comment vous pouvez utiliser Nginx ou IIS lorsque vous êtes prêt à l’exposer au monde.
Pour utiliser HTTPS, nous avons besoin d’un certificat numérique. Si vous devez générer le vôtre à utiliser au moment du développement, je recommande d’utiliser OpenSSL pour créer des certificats. Il explique non seulement comment créer votre propre autorité de certification et certificats, mais aussi comment configurer votre navigateur (Chrome ou Firefox) pour qu’il fasse confiance à l’autorité de certification.
De plus, si vous souhaitez comprendre le rôle des certificats dans HTTPS, consultez une brève explication du fonctionnement de https.
À partir de maintenant, je suppose que vous avez généré votre autorité de certification, votre certificat et votre clé privée correspondante et que vous avez un.fichier pfx (Échange de Renseignements personnels).
Créer un nouveau projet
Je vais décrire le processus en utilisant le code Visual Studio et Yeoman.
Si vous n’êtes pas familier avec yeoman, c’est un outil en ligne de commande qui vous permet de créer de nouveaux projets à partir d’une liste de modèles de projet. Le générateur yeoman (c’est le nom du paquet pour yeoman qui contient les modèles) que nous allons utiliser est generator-aspnet. Pour installer yeoman, vous avez d’abord besoin de npm, puis vous pouvez suivre les instructions d’installation de yeoman et du ASP.NET Modèles de base ici.
La raison d’utiliser Visual Studio Code et yeoman est que ce processus fonctionne sous Windows, Linux et macOS.
Pour utiliser yeoman avec le ASP.NET Les modèles de base exécutent la commande suivante:
$ yo aspnet _-----_ ╭──────────────────────────╮ | | │ Welcome to the │ |--(o)--| │ marvellous ASP.NET Core │`---------´ │ generator! │ ( _´U`_ ) ╰──────────────────────────╯ /___A___\ / | ~ | __'.___.'__ ´ ` |° ´ Y ` ? What type of application do you want to create? (Use arrow keys)❯ Empty Web Application Empty Web Application (F#) Console Application Console Application (F#) Web Application Web Application Basic Web Application Basic (F#)
Sélectionnez Une Application Web vide. Un projet web simple sera créé qui a juste une page avec le texte « Hello World ».
Si vous utilisez Windows et que vous avez la version complète de Visual Studio, vous pouvez simplement faire File- > Nouveau projet, sélectionnez .Net Core, ASP.NET Application Web de base, puis sélectionnez Vide.
Configuration de HTTPS pour Kestrel
Kestrel est le serveur Web utilisé par défaut avec ASP.NET Noyau.
Pour ajouter la prise en charge HTTPS à Kestrel, ajoutez le package Microsoft.AspNetCore.Server.Kestrel.Https
en tant que dépendance.
Si vous utilisez project.json vous pouvez le faire en éditant le projet.section « dépendances » de json et ajout:
"Microsoft.AspNetCore.Server.Kestrel.Https": "1.1.0"
Le numéro de version peut être différent pour vous, mais il doit être le même que celui utilisé dans le package Microsoft.AspNetCore.Server.Kestrel
.
Si vous utilisez .csproj
, vous pouvez ajouter la dépendance en exécutant:
dotnet add package Microsoft.AspNetCore.Server.Kestrel.Https
Configuration du certificat
Pour configurer Kestrel pour utiliser notre.fichier pfx (certificat et clé privée) nous devons éditer Program.cs
où le WebHostBuilder
est en cours de création et apporter quelques modifications:
var host = new WebHostBuilder() .UseConfiguration(config) .UseKestrel(options => { options.UseHttps("localhost.pfx", "password"); }) .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration() .UseUrls("https://*:4430") .UseStartup<Startup>() .Build();
Les changements sont:
.UseKestrel(options => { options.UseHttps("localhost.pfx", "password");})
C’est là que nous spécifions ce qu’est le.fichier pfx que nous voulons utiliser et son mot de passe. UseHttps
est une méthode d’extension, si vous obtenez une erreur disant qu’elle n’existe pas, c’est parce que vous n’avez pas ajouté le package nuget Microsoft.AspNetCore.Server.Kestrel.Https
, qui est là où il vit.
Aussi:
.UseUrls("https://*:4430")
Qui définit où Kestrel écoutera les connexions entrantes. Vous pouvez également utiliser https://localhost:4430
au lieu de *
. Avec *
cependant, vous pouvez utiliser n’importe quel nom de domaine, par exemple si vous avez cette application Web dans myDomain.com
, cela fonctionnerait toujours, alors qu’avec localhost
, seules les requêtes vers localhost
seraient servies.
Si vous vous demandez pourquoi je n’ai pas utilisé le port HTTPS par défaut, 443, c’est parce que vous avez besoin d’autorisations spéciales sur Linux pour les ports inférieurs à 1024. Sous Windows, ce ne serait pas un problème. Cependant, parce que faire cela avec Kestrel n’est recommandé que lorsque vous êtes au moment du développement, ce n’est pas un gros problème.
Si vous essayez cela sous Linux, macOS ou en utilisant la ligne de commande sous Windows, vous pouvez appeler dotnet run
, ouvrir Chrome et aller à https://localhost:43000
et voir une icône de cadenas vert.
Si vous utilisez full Visual Studio sous Windows, la façon de le faire est de spécifier que vous souhaitez exécuter l’application Web directement et non via IIS Express:
Sélectionnez également le navigateur sur lequel vous souhaitez l’essayer. Si vous avez installé le certificat de l’autorité de certification racine de votre test dans un navigateur spécifique, utilisez ce navigateur, par exemple Chrome (si vous êtes confus par cette déclaration, je vous recommande de lire une brève explication du fonctionnement de https et d’utiliser OpenSSL pour créer des certificats):
Enfin, modifiez les propriétés du projet (cliquez avec le bouton droit de la souris et sélectionnez propriétés):
Et modifiez l’URL de lancement:
En utilisant ASP.NET Core avec un proxy inverse
Bien qu’il soit certainement possible de servir une application Web en utilisant ASP.NET Noyau utilisant uniquement le crécerelle, il n’est pas recommandé. En effet, Kestrel n’est pas un serveur Web complet et manque encore de fonctionnalités de sécurité.
Même si cela n’est pas recommandé, vous voudrez peut-être simplement montrer quelque chose que vous avez fait à quelqu’un et ignorer la partie de l’installation et de la configuration d’un serveur Web. Avec des services comme DigitalOcean ou Linode, vous pouvez créer un VPS en très peu de temps et avoir simplement votre ASP.NET Le noyau disponible par là n’a qu’à installer .net core.
Cependant, si vous voulez quelque chose de plus sérieux (et vous le faites probablement puisque vous êtes ici à cause de l’activation de HTTPS), vous devez utiliser un serveur Web complet, comme Nginx ou IIS (sous Windows), comme un proxy inverse à votre ASP.NET Application de base.
Un serveur proxy inverse est un serveur Web qui accepte les demandes et les envoie à un autre serveur Web qui crée réellement les réponses pour ces demandes. Les réponses sont renvoyées au serveur proxy qui les transmet aux clients ayant émis les demandes correspondantes.
Avec Nginx agissant comme un proxy inverse, cela ressemblerait à ceci:
Browser <----> Nginx <----> Kestrel
La bonne chose à propos de cette configuration est que nous pouvons tirer parti du fait que Nginx (ou IIS) est un serveur Web complet et activer HTTPS dessus:
Browser <---- HTTPS ---> Nginx <---- HTTP ----> Kestrel
Nous n’avons donc même pas besoin de configurer Kestrel avec HTTPS, juste Nginx.
Configuration de HTTPS avec Nginx
Vous devez d’abord installer Nginx. J’utilise Ubuntu 16.04 pour cela, mais vous pouvez même l’installer sur Windows.
Si vous utilisez Ubuntu, ouvrez un terminal et tapez
$ sudo apt-get install nginx
La prochaine chose que nous devons faire est de modifier la configuration de Nginx. Mais avant de le faire, il est utile de savoir quel est l’emplacement des fichiers de configuration et comment ils deviennent activés. Le dossier dans lequel les fichiers de configuration sont généralement placés est /etc/nginx/sites-available/
(cet emplacement peut être différent si vous utilisez une distribution Linux différente).
Le fichier de configuration présent lors de l’installation de Nginx est nommé default
.
Pour qu’une configuration Nginx soit activée, elle doit se trouver dans le dossier /etc/nginx/sites-enabled
. Ainsi, après la création d’un nouveau fichier de configuration (dans sites-available
), un lien symbolique est créé dans sites-enabled
qui pointe vers le nouveau fichier.
Imaginez que nous venions de créer un nouveau fichier de configuration nommé my-site-https
dans sites-available
. Après cela, vous allez dans le dossier sites-enabled
et exécutez la commande suivante pour créer un lien symbolique:
$ ln -s /etc/nginx/sites-available/my-site-htts
Pour que Nginx lise cette nouvelle configuration, exécutez la commande:
$ sudo nginx -s reload
Maintenant que nous savons comment créer et activer des configurations Nginx, créons le fichier de configuration pour configurer Nginx en tant que proxy inverse à un ASP.NET Application principale qui s’exécute à http://localhost:5000
.
Créez d’abord un nouveau fichier dans /etc/nginx/sites-available
nommé, par exemple, aspnetcore
, avec le contenu suivant:
server { listen 443 ssl; ssl_certificate PATH_TO_CERTIFICATE/CERTIFICATE_NAME.pem; ssl_certificate_key PATH_TO_PRIVATE_KEY/PRIVATE_KEY.pem; location / { proxy_pass http://localhost:5000; }}
Ici, nous configurons Nginx sur listen
sur le port 443 en utilisant SSL (443 est la valeur par défaut pour HTTPS). Ensuite, nous spécifions où se trouvent le certificat (ssl_certificate
) et la clé privée (ssl_certificate_key
) et enfin nous demandons à Nginx de transférer toutes les demandes (location /
correspondra à toutes les demandes) à http://localhost:5000
.
Enfin, créez le lien symbolique vers ce fichier dans sites-enabled
(vous pouvez supprimer le lien vers le fichier default
, cela ne supprimera pas le fichier d’origine car il s’agit d’un lien symbolique).
/etc/nginx/sites-enabled$ sudo ln -s /etc/nginx/sites-available/aspnetcore
Pour que Nginx charge cette configuration:
$ sudo nginx -s reload
Si vous avez votre ASP.NET Application principale s’exécutant à http://localhost:5000
, vous devriez maintenant pouvoir ouvrir https://localhost
et la voir servie via HTTPS.
Un problème courant peut survenir lorsque vous rechargez la configuration Nginx, à savoir que vous êtes invité à entrer un mot de passe. Spécifiquement pour le mot de passe de la clé privée. Cela peut ne pas être pratique pour vous, donc si vous souhaitez supprimer le mot de passe de la clé privée, vous pouvez exécuter la commande suivante:
$ openssl rsa -in privateKeyWithPassword.pem -out privateKeyWithoutPassword.pem
Une autre chose utile que vous pouvez faire avec Nginx est que toutes les demandes de HTTP soient redirigées vers HTTPS. Si vous souhaitez l’activer, ajoutez cette configuration supplémentaire au fichier de configuration aspnetcore
Nginx:
server { listen 80; return 301 https://$host$request_uri;}
Superviseur de configuration
Une chose dont nous devons nous préoccuper est que nous devons garder notre ASP.NET Application web de base en cours d’exécution.
Il existe un outil appelé superviseur qui nous permet de configurer qu’une application doit être lancée au démarrage, et si elle se bloque, elle doit être rétablie
La première chose que nous devons faire est de l’installer. J’utilise Ubuntu 16.04 pour cela, et dans cette distribution, l’installation est très simple:
$ sudo apt-get install supervisor
La prochaine chose que nous devons faire est de créer un fichier de configuration de superviseur pour notre application Web. Appelons-le aspnetcore.conf
et ajoutez-le à /etc/supervisor/conf.d
(vous devez le faire en utilisant sudo):
Placez-le dans le fichier de configuration:
command=/usr/bin/dotnet PATH_TO_YOUR_PUBLISHED_PROJECT/YOURWEBAPP.dlldirectory=PATH_TO_YOUR_PUBLISHED_PROJECTautostart=trueautorestart=truestdout_logfile=/var/log/aspnetcore.out.logstderr_logfile=/var/log/aspnetcore.err.logenvironment=ASPNETCORE_ENVIRONMENT="Production"
La première ligne définit le nom (aspnetcore
) par lequel nous pouvons faire référence à l’application web dans supervisor.
La ligne avec command
définit la commande à exécuter. Dans ce cas, il s’agit de dotnet
suivi de la dll de votre application Web. Cela équivaut à exécuter dotnet run
à la racine de votre projet.
La ligne suivante (directory=
) définit le répertoire de travail comme celui où se trouve votre projet.
autostart=true
signifie que l’application sera démarrée au démarrage.
autorestart=true
signifie que l’application sera redémarrée si elle plante ou même si elle est arrêtée (par exemple en utilisant kill
). Si vous souhaitez que votre application ne soit redémarrée qu’en cas de plantage, remplacez-la par autorestart=unexpected
.
Les deux lignes suivantes définissent dans quels fichiers la sortie standard et la sortie d’erreur sont écrites, respectivement.
Enfin environment
nous permet de définir des variables d’environnement, dans ce cas nous définissons ASPNETCORE_ENVIRONMENT=Production
.
Pour activer ce nouveau fichier de configuration, exécutez les commandes suivantes:
$ sudo supervisorctl reread$ sudo supervisorctl update
Vous pouvez vérifier l’état des processus en cours d’exécution sous supervisor en exécutant
$ sudo supervisorctl
Il devrait afficher quelque chose de similaire à:
aspnetcore EXÉCUTANT pid 18817, uptime 0:05:29
supervisor >
Il existe plusieurs commandes que vous pouvez utiliser pour gérer les commandes suivantes : processus sous superviseur, tapez help
pour une liste des commandes disponibles. Pour quitter, tapez simplement quit
.
Configuration de HTTPS avec IIS
La première étape pour activer HTTPS lors de l’utilisation d’IIS consiste à installer notre certificat et notre clé privée (en utilisant a.fichier pfx qui contient les deux).
Ouvrez le Gestionnaire IIS et sélectionnez Certificats de serveur
Cliquez sur Importer un certificat:
Sélectionnez le.fichier pfx et entrez le mot de passe correspondant, quittez le magasin comme personnel:
Avant de continuer, il est important de mentionner que vous devez avoir le ASP.NET Module de base installé. Il est très probable que vous le fassiez déjà car il est installé pour vous lorsque vous installez le SDK .Net Core.
Cependant, dans le cas où ce n’est pas le cas (vous pouvez le vérifier dans le gestionnaire IIS en ouvrant des modules et vérifier si AspNetCoreModule y est répertorié), vous pouvez trouver des instructions d’installation ici et un lien direct pour le téléchargement du ASP.NET Paquet d’hébergement de serveur principal ici.
Ce que ce module fait est de démarrer votre ASP.NET Site Web principal et continuez à fonctionner (redémarrez-le s’il se bloque). Ce module est également chargé de transmettre les requêtes HTTP à votre application Web, puis de renvoyer les réponses au client.
Une chose importante à savoir sur le module AspNetCoreModule est qu’il est configuré par le fichier web.config
à la racine de votre projet. Vous devez exécuter dotnet publish
sur votre projet pour que web.config
soit configuré correctement dans votre dossier de publication.
L’étape suivante consiste à créer un nouveau pool d’applications et à sélectionner Aucun code géré comme version .NET CLR. Normalement, les sites Web s’exécutent dans un processus de travail IIS, mais dans .NET Core, ils s’exécutent comme un processus séparé, il n’est donc pas nécessaire d’avoir un Runtime .Net dans le pool d’applications:
Enfin, créons un nouveau site Web dans IIS pour notre ASP.NET Application de base. Nous devons sélectionner le pool d’applications que nous venons de créer, sélectionner comme chemin physique le chemin d’accès au site Web publié, sélectionner HTTPS comme liaison et notre certificat dans la liste déroulante Certificat SSL:
Vous devriez maintenant pouvoir utiliser https pour accéder à votre ASP.NET Application de base.