在伺服器上啟用 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，並按照其指示接收最終憑證或憑證鏈結。

不同的憑證授權單位會針對公開金鑰的擔保服務收取不同金額的費用。

您也可以選擇將金鑰對應至多個 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 網址連結至其他網站。

請使用指令碼更新連結，不要手動更新，以免出錯。如果網站內容位於資料庫中，請在資料庫的開發人員副本上測試指令碼。如果您的網站內容只包含簡單檔案，請在檔案的開發人員副本上測試指令碼。請務必等到變更通過品質管控後，再將變更內容推送至實際執行環境。您可以使用 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 上設定 Secure 標記。

首先，請使用嚴格傳輸安全性，告訴用戶端應一律使用 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 的廣告主至少提供這個選項。您可能需要延後完成「讓網站內網址保持相對性」作業，直到有足夠的廣告主正確進行互動為止。