怎樣在服務器上啓用 HTTPS

時間 2019-11-16

標籤怎樣服務器啓用 https 简体版

原文原文鏈接

摘要html

建立一個 2048 位 RSA 公鑰/私鑰對。前端
生成一個嵌入您的公鑰的證書籤名請求 (CSR)jquery
將 CSR 與證書頒發機構 (CA) 共享以接收最終證書或證書鏈。web
將最終證書安裝在非網絡可訪問的位置，例如 /etc/ssl（Linux 和 Unix）或 IIS 須要它的位置 (Windows)。算法

此部分使用 openssl 命令行程序（大部分 Linux、BSD 和 Mac OS X 系統均附帶此程序）來生成私鑰/公鑰和 CSR。數據庫

咱們首先生成一個 2048 位 RSA 密鑰對。較短的密鑰，如 1024 位，不足以抵禦暴力猜想攻擊。較長的密鑰，如 4096 位，則有點過分。長遠來看，隨着計算機處理開銷下降，密鑰長度會增長。目前 2048 是最佳長度。瀏覽器

用於生成 RSA 密鑰對的命令爲：安全

這將生成如下輸出：服務器

在此步驟中，您將公鑰和有關貴組織及網站的信息嵌入到證書籤名請求（或 CSR）中。 openssl 命令以交互方式要求您提供所需的元數據。網絡

運行如下命令：

系統將輸出如下內容：

爲確保 CSR 的有效性，請運行如下命令：

響應結果應以下所示：

對於不一樣的證書頒發機構 (CA)，須要使用不一樣的方法將 CSR 發送給他們。這些方法可能包括在其網站上使用表單、以電子郵件或其餘方式發送 CSR。一些 CA（或其經銷商）甚至可能將其中部分或所有流程自動化（在某些狀況下，包括密鑰對和 CSR 的生成）。

將 CSR 發送給 CA 並按照他們的說明接收最終證書或證書鏈。

對於爲您的公鑰進行證明的服務，不一樣 CA 的收費將有所不一樣。

還能夠選擇將密鑰映射到多個 DNS 名稱，包括多個獨立名稱（例如 example.com、www.example.com、example.net 和 www.example.net 的所有）或「通配符」名稱（例如 *.example.com）。

例如，某個 CA 目前提供如下價格：

標準：16 美圓/年，適用於 example.com 和 www.example.com。
通配符：150 美圓/年，適用於 example.com 和 *.example.com。

按這些價格，當您有 9 個以上子域名時，通配符證書比較划算；您也能夠只購買一個或多個單名稱證書。（例如，若是您有五個以上子域名，在服務器上啓用 HTTPS 時，您可能發現通配符證書更方便。）

Note: 記住，在通配符證書中，通配符只適用於一個 DNS 標籤。對 *.example.com 有效的證書將對 foo.example.com 和 bar.example.com 有效，但對於 foo.bar.example.com 無效。

將證書複製到全部前端服務器的非網絡可訪問位置，例如 /etc/ssl（Linux 和 Unix）或 IIS 須要它們的位置 (Windows)。

在服務器上啓用 HTTPS 是確保網頁安全的關鍵一步。

使用 Mozilla 的服務器配置工具來設置服務器以支持 HTTPS。
按期使用 Qualys 便捷的 SSL 服務器測試來測試網站，並確保得分至少爲 A 或 A+。

此時，您必須作出關鍵的操做決定。選擇下列其中一項：

給爲網絡服務器提供內容的每一個主機名指定一個獨立的 IP 地址。
使用基於名稱的虛擬託管。

若是您一直針對每一個主機名使用獨立的 IP 地址，則能夠輕鬆地讓全部客戶端支持 HTTP 和 HTTPS。

可是，大多數網站運營商使用基於名稱的虛擬託管以節約 IP 地址，另外一個緣由是這樣一般更方便。 Windows XP 上的 IE 和 2.3 版之前的 Android 的問題是，它們不理解服務器名稱指示 (SNI)，而這對 HTTPS 基於名稱的虛擬託管很是重要。

未來有一天（但願很快），不支持 SNI 的客戶端將被現代軟件代替。監控請求日誌中的 User Agent 字符串，以瞭解什麼時候已有足夠的用戶遷移到現代軟件。（您能夠決定您的閾值；多是 < 5%，或 < 1%。）

若是您的服務器上尚未 HTTPS 服務，請當即啓用（無需將 HTTP 重定向到 HTTPS；參見下文）。配置網絡服務器以使用您購買並安裝的證書。您可能發現 Mozilla 便捷的配置生成器頗有用。

若是您有許多主機名/子域名，它們每一個都須要使用正確的證書。

Caution: 若是您已完成上述步驟，但您使用 HTTPS 僅僅是爲了將客戶端重定向回 HTTP，那麼，請立刻中止這麼作。參考下一部分以確保 HTTPS 和 HTTP 順暢工做。

Note: 最終，您應將 HTTP 請求重定向到 HTTPS 並使用 HTTP 嚴格傳輸安全 (HSTS)。不過，如今不是向這種作法進行遷移的合適階段；請參考「將 HTTP 重定向到 HTTPS」和「打開嚴格傳輸安全和安全 Cookie」。

如今，以及您網站的整個生命週期中，使用 Qualys 便捷的 SSL 服務器測試來檢查您的 HTTPS 配置。您的網站得分應爲 A 或 A+；將致使等級較低的任何因素均視爲錯誤。（今天的 A 在明天會變成 B，由於針對算法和協議的攻擊始終在改進！）

因爲您的網站同時運行 HTTP 和 HTTPS，無論哪一種協議，都應當儘量順暢運行。一個重要的因素是對站內連接使用相對網址。

確保站內網址和外部網址與協議無關；即確保使用相對路徑或省去協議，例如 //example.com/something.js。

當您經過 HTTPS 提供一個包括 HTTP 資源的頁面（稱爲混合內容）時會出現問題。瀏覽器將警告用戶，已失去 HTTPS 的所有能力。事實上，若是是主動混合內容（腳本、插件、CSS、iframe），則瀏覽器一般根本不會加載或執行此內容，從而致使頁面殘缺。

Note: 在 HTTP 頁面中包括 HTTPS 資源徹底沒問題。

此外，當您連接到您網站中的其餘頁面時，用戶可能從 HTTPS 降級爲 HTTP。

當您的頁面包括了使用 http:// 架構的徹底限定站內網址時，會出現這些問題。

不建議的作法 — 咱們不建議使用徹底限定站內網址。

換句話說，使站內網址儘量是相對地址：協議相對（省去協議，以 //example.com 開頭）或主機相對（以相對路徑開頭，例如 /jquery.js）。

建議作法 — 咱們建議您使用協議相對站內網址。

建議作法 — 咱們建議您使用相對站內網址。

經過腳本實現，而不是手動操做。若是網站內容在數據庫中，則在數據庫的開發副本中測試您的腳本。若是網站內容由簡單文件組成，則要在文件的開發副本中測試您的腳本。像日常同樣，只有在更改經過 QA 後，纔會將更改推送到生產平臺中。可使用 Bram van Damme 的腳本或相似腳原本檢測網站中的混合內容。

在連接到其餘網站（而不是包括其餘網站的資源）時，請勿更改協議，由於您不能控制這些網站的運行方式。

Success: 爲確保大型網站的遷移更順利，咱們建議採用協議相對網址。若是您還不肯定是否可以徹底部署 HTTPS，則強制網站的全部子資源使用 HTTPS 可能會弄巧成拙。可能會有一段時間，您對 HTTPS 以爲新奇，而且 HTTP 網站仍必須像往常同樣運行。但從長遠看，您將完成遷移並鎖定 HTTPS（請參考接下來兩個部分）。

若是網站依賴第三方（例如 CDN、jquery.com）提供的腳本、圖像或其餘資源，則有兩個選擇：

對這些資源使用協議相對網址。若是該第三方不提供 HTTPS，請求他們提供。大多數已經提供，包括 jquery.com。
從您控制的而且同時提供 HTTP 和 HTTPS 的服務器上提供資源。這一般是個好點子，由於您能夠更好地控制網站的外觀、性能和安全。此外，您沒必要信任第三方，儘管他們老是很不錯。

Note: 請記住，您還須要更改樣式表、JavaScript、重定向規則、 <link> 標記和 CSP 聲明中的站內網址，而不只是 HTML 頁面。

您須要在頁面的最前面放一個規範連接，以告訴搜索引擎 HTTPS 是訪問您網站的最佳方法。

在頁面中設置 <link rel="canonical" href="https://…"/> 標記。這樣可幫助搜索引擎肯定訪問您網站的最佳方法。

此時，您已準備好「鎖定」使用 HTTPS。

使用 HTTP 嚴格傳輸安全 (HSTS) 來避免 301 重定向產生的開銷。
始終在 Cookie 上設置安全標記。

首先，使用嚴格傳輸安全來告訴客戶端，它們始終應經過 HTTPS 來鏈接您的服務器，即便在訪問 http:// 引用時也是如此。

這樣可挫敗 SSL 剝離之類的攻擊，還能避免咱們在將 HTTP 重定向到 HTTPS時啓用的 301 redirect 產生的往返開銷。

Note: 若是您的網站在其傳輸層安全協議 (TLS) 配置中出現過錯誤（例如過時證書），則已將您的網站註明爲已知 HSTS 主機的客戶端可能出現

硬故障

。經過此方式顯式設計 HSTS 可確保網絡攻擊者沒法欺騙客戶端訪問沒有 HTTPS 的網站。在確認您的網站運營足夠可靠以前，不要啓用 HSTS，以免部署 HTTPS 時老是出現證書驗證錯誤。

經過設置 Strict-Transport-Security 標頭來打開 HTTP 嚴格傳輸安全 (HSTS)。OWASP 的 HSTS 頁面有說明連接，提供了針對各類服務器軟件的說明。

大多數網絡服務器提供類似的功能來添加自定義標頭。

Note: max-age 的計算單位爲秒。您能夠從較小的值開始，並隨着您愈來愈熟練自如地運營純 HTTPS 網站而逐步增長 max-age。

還要務必確保客戶端從不經過 HTTP 發送 Cookie（例如用於身份驗證或網站偏好）。例如，若是用戶的身份驗證 Cookie 將在明文中暴露，則其整個會話的安全保障將被破壞 — 即便其餘的一切都正確無誤！

所以，更改您的網絡應用，以便始終在其設置的 Cookie 上設置安全標記。此 OWASP 網頁解釋瞭如何在多個應用框架中設置安全標記。每一個應用框架都採用一種方法來設置此標記。

大多數網絡服務器都提供一種簡單的重定向功能。使用 301 (Moved Permanently) 來告訴搜索引擎和瀏覽器，此 HTTPS 版本是規範的，並將用戶從 HTTP 重定向到網站的 HTTPS 版本。

對於從 HTTP 遷移到 HTTPS，許多開發者有着合情合理的顧慮。Google 網站站長團隊提供了一些很是好的指導【https://plus.google.com/+GoogleWebmasters/posts/eYmUYvNNT5J】。

Google 使用 HTTPS 用做確定性的搜索質量指標【https://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html】。Google 還發佈一個指南，說明在維護其搜索排名時如何傳輸、移動或遷移您的網站。

Bing 也發佈了網站站長指南。

當內容和應用層優化得當時（請參考 Steve Souders 的論著以獲取很好的建議），相對於應用的整體開銷而言，其他的傳輸層安全協議 (TLS) 性能問題通常都是小問題。此外，您能夠減小和分攤那些開銷。（如需 TLS 優化建議和通常建議，請參考 IlyaGrigorik 撰寫的高性能瀏覽器網絡。）另請參考 Ivan Ristic 的 OpenSSL 手冊和 SSL 和 TLS 的防彈衣。

在某些狀況下，TLS 能夠提升性能，主要是能夠採用 HTTP/2 所帶來的結果。 Chris Palmer 在 Chrome 開發峯會 2014 上作過一個演講，討論 HTTPS 和 HTTP/2 的性能。

當用戶從您的 HTTPS 網站連接到其餘 HTTP 網站時，User Agent 不會發送引用站點標頭。若是這是個問題，有多種方法可解決：

其餘網站應遷移到 HTTPS。若是被引用網站能夠完成本指南中的在服務器上啓用 HTTPS 部分，則能夠將您網站中指向他們網站的連接從 http:// 更改成 https://，或可使用協議相對連接。
爲解決引用站點標頭的各類問題，可以使用新的引用站點政策標準。

因爲各搜索引擎正在遷移到 HTTPS，未來，當您遷移到 HTTPS 時，可能會看到更多的引用站點標頭。

Caution: 根據 HTTP RFC，若是引用頁面是經過安全協議傳輸的，則客戶端不能在（非安全）HTTP 請求中包括引用站點標頭字段。

經過展現廣告來賺錢的網站運營商但願確保遷移到 HTTPS 不會下降廣告曝光量。可是，因爲混合內容的安全問題，HTTP <iframe> 在 HTTPS 頁面中不起做用。這裏就存在一個棘手的集體行動問題：在廣告商經過 HTTPS 發佈廣告以前，網站運營商沒法在不損失廣告收入的狀況下遷移到 HTTPS；可是在網站運營商遷移到 HTTPS 以前，廣告商沒有動力來經過 HTTPS 發佈廣告。

廣告商至少應經過 HTTPS 提供廣告服務（例如完成本頁面中的「在服務器上啓用 HTTPS」部分）。許多廣告商已經這樣作了。您應當請求徹底不提供 HTTPS 的廣告商至少開始提供 HTTPS。

歡迎關注京程一燈公衆號：京程一燈，獲取更多前端乾貨內容。