在伺服器上啟用 HTTPS

Chris Palmer

Matt Gaunt

本頁面提供在伺服器上設定 HTTPS 的指引，包括下列步驟：

• 建立 2048 位元 RSA 公開/私密金鑰組。
• 產生內嵌公開金鑰的憑證簽署要求 (CSR)。
• 將 CSR 提供給憑證授權單位 (CA)，以便接收最終憑證或憑證鏈結。
• 將最終憑證安裝在無法透過網路存取的位置，例如 /etc/ssl (Linux 和 Unix) 或 IIS 要求的位置 (Windows)。

產生金鑰和憑證簽署要求

本節使用大多數 Linux、BSD 和 Mac OS X 系統隨附的 openssl 指令列程式，產生私密金鑰、公開金鑰和 CSR。

產生公開/私密金鑰組

首先，請產生 2,048 位元的 RSA 金鑰組。較短的金鑰可能會遭到暴力猜測攻擊，而較長的金鑰會使用不必要的資源。

使用下列指令產生 RSA 金鑰組：

openssl genrsa -out www.example.com.key 2048

這會提供下列輸出內容：

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

產生憑證簽署要求

在這個步驟中，您將公開金鑰和貴機構和網站的相關資訊，嵌入憑證簽署要求或 CSR 中。openssl 指令會要求您提供必要的中繼資料。

執行下列指令：

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

輸出以下內容：

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:[e-mail]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

如要確認 CSR 的有效性，請執行下列指令：

openssl req -text -in www.example.com.csr -noout

回應應如下所示：

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=[e-mail]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

將 CSR 提交給憑證授權單位

不同的憑證授權單位 (CA) 要求您以不同的方式提交 CSR。例如使用網站上的表單，或透過電子郵件傳送 CSR。部分 CA 或其經銷商甚至可能會自動執行部分或所有程序，包括在某些情況下產生金鑰組和 CSR。

將 CSR 傳送給 CA，並按照其指示接收最終憑證或憑證鏈結。

不同的 CA 會針對您的公開金鑰收取不同費用。

您也可以選擇將金鑰對應至多個 DNS 名稱，包括好幾個不同的名稱 (例如所有 example.com、www.example.com、example.net 和 www.example.net)，或是「萬用字元」名稱 (例如 *.example.com)。

注意：在萬用字元憑證中，萬用字元只會套用至一個 DNS 標籤。適用於 *.example.com 的憑證可用於 foo.example.com 和 bar.example.com，但不適用於 foo.bar.example.com。

將憑證複製到所有前端伺服器的非網路存取位置，例如 /etc/ssl (Linux 和 Unix) 或 IIS (Windows) 要求的任何位置。

在伺服器上啟用 HTTPS

在伺服器上啟用 HTTPS 是保護網頁安全的重要步驟。

• 使用 Mozilla 的伺服器設定工具，設定伺服器以支援 HTTPS。
• 請定期使用 Qualys 的安全資料傳輸層 (SSL) 伺服器測試工具測試網站，並確保至少獲得 A 或 A+ 評分。

此時，您必須做出重要的作業決策。請選擇下列其中一種做法：

• 為網路伺服器提供內容的每個主機名稱，指定專屬的 IP 位址。
• 使用以名稱為基礎的虛擬主機。

如果您為每個主機名稱使用了不同的 IP 位址，那麼就可以針對所有用戶端支援 HTTP 和 HTTPS。不過，大多數網站管理員會使用以名稱為基礎的虛擬主機，因為這麼做可以節省 IP 位址，而且一般來說也比較方便。

如果您的伺服器尚未提供 HTTPS 服務，請立即啟用 (不必將 HTTP 重新導向至 HTTPS)。詳情請參閱「將 HTTP 重新導向至 HTTPS」一文。設定網路伺服器以使用您已取得及安裝的憑證。您可能會發現 Mozilla 的設定產生器很實用。

如果您有多個主機名稱或子網域，則每個主機名稱或子網域都必須使用正確的憑證。

警告： 如果您已完成這些步驟，但只想使用 HTTPS 將用戶端重新導向回 HTTP，請立即停止操作。請參閱下一節，確保 HTTPS 和 HTTP 運作順暢。

注意： 最後，您應該將 HTTP 要求重新導向至 HTTPS，並使用 HTTP 嚴格傳輸安全性 (HSTS)。不過，這項作業必須在遷移程序的後續階段進行。詳情請參閱將 HTTP 重新導向至 HTTPS 和啟用嚴格傳輸安全性與安全的 Cookie。

請定期在網站的生命週期中，透過 Qualys 的 SSL 伺服器測試檢查 HTTPS 設定。您的網站應視為 A 或 A+ 評分。請將任何造成較低成績的問題視為錯誤並加以處理，而且也持續努力，因為我們不斷開發針對演算法和通訊協定的新攻擊。

將網站內網址設為相對網址

既然您同時透過 HTTP 和 HTTPS 提供網站，無論使用哪種通訊協定，都必須盡可能順利運作。其中一個重要因素是使用相對網址建立網站內連結。

請確認網站內部網址和外部網址不依賴特定通訊協定。使用相對路徑或省略通訊協定，如同 //example.com/something.js 中的做法。

使用 HTTPS 提供含有 HTTP 資源的網頁可能會發生問題。當瀏覽器遇到使用不安全資源的安全網頁時，會向使用者發出警告，指出該網頁並非完全安全，且某些瀏覽器會拒絕載入或執行 HTTP 資源，導致網頁無法正常運作。不過，您可以安全地在 HTTP 網頁中加入 HTTPS 資源。若要進一步瞭解如何修正這些問題，請參閱修正複合型內容一文。

追蹤網站上其他網頁的 HTTP 連結，也會導致使用者體驗從 HTTPS 降級為 HTTP。如要修正這個問題，請盡可能讓您的內部網址採用通訊協定相關 (缺少通訊協定，開頭為 //example.com) 或主機相關網址 (以 /jquery.js 等路徑開頭)，盡可能讓網址相對較相對。

正確做法

<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>

使用相對內部網址。

正確做法

<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>

或者，使用通訊協定相對網站內部網址。

正確做法

<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>

盡可能使用 HTTPS 網址連結至其他網站。

請使用指令碼更新連結，不要手動更新，以免出錯。如果網站內容位於資料庫中，請在資料庫的開發人員副本上測試指令碼。如果您的網站內容只包含簡單檔案，請在檔案的開發人員副本上測試指令碼。只有在這些變更通過 QA 後，才將變更推送至正式環境。您可以使用 Bram van Damme 的腳本或類似工具，偵測網站中的混合內容。

連結至其他網站 (而非加入其他網站的資源) 時，請勿變更通訊協定。您無法控制這些網站的運作方式。

為了讓大型網站遷移作業能更順暢，建議您使用通訊協定相關網址。如果不確定是否能完整部署 HTTPS，請強制網站對所有子資源使用 HTTPS。在 HTTPS 對您來說是新奇的情況下，HTTP 網站仍必須正常運作。隨著時間的推移，您將完成遷移作業並鎖定 HTTPS (請參閱接下來兩個部分)。

如果您的網站依附於指令碼、圖片或其他第三方 (例如 CDN 或 jquery.com) 提供的資源，您有以下兩種選擇：

• 針對這些資源使用通訊協定相對網址。如果第三方未提供 HTTPS，請要求對方提供。大多數網站都已這麼做，包括 jquery.com。
• 從您控管的伺服器提供資源，該伺服器同時提供 HTTP 和 HTTPS。這通常是個不錯的做法，因為您可以更有效地控管網站的外觀、效能和安全性，而且不必信任第三方來確保網站安全。

注意：您也必須變更樣式表單、JavaScript、重新導向規則、<link> 標記和 CSP 宣告中的網站內網址，而非只在 HTML 頁面中變更。

將 HTTP 重新導向至 HTTPS

如要告知搜尋引擎使用 HTTPS 存取網站，請使用 <link rel="canonical" href="https://…"/> 標記，在每個網頁的標頭中放置標準連結。

啟用嚴格傳輸安全性和安全 Cookie

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

• 使用 HTTP 嚴格傳輸安全性 (HSTS)，避免 301 重新導向的成本。
• 一律在 Cookie 上設定安全旗標。

首先，請使用嚴格傳輸安全性，告訴用戶端應一律使用 HTTPS 連線至伺服器，即使是遵循 http:// 參照時也一樣。這樣做可以打擊安全資料傳輸層 (SSL) 去除等攻擊，也能避免我們將 HTTP 重新導向至 HTTPS 時啟用的 301 redirect 來回費用。

注意：如果您的網站 TLS 設定發生錯誤 (例如憑證過期)，將您的網站列為已知 HSTS 主機的用戶端，可能會硬式失敗。HSTS 的設計目的就是確保網路攻擊者無法欺騙用戶，讓他們在沒有 HTTPS 的情況下存取網站。請先確認網站運作已足夠健全，不會因為憑證驗證錯誤而無法部署 HTTPS，再啟用 HSTS。

如要啟用 HSTS，請設定 Strict-Transport-Security 標頭。OWASP 的 HSTS 頁面提供各種伺服器軟體的操作說明連結。

大多數的網路伺服器都提供類似的功能，可新增自訂標頭。

注意：max-age 是以秒為單位。您可以先從較低的值開始，隨著對 HTTPS 專用網站的操作越來越熟悉，再逐步提高 max-age。

此外，請確認用戶端一律不會透過 HTTP 傳送 Cookie (例如驗證或網站偏好設定)。舉例來說，如果使用者的驗證 Cookie 以純文字形式公開，即使您已正確執行所有其他操作，該使用者的整個工作階段安全保證也會遭到破壞！

為避免這種情況發生，請變更網頁應用程式，讓其一律在設定 Cookie 時設定「安全」標記。這個 OWASP 頁面說明如何在多個應用程式架構中設定 Secure 標記。每個應用程式架構都有設定標記的方法。

大多數網頁伺服器都提供簡單的重新導向功能。使用 301 (Moved Permanently) 向搜尋引擎和瀏覽器指出 HTTPS 版本是標準版本，並將使用者從 HTTP 重新導向至網站的 HTTPS 版本。

搜尋結果排名

Google 將 HTTPS 視為正向的搜尋品質指標。Google 也發布了指南，說明如何轉移、移動或遷移網站，同時維持其搜尋排名。Bing 也會發布網站管理員指南。

成效

當內容和應用程式層經過妥善調整 (請參閱 Steve Souders 的書籍，瞭解相關建議) 後，相較於應用程式的整體成本，剩餘的 TLS 效能問題通常不大。您也可以減少和攤銷這些費用。如需 TLS 最佳化建議，請參閱 Ilya Grigorik 的「High Performance Browser Networking」(高效能瀏覽器網路)，以及 Ivan Ristic 的「OpenSSL Cookbook」和「Bulletproof SSL And TLS」。

在某些情況下，TLS 可提升效能，主要是因為可使用 HTTP/2。詳情請參閱 Chris Palmer 在 2014 年 Chrome 開發人員大會上發表的演講，主題為 HTTPS 和 HTTP/2 效能。

參照標頭

當使用者從 HTTPS 網站點選連結前往其他 HTTP 網站時，使用者代理程式不會傳送 Referer 標頭。如果造成問題，可以透過多種方式解決：

• 其他網站應遷移至 HTTPS。如果推薦網站完成本指南「在伺服器上啟用 HTTPS」一節的操作，您就可以將網站中的連結從 http:// 變更為 https://，或使用通訊協定相關連結。
• 如要解決參照標頭的各種問題，請使用新的參照政策標準。

注意：根據 HTTP RFC，如果參照網頁是透過安全通訊協定傳輸，則用戶端「不得」在 (非安全) HTTP 要求中加入參照來源標頭欄位。

廣告收益

透過放送廣告來營利的網站經營者，希望確保遷移至 HTTPS 不會減少廣告曝光次數。不過，由於混合內容安全性問題，HTTP <iframe> 無法在 HTTPS 網頁上運作。廣告主必須透過 HTTPS 發布廣告，網站經營者才能在不損失廣告收益的情況下遷移至 HTTPS；但網站經營者必須遷移至 HTTPS，廣告主才會願意透過 HTTPS 發布廣告。

您可以開始解決這個僵局，方法是使用透過 HTTPS 提供廣告服務的廣告主，並要求完全不放送 HTTPS 的廣告主至少提供這個選項。您可能需要延遲完成「將內部網址設為相對網址」，直到廣告主的互通性達到一定門檻為止。