合格的web后端程序員，除搬磚技能，還必須會給各種web服務器啟用Https，本文結合ASP.NET Core部署模型聊一聊啟用Https的方式。

溫故知新

????目前常見的Http請求明文傳輸，請求可能被篡改，訪問的站點可能被偽造。

HTTPS是HTTP加上TLS/SSL協(xié)議構建的可進行加密傳輸、身份認證的網絡協(xié)議，主要通過數(shù)字證書、加密算法、非對稱密鑰等技術完成互聯(lián)網數(shù)據傳輸加密，實現(xiàn)互聯(lián)網傳輸安全保護。

流程解讀

① 傳輸密鑰是對稱密鑰，用于雙方對傳輸數(shù)據的加解密

② 怎么在傳輸之前確立傳輸密鑰呢？

????答：針對普遍的多客戶端訪問受信web服務器的場景， 提出非對稱密鑰（公鑰下發(fā)給客戶端，私鑰存于web服務器），雙方能互相加解密，說明中間數(shù)據（傳輸密鑰）沒被篡改。

③ 再拋出疑問，客戶端如何認定下發(fā)的公鑰是目標web服務器的公鑰？又如何確定公鑰下發(fā)過程沒被截取篡改？

????答：追溯到握手階段的證書驗證過程，瀏覽器從證書提取（證書頒發(fā)機構，證書綁定的域名，證書簽名，證書有效期）；瀏覽器先驗證證書綁定的域名是否與目標域名匹配；瀏覽器內置證書頒發(fā)機構認定該證書是其有效下發(fā)；通過簽名認定該證書沒被篡改

④ 所以瀏覽器內置的證書機構（根證書）的權威性很重要，?中毒或山寨瀏覽器可能攜帶非法的根證書。

如果面向面試記憶Https原理，恐怕有些難度，所以個人用一種 【雞生蛋還是蛋生雞】的方式向上追溯流程， 方便大家知其然更知其所以然。

下面演示對ASP.NET Core程序兩種常見部署模型強制應用Https。

常規(guī)反向代理模型

由nginx反向代理請求到后端https://receiver.server， 在nginx上添加HTTPS證書， 并強制使用HTTPS。

worker_processes 4; events { worker_connections 1024; } http {sendfile on;upstream receiver_server {server receiver:80;}server {listen 80;listen [::]:80;server_name eqid.******.com;return 301 https://eqid.******.com$request_uri;}server {listen 443 ssl;listen [::]:443 ssl;ssl on;server_name eqid.******.com;ssl_certificate /conf.crt/live/******.com.crt;ssl_certificate_key /conf.crt/live/******.com.key;location / {proxy_pass http://receiver_server;proxy_http_version 1.1;proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection keep-alive;proxy_redirect off;proxy_set_header Host $host;proxy_cache_bypass $http_upgrade;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $scheme;}} }

dotnet.exe自宿模型

Kestrel用作邊緣（面向Internet）Web服務器， 這個部署模型不常見，但依舊存在。

我們利用 Visual Studio 2019項目模板構建 ASP.NetCore項目--- 勾選HTTPS支持， 會默認添加支持Https的Middleware；

• app.UseHttpsRedirection()? ?強制Http請求跳轉到Https

• app.UseHsts()??指示瀏覽器為特定主機頭在特定時間范圍內的所有通信應用Https。

HSTS（HTTP Strict Transport Protocol）的作用是強制瀏覽器使用HTTPS與服務器創(chuàng)建連接，避免原有的301重定向Https時可能發(fā)生中間人劫持。

服務器開啟HSTS的方法是，當客戶端通過HTTPS發(fā)出請求時，在服務器返回的超文本傳輸協(xié)議響應頭中包含Strict-Transport-Security字段。非加密傳輸時設置的HSTS字段無效。

Development證書

VS模板構建的web會使用dotnet cli 提供的開發(fā)證書在https://localhost:5001 地址接收請求。

關于開發(fā)證書, 可倒騰 dotnet dev-certs https --help 命令：

dotnet dev-certs https -c清除證書，啟動程序會報無服務器證書異常；

dotnet dev-certs https -t信任證書，會彈窗提示確認安裝名為localhost的開發(fā)根證書：

- 否：web能正常啟動，Https請求將獲取無效證書，瀏覽器地址欄警示▲不安全(提示瀏覽器不信任localhost根證書，證書無效)

- 是：web正常啟動，瀏覽器發(fā)在地址欄顯示正常的Httsp小鎖?圖標

在Windows上，最安全方式是使用certificate store來注冊已認證的HTTPS，但是有時候希望在程序內綁定證書+私鑰， 這樣便于在不同平臺上部署。

文件證書

ASP.NET Core支持使用硬盤上文件證書來建立Https連接（這在linux上很常見）。

以下代碼允許Kestrel傳入文件證書和私鑰，并建立Https連接。

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>WebHost.CreateDefaultBuilder(args).UseKestrel(options =>{options.Listen(IPAddress.Loopback, 5000);options.Listen(IPAddress.Loopback, 5001, listenOptions =>{listenOptions.UseHttps("certificate.pfx", "topsecret");});}).UseStartup<Startup>();

務必確保不要將私鑰存儲在配置文件中：在開發(fā)模式，可使用user secrets?存儲此類密鑰；在生產模式，可考慮Azure Key Vault或環(huán)境變量。

更多密鑰分離策略請參考：?密鑰分離，.Net程序猿不再背鍋

總結

希望本文有助于您大致了解ASP.NET Core中Https的應用方式。

這不是什么高深的理論，而是嘗試以不同的方式啟用Https、并著重解釋相關中間件的用法。

總結

以上是生活随笔為你收集整理的2020年了，再不会Https就老了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。