摘要
- 創建一個 2048 位 RSA 公鑰/私鑰對。
- 生成一個嵌入您的公鑰的證書籤名請求 (CSR)
- 將 CSR 與證書頒發機構 (CA) 共享以接收最終證書或證書鏈。
- 將最終證書安裝在非網絡可訪問的位置，例如 /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> 標記。這樣可幫助搜索引擎確定訪問您網站的最佳方法。
此時，您已準備好“鎖定”使用 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 發佈廣告。/<iframe>
廣告商至少應通過 HTTPS 提供廣告服務（例如完成本頁面中的“在服務器上啟用 HTTPS”部分）。 許多廣告商已經這樣做了。您應當請求完全不提供 HTTPS 的廣告商至少開始提供 HTTPS。
閱讀更多 前端技術教學分享 的文章
