Ostatnio, gdy patrzymy na sposób konfiguracji uwierzytelniania przy użyciu zewnętrznych dostawców logowania (np. Google, Facebook) z ASP.NET Core zauważyłem, że https jest teraz wymaganiem dla niektórych z nich.
kolejną rzeczą, którą zauważyłem, było to, jak trudno było znaleźć zasoby dotyczące włączania HTTPS na ASP.NET Rdzeń.
ten post na blogu jest o procesie tworzenia lokalnego ASP.Strona NET Core działa z HTTPS bez błędów w Chrome (pokazując zieloną kłódkę w pasku adresu) dla lokalnego czasu rozwoju. A potem, jak możesz używać Nginx lub IIS, gdy jesteś gotowy, aby odsłonić go światu.
aby korzystać z HTTPS potrzebujemy certyfikatu cyfrowego. Jeśli potrzebujesz wygenerować własne certyfikaty do wykorzystania w czasie programowania, polecam użycie OpenSSL do tworzenia certyfikatów. Wyjaśnia nie tylko, w jaki sposób można utworzyć własny urząd certyfikacji i certyfikaty, ale także w jaki sposób skonfigurować przeglądarkę (Chrome lub Firefox), aby ufała urzędowi certyfikacji.
Ponadto, jeśli chcesz zrozumieć, jaka jest rola certyfikatów w HTTPS, zapoznaj się z krótkim(mniej więcej) wyjaśnieniem, jak działa https.
od teraz zakładam, że wygenerowałeś swój urząd certyfikacji, certyfikat i odpowiedni klucz prywatny i masz .plik pfx (Personal Information Exchange).
Stwórz nowy projekt
opiszę proces używając kodu Visual Studio i Yeoman.
jeśli nie jesteś zaznajomiony z yeoman, jest to narzędzie wiersza poleceń, które pozwala tworzyć nowe projekty z listy szablonów projektów. Generator yeoman (tak nazywa się pakiet dla yeoman, który zawiera szablony), którego będziemy używać, to generator-aspnet. Aby zainstalować yeoman najpierw potrzebujesz npm, a następnie możesz postępować zgodnie z instrukcjami instalacji yeoman i ASP.NET podstawowe szablony tutaj.
powodem użycia Visual Studio Code i yeoman jest to, że proces ten działa na systemach Windows, Linux i macOS.
aby uzywac Ziemian z ASP.NET podstawowe szablony uruchamiają następujące polecenie:
$ 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#) wybierz opcję pusta aplikacja internetowa. Zostanie utworzony prosty projekt internetowy, który ma tylko stronę z tekstem „Hello World”.
jeśli używasz Windows i masz pełną wersję Visual Studio możesz po prostu zrobić plik – > Nowy Projekt, wybierz. Net Core, ASP.NET Core Web Application, a następnie wybierz Empty.
Konfigurowanie HTTPS dla Kestrel
Kestrel jest serwerem sieci Web używanym domyślnie z ASP.NET Rdzeń.
aby dodać obsługę HTTPS do Kestrel Dodaj pakiet Microsoft.AspNetCore.Server.Kestrel.Https jako zależność.
jeśli używasz projektu.json możesz to zrobić edytując projekt.sekcja „zależności” jsona i dodawanie:
"Microsoft.AspNetCore.Server.Kestrel.Https": "1.1.0"numer wersji może być inny dla ciebie, jednak powinien być taki sam jak w pakiecie Microsoft.AspNetCore.Server.Kestrel.
jeśli używasz .csproj możesz dodać zależność, uruchamiając:
dotnet add package Microsoft.AspNetCore.Server.Kestrel.HttpsKonfiguracja certyfikatu
aby skonfigurować Kestrel do korzystania z naszego .plik pfx (certyfikat i klucz prywatny) musimy edytować Program.cs gdzie jest tworzony WebHostBuilder i wprowadzić kilka zmian:
var host = new WebHostBuilder() .UseConfiguration(config) .UseKestrel(options => { options.UseHttps("localhost.pfx", "password"); }) .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration() .UseUrls("https://*:4430") .UseStartup<Startup>() .Build();zmiany są:
.UseKestrel(options => { options.UseHttps("localhost.pfx", "password");})czyli gdzie określamy co to jest .plik pfx, którego chcemy użyć i jego hasło. UseHttps jest metodą rozszerzenia, Jeśli pojawi się błąd mówiący, że nie istnieje, to dlatego, że nie dodałeś pakietu nuget Microsoft.AspNetCore.Server.Kestrel.Https, który jest tam, gdzie mieszka.
:
.UseUrls("https://*:4430")która określa gdzie będą nasłuchiwane połączenia przychodzące. Alternatywnie możesz użyć https://localhost:4430 zamiast *. W przypadku * możesz jednak użyć dowolnej nazwy domeny, na przykład jeśli masz tę aplikację internetową w myDomain.com, nadal będzie ona działać, podczas gdy w przypadku localhost będą obsługiwane tylko żądania do localhost.
w przypadku, gdy zastanawiasz się, dlaczego nie użyłem domyślnego portu HTTPS, 443, to dlatego, że potrzebujesz specjalnych uprawnień na Linuksie dla portów poniżej 1024. W systemie Windows nie byłoby to problemem. Ponieważ jednak robienie tego z Pustułką jest zalecane tylko wtedy, gdy jesteś w czasie rozwoju, nie jest to duży problem.
jeśli próbujesz tego w systemie Linux, macOS lub używając wiersza poleceń w systemie Windows, możesz zadzwonić do dotnet run, otworzyć Chrome i przejść do https://localhost:43000 i zobaczyć zieloną ikonę kłódki.
jeśli używasz full Visual Studio w systemie Windows, sposobem na to jest określenie, że chcesz uruchomić aplikację internetową bezpośrednio, a nie za pośrednictwem usługi IIS Express:
wybierz również przeglądarkę, na której chcesz ją wypróbować. Jeśli zainstalowałeś certyfikat głównego urzędu certyfikacji testowego w określonej przeglądarce, użyj tej przeglądarki, na przykład Chrome (jeśli nie rozumiesz tego stwierdzenia, zalecam przeczytanie krótkiego (mniej więcej) wyjaśnienia, jak działa https i używanie OpenSSL do tworzenia certyfikatów):
na koniec Edytuj właściwości projektu (kliknij prawym przyciskiem myszy i wybierz Właściwości):
i zmień adres URL uruchamiania:
używając ASP.NET rdzeń z odwrotnym proxy
chociaż z pewnością jest możliwe, aby służyć aplikacji internetowej za pomocą ASP.NET Rdzeń przy użyciu tylko pustułki, nie jest zalecane. Dzieje się tak dlatego, że Kestrel nie jest w pełni funkcjonalnym serwerem internetowym i nadal brakuje mu pewnych funkcji bezpieczeństwa.
mimo, że nie jest to zalecane, możesz po prostu pokazać komuś coś, co zrobiłeś i pominąć część instalacji i konfiguracji serwera www. Dzięki usługom takim jak DigitalOcean lub Linode możesz stworzyć VPS w bardzo krótkim czasie i po prostu mieć swój ASP.NET Core dostępny tam tylko po zainstalowaniu. NET core.
jednak, jeśli chcesz czegoś poważniejszego (a prawdopodobnie tak, ponieważ jesteś tutaj z powodu włączenia HTTPS), powinieneś użyć w pełni funkcjonalnego serwera sieci web, takiego jak Nginx lub IIS (w systemie Windows), jako odwrotnego proxy do twojego ASP.NET Podstawowe zastosowanie.
serwer odwrotnego proxy to serwer WWW, który przyjmuje żądania i wysyła je do innego serwera WWW, który faktycznie tworzy odpowiedzi na te żądania. Odpowiedzi są wysyłane z powrotem do serwera proxy, który przekazuje je klientom, którzy wydali odpowiednie żądania.
z Nginx działającym jako odwrotne proxy wyglądałoby to mniej więcej tak:
Browser <----> Nginx <----> Kestreldobrą rzeczą w tej konfiguracji jest to, że możemy wykorzystać Nginx (lub IIS) jako pełny serwer WWW i włączyć na nim HTTPS:
Browser <---- HTTPS ---> Nginx <---- HTTP ----> Kestrelwięc nie musimy nawet konfigurować Kestrel z HTTPS, po prostu Nginx.
Konfigurowanie HTTPS za pomocą Nginx
najpierw musisz zainstalować Nginx. Używam do tego Ubuntu 16.04, jednak można go nawet zainstalować na Windows.
jeśli używasz Ubuntu otwórz terminal i wpisz
$ sudo apt-get install nginx następną rzeczą, którą musimy zrobić, to edytować konfigurację Nginx. Ale zanim to zrobimy, warto wiedzieć, jaka jest lokalizacja plików konfiguracyjnych i jak stają się one włączone. Folder, w którym zazwyczaj umieszczane są pliki konfiguracyjne, to /etc/nginx/sites-available/ (ta lokalizacja może być inna, jeśli używasz innej dystrybucji Linuksa).
plik konfiguracyjny obecny podczas instalacji Nginx nosi nazwę default.
aby konfiguracja Nginx stała się włączona, musi znajdować się w folderze /etc/nginx/sites-enabled. Tak więc po utworzeniu nowego pliku konfiguracyjnego (w sites-available) w sites-enabled tworzy się dowiązanie symboliczne, które wskazuje na nowy plik.
wyobraź sobie, że właśnie stworzyliśmy nowy plik konfiguracyjny o nazwie my-site-https w sites-available. Następnie przejdź do folderu sites-enabled i uruchom następujące polecenie, aby utworzyć dowiązanie symboliczne:
$ ln -s /etc/nginx/sites-available/my-site-httsaby nginx odczytał nową konfigurację uruchom polecenie:
$ sudo nginx -s reloadteraz, gdy wiemy, jak tworzyć i włączać konfiguracje Nginx, stwórzmy plik konfiguracyjny do Ustawienia Nginx jako odwrotnego proxy do ASP.NET Podstawowa aplikacja, która działa w http://localhost:5000.
najpierw Utwórz nowy plik w /etc/nginx/sites-available o nazwie, na przykład aspnetcore, z następującą zawartością:
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; }}tutaj konfigurujemy Nginx do listen na port 443 przy użyciu SSL (443 jest domyślnym dla HTTPS). Następnie określamy, gdzie znajduje się certyfikat (ssl_certificate) i klucz prywatny (ssl_certificate_key) i na koniec instruujemy Nginx, aby przekazał wszystkie żądania (location / dopasuje wszystkie żądania) do http://localhost:5000.
na koniec utwórz dowiązanie symboliczne do tego pliku w sites-enabled(możesz usunąć dowiązanie do pliku default, nie usunie to oryginalnego pliku, ponieważ jest to dowiązanie symboliczne).
/etc/nginx/sites-enabled$ sudo ln -s /etc/nginx/sites-available/aspnetcoreaby nginx załadował tę konfigurację:
$ sudo nginx -s reloadjeśli masz swoje ASP.NET Core application uruchomiony na http://localhost:5000 powinieneś być teraz w stanie otworzyć https://localhost i zobaczyć, że jest obsługiwany przez HTTPS.
istnieje powszechny problem, który może się zdarzyć po ponownym załadowaniu konfiguracji Nginx, czyli zostaniesz poproszony o hasło. Specjalnie dla hasła klucza prywatnego. Może to nie być dla Ciebie praktyczne, więc jeśli chcesz usunąć hasło z klucza prywatnego, możesz uruchomić następujące polecenie:
$ openssl rsa -in privateKeyWithPassword.pem -out privateKeyWithoutPassword.peminną przydatną rzeczą, którą możesz zrobić z Nginx, jest przekierowanie wszystkich żądań do HTTP na HTTPS. Jeśli chcesz to włączyć dodaj tę dodatkową konfigurację do pliku konfiguracyjnego aspnetcore Nginx:
server { listen 80; return 301 https://$host$request_uri;}Konfigurowanie nadzorcy
jedną rzeczą, którą musimy się martwić, jest to, że musimy zachować nasze ASP.NET Core web application running.
istnieje narzędzie o nazwie supervisor, które pozwala nam skonfigurować, że aplikacja powinna być inicjowana podczas uruchamiania, a jeśli ulegnie awarii, powinna zostać przywrócona
pierwszą rzeczą, którą musimy zrobić, to ją zainstalować. Używam do tego Ubuntu 16.04 i w tej dystrybucji instalacja jest bardzo prosta:
$ sudo apt-get install supervisornastępnie musimy utworzyć plik konfiguracyjny Supervisora dla naszej aplikacji webowej. Nazwijmy go aspnetcore.conf i dodaj go do /etc/supervisor/conf.d(musisz to zrobić za pomocą sudo):
Umieść to w pliku konfiguracyjnym:
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"pierwsza linia definiuje nazwę (aspnetcore), przez którą możemy odnieść się do aplikacji webowej w supervisorze.
linia z command definiuje polecenie do uruchomienia. W tym przypadku jest to dotnet, a następnie dll aplikacji internetowej. Jest to równoważne z uruchomieniem dotnet run w katalogu głównym projektu.
następna linia (directory=) ustawia katalog roboczy jako katalog, w którym znajduje się twój projekt.
autostart=true oznacza, że aplikacja zostanie uruchomiona podczas uruchamiania.
autorestart=true oznacza, że aplikacja zostanie uruchomiona ponownie w przypadku awarii lub nawet zatrzymania (na przykład przy użyciu kill). Jeśli chcesz, aby Twoja aplikacja została ponownie uruchomiona tylko w przypadku awarii, zmień ją na autorestart=unexpected.
dwie następne linie definiują, do których plików zapisywane są odpowiednio wyjście standardowe i wyjście błędu.
wreszcie environment pozwala nam ustawić zmienne środowiskowe, w tym przypadku ustawiamy ASPNETCORE_ENVIRONMENT=Production.
aby włączyć ten nowy plik konfiguracyjny, uruchom następujące polecenia:
$ sudo supervisorctl reread$ sudo supervisorctl updatemożesz sprawdzić stan procesów działających pod kontrolą nadzorcy, uruchamiając
$ sudo supervisorctlpowinien wyświetlić coś podobnego do:
aspnetcore uruchomiony pid 18817, uptime 0:05:29
supervisor>
istnieje więcej poleceń, których możesz użyć do zarządzania procesy w sekcji nadzorca wpisz help, aby wyświetlić listę dostępnych poleceń. Aby zakończyć, wystarczy wpisać quit.
Konfigurowanie protokołu HTTPS za pomocą usług IIS
pierwszym krokiem włączania protokołu HTTPS podczas korzystania z usług IIS jest zainstalowanie naszego certyfikatu i klucza prywatnego (za pomocą .plik pfx, który zawiera oba).
Otwórz Menedżera usług IIS i wybierz certyfikaty serwera
kliknij Importuj certyfikat:
Wybierz .plik pfx i wprowadź odpowiednie hasło, Wyjdź ze sklepu jako osobisty:
zanim przejdziemy dalej ważne jest, aby wspomnieć, że musisz mieć ASP.NET zainstalowany moduł podstawowy. Jest bardzo prawdopodobne, że już to robisz, ponieważ jest zainstalowany dla Ciebie podczas instalacji.Net Core SDK.
jednak w przypadku, gdy nie jest (możesz to sprawdzić w Menedżerze IIS, otwierając moduły i sprawdzając, czy AspNetCoreModule jest tam wymieniony), możesz znaleźć instrukcje instalacji tutaj i bezpośredni link do pobrania ASP.NET Core Server Hosting Bundle tutaj.
to co ten moduł robi to uruchamia Twój ASP.NET Podstawowa strona i utrzymuj ją w działaniu (uruchom ją ponownie, jeśli ulegnie awarii). Moduł ten jest również odpowiedzialny za przekazywanie żądań HTTP do aplikacji internetowej, a następnie przekazywanie odpowiedzi z powrotem do klienta.
ważną rzeczą, którą należy wiedzieć o AspNetCoreModule jest to, że jest on skonfigurowany przez plik web.config w katalogu głównym projektu. Musisz uruchomić dotnet publish w swoim projekcie, aby poprawnie skonfigurować web.config w folderze publikuj.
następnym krokiem jest utworzenie nowej puli aplikacji i wybranie No Managed Code jako wersji.NET CLR. Zwykle witryny działają wewnątrz procesu roboczego usług IIS, ale w środowisku. NET Core działają jako osobny proces, więc nie ma potrzeby korzystania z środowiska wykonawczego. Net w puli aplikacji:
na koniec stwórzmy nową stronę internetową wewnątrz IIS dla naszego ASP.NET Podstawowe zastosowanie. Musimy wybrać właśnie utworzoną pulę aplikacji, wybrać jako ścieżkę fizyczną ścieżkę do opublikowanej witryny, wybrać HTTPS jako powiązanie i nasz certyfikat w rozwijanym menu certyfikat SSL:
powinieneś teraz móc używać https, aby przeglądać swoje ASP.NET Podstawowa aplikacja.
