在伺服器上啟用 HTTPS

帕爾默 (Chris Palmer)
Chris Palmer
Matt Gaunt
Twitter 首頁

本文提到的步驟

  1. 建立 2048 位元 RSA 公開/私密金鑰組。
  2. 產生嵌入公開金鑰的憑證簽署要求 (CSR)。
  3. 與憑證授權單位 (CA) 共用您的 CSR，即可接收最終憑證或憑證鏈結。
  4. 請將最終憑證安裝在無法透過網路存取的位置，例如 /etc/ssl (Linux 和 Unix) 或 IIS 的需要位置 (Windows)。

產生金鑰和憑證簽署要求

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

產生公開/私密金鑰組

首先，請產生 2,048 位元 RSA 金鑰組。較小的金鑰 (例如 1,024 位元) 並不足以防止受到暴力猜測的攻擊。一個較大的索引鍵 (例如 4,096 位元) 會導致過度終止。一段時間後，金鑰大小就會隨著電腦處理作業的成本降低而增加。目前最滿意的水準是 2,048。

產生 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 []:webmaster@example.com

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=webmaster@example.com
        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)。

舉例來說，有一個憑證授權單位目前提供以下價格：

  • 標準：每年 $16 美元，example.com 和 www.example.com 有效。
  • 萬用字元：每年 $150 美元，適用於 example.com 和 *.example.com。

在這些價格上，當您擁有超過 9 個子網域時，使用萬用字元是非常經濟實惠的選擇；否則，您只需購買一或多個單一名稱的憑證即可。(如果擁有超過五個子網域，在伺服器上啟用 HTTPS 時，或許會覺得萬用字元憑證比較方便)。

請將憑證複製到無法連上網路的位置 (例如 /etc/ssl (Linux 和 Unix) 或 IIS (Windows) 等) 的所有前端伺服器。

在您的伺服器上啟用 HTTPS

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

  • 請使用 Mozilla 的伺服器設定工具調整伺服器，以支援 HTTPS。
  • 透過 Qualys 便利的安全資料傳輸層 (SSL) 伺服器測試，定期測試你的網站，確保至少取得 A 或 A+。

在這個階段，您必須做出重要的營運決策，請選擇下列其中一個選項：

  • 為網路伺服器提供內容的每個主機名稱分別指定不同的 IP 位址。
  • 使用以名稱為基礎的虛擬託管。

如果您為每個主機名稱都使用不同的 IP 位址，就可以輕鬆支援所有用戶端的 HTTP 和 HTTPS。

不過，大多數網站運算子都會使用名稱式虛擬主機來節省 IP 位址，因為一般來說會比較方便。在 Windows XP 和 Android 2.3 以下版本中，IE 的問題是他們無法瞭解伺服器名稱指標 (SNI)，這對 HTTPS 名稱式虛擬託管來說極為重要。

有一天，不久後支援 SNI 的用戶端將替換為新型軟體。監控要求記錄中的使用者代理程式字串，瞭解使用者有多少使用者已遷移至現代化軟體。(您可以自行設定門檻，可能低於 5%，不超過 1%)。

如果您的伺服器尚未提供 HTTPS 服務，請立即啟用 (而不將 HTTP 重新導向至 HTTPS；詳情請見下文)。設定網路伺服器以使用您購買及安裝的憑證。您可以發現 Mozilla 的便利設定產生器相當實用。

如果您有多個主機名稱或子網域，這些主機名稱或子網域都需要使用正確的憑證。

現在，而在整個網站的生命週期，請透過 Qualys 便利的安全資料傳輸層 (SSL) 伺服器測試來檢查 HTTPS 設定。網站應能得到 A 或 A+ 分；將任何導致低分的項目視為錯誤。(今天的 A 是明天的 B，因為對演算法和通訊協定的攻擊會不斷進步！)

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

現在，您同時是透過 HTTP 和 HTTPS 提供網站，因此無論通訊協定為何，都必須盡可能順暢運作。其中一項重要的因素是 內部連結使用相對網址

請確保內部網址和外部網址適用於通訊協定，也就是說，請務必使用相對路徑或排除 //example.com/something.js 等通訊協定。

如果您透過 HTTPS 提供含有 HTTP 資源的網頁 (稱為「混合內容」)，就會發生問題。瀏覽器會警告使用者 HTTPS 的完整優勢已遺失。事實上，在使用主動式複合型內容 (指令碼、外掛程式、CSS、iframe) 的情況下，瀏覽器通常完全無法載入或執行內容，因而導致網頁毀損。請注意，將 HTTPS 資源納入 HTTP 網頁是完全正常的。

此外，如果您連結至網站中的其他網頁，使用者可能會從 HTTPS 降級為 HTTP。

如果您的網頁包含使用 http:// 配置的完整內部網址，就會發生這類問題。

錯誤做法
<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
請避免使用完整的內部網站網址。

換句話說，盡可能增加內部網站網址的相對關係：通訊協定相關 (缺少通訊協定，開頭為 //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，請要求他們使用 HTTPS。大多數人都有這種說法，包括 jquery.com。
  • 從您控管的伺服器提供資源，採用 HTTP 和 HTTPS。無論如何，通常都是很好的作法，因為這樣您就可以進一步掌控網站的外觀、效能和安全性。此外，您也不必信任第三方，這很不錯。

將 HTTP 重新導向至 HTTPS

您必須在網頁標頭中加入標準連結，告知搜尋引擎 HTTPS 是前往您的網站的最佳方式。

在網頁上設定 <link rel="canonical" href="https://…"/> 標記。可協助搜尋引擎判斷前往網站的最佳方式。

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

此時，您已經準備好開始使用 HTTPS。

  • 如要避免 301 重新導向的費用，請使用 HTTP 嚴格傳輸安全性 (HSTS)。
  • 請一律為 Cookie 設定安全標記。

首先，使用嚴格傳輸安全性告知用戶端，即使遵循 http:// 參照，也應一律透過 HTTPS 連線至您的伺服器。這可抵禦 SSL 去除等攻擊，還能避免將 HTTP 重新導向至 HTTPS 中啟用的 301 redirect 往返費用。

設定 Strict-Transport-Security 標頭以啟用 HTTP 嚴格傳輸安全性 (HSTS)。如需各種伺服器軟體的操作說明連結，請參閱 OWASP 的 HSTS 頁面。

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

此外，請務必確認用戶端絕對不會透過 HTTP 傳送 Cookie (例如驗證或網站偏好設定)。舉例來說，如果使用者的驗證 Cookie 以純文字形式公開，則即使您已經妥善完成其他所有步驟，整個工作階段的安全保證仍會遭到刪除！

因此，請變更網頁應用程式，一律在其設定的 Cookie 上設定安全標記。這個 OWASP 頁面說明如何在多個應用程式架構中設定安全標記。每個應用程式架構都可以設定旗標。

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

搜尋結果排名

Google 使用 HTTPS 做為正面的搜尋品質指標。 此外，Google 也發布了如何轉移、移動或遷移網站的指南，說明如何維持網站的搜尋排名。此外，Bing 也會發布網站管理員指南。

效能

如果內容和應用程式層經過妥善調整 (請參閱 Steve Souders 書籍瞭解實用建議)，相對於應用程式的整體成本，剩餘的傳輸層安全標準 (TLS) 效能問題通常並不多。此外，您也可以減少及降低這些費用。(如需有關傳輸層安全標準 (TLS) 最佳化作業的實用建議，請參閱 Ilya Grigorik 的「High Performance Browser Networking」(高效能瀏覽器網路)。另請參閱 Ivan Ristic 的 OpenSSL 教戰手冊和防彈 SSL 和 TLS。

在某些情況下，TLS 可以「改善」效能，主要是因為可以採用 HTTP/2。Chris Palmer 在 2014 年 Chrome 開發人員高峰會的 HTTPS 和 HTTP/2 效能上發表了演講。

參照網址標頭

如果使用者點選從您的 HTTPS 網站前往其他 HTTP 網站，使用者代理程式不會傳送參照網址標頭。如果發生問題，有幾種方式可以解決問題：

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

由於搜尋引擎正在遷移至 HTTPS，因此未來在遷移至 HTTPS 時，您可能會看見「更多」參照網址標頭。

廣告收益

網站營運商為了顯示廣告而顯示廣告，希望確保遷移至 HTTPS 不會減少廣告曝光次數。不過由於複合型內容安全疑慮，HTTP <iframe> 無法在 HTTPS 網頁中運作。這有點困難的集體行動問題：在廣告客戶透過 HTTPS 發布應用程式之前，網站經營者無法遷移至 HTTPS 而不會失去廣告收益；但除非網站營運商遷移至 HTTPS，否則廣告客戶沒有動機發布 HTTPS 的動機。

廣告客戶至少應透過 HTTPS 提供廣告服務 (例如填寫本頁面的「在伺服器上啟用 HTTPS」一節)。不過許多人已經完成相關作業。 請至少先要求未提供 HTTPS 的廣告主起頭。 建議您延遲完成「將 IntraSite 網址相對」，直到足夠的廣告客戶正確互通為止。