現在網站越來越需要 HTTPS，而這正是順應了發展趨勢。Chrome 現已將帶有密碼或信用卡字段的 HTTP 網站明確標記為“不安全的”。在過去的一年里，我一直在將我的客戶端網站切換到 HTTPS 上。事實證明，作為系統管理員的工作總是這樣做，也存在與此相關的隱藏的挑戰。

HTTPS 簡述

在我們深入下面的細節之前，我們先弄清寫這篇文章的目的。

從同一服務器上托管多個 HTTPS 網站的問題與 HTTPS 連接的建立方式有關。安全的（讀取：不是pwned）HTTPS 是在 TLS 上運行。當 TLS 連接建立時，我們傾向于認為它是與網站構建的。在技術上這是不正確的。 TLS 連接是連接到特定的 ip 地址。一旦你連接到那個 IP，服務器會假定這就是你想訪問的網站。這意味著您不能在同一 IP 地址的主機上托管的多個 HTTPS 網站。

進入（和退出）SNI

SNI（服務器名稱標識）是一項在 21 世紀初期就被引入的協議，引入的目的就是為了解決這個問題。它是一種用于在瀏覽器設置一個 TLS 連接時向網頁服務器發送一個域名的方法。通過在初次握手階段傳入域名，網頁服務器就可以知道你想要訪問的是哪一個域，從而讓其為正確的那一個提供服務。

不過盡管其已經得到了廣泛的支持，但也有不被支持的情況。我自己就曾在處理對 SNI 的依賴時掉進了移動端瀏覽器的坑。從另外一方面來看，IP 地址是廉價的，好像是 1 $/月，或者還要更便宜。因此你索性可以為你的 HTTPS 站點單獨弄一個 IP，這樣做所避免掉的一些在終端/瀏覽器組合上遇到的頭疼事兒，花費的代價可能百倍不止。

添加 IP 地址

對于初學者而言，首先需要給每一個你準備從同一臺服務器上托管在 HTTPS 上的域名獲取一個 IP。大多數像 Linode 以及 AWS 這樣的托管平臺都提供了為任何東西添加 IP 的能力。

$ ping you.new.ip.addrPING you.new.ip.addr (you.new.ip.addr): 56 data bytes  Request timeout for icmp_seq 0  Request timeout for icmp_seq 1  ...這是因為服務器忽略了沒有配置的 IP 地址。要讓服務器看到那些輸入的 IP，我們需要更新網絡接口。這聽起來很可怕，但實際上并沒有那么壞。我們開始編輯 /etc/network/interfaces 這個文件。 你大概會有一個龐大的清單是關于你的服務器所需要存儲的 IP 地址的。
# Something like this PRobably already existsauto eth0  iface eth0 inet static      address X.X.X.X/24    gateway X.X.X.1    dns-nameservers 8.8.8.8 8.8.4.4    dns-search your.dns.info    dns-options rotate這里，我們將會在 eth0 塊下，添加新 IP 地址。
# Add support for our new IP addressesiface eth0:1 inet static      address Y.Y.Y.Y/24    dns-nameservers 8.8.8.8 8.8.4.4iface eth0:2 inet static      address Z.Z.Z.Z/24    dns-nameservers 8.8.8.8 8.8.4.4
如何獲得證書
盡管我在之前已經說的很詳細了，但是在這里我還是想再提一點。使用 Let's Encrypt,我們有幾種選擇來取得證書。
# First we need the Let's Encrypt binsudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt有了 Let's EncryptOnce 軟件包之后，我們可以用以下幾種方法注冊我們的域名。
# Get a cert for a domain (include all subdomains that apply to this file path, including www)/opt/letsencrypt/letsencrypt-auto certonly --webroot /  -d 'mysite.com,www.mysite.com' -w /var/www/mysite/public # Get a cert for a domain and subdomain with different filesystem paths /opt/letsencrypt/letsencrypt-auto certonly --webroot /  -d 'mysite.com,www.mysite.com' -w /var/www/mysite/public /  -d 'blog.mysite.com' -w /var/www/mysite_blog/ # Get a cert for an entirely new domain name/opt/letsencrypt/letsencrypt-auto certonly --webroot /  -d 'newsite.com,www.newsite.com' -w /var/www/newsite/public
更新 nginx 服務器
接下來，我們需要做一點 HTTPS 配置的修改，目的是使 nginx 從 域名+端口 認證方法切換到一種 ip+端口 的認證系統。這是在我們 HTTPS 服務器模塊中改變監聽（listen）指令最簡單的配置方式 (并且在我的使用中一直沒有問題) 。
server {      # Old method:    # listen          443 ssl;     # Ip-based:    listen          X.X.X.X:443 ssl;    server_name:    mysite.com www.mysite.com;    # ...}
自動續期證書
最后，當我們在服務器上維護多個站點時，我們真的應該依賴某種方法自動更新我們的 Let's Encrypt 證書。沒人愿意每三個月去手動更新一次。很幸運，Let's Encrypt 官方提供了一段代碼來處理這個問題 ，而我們只需要創建一個計劃任務，采用 cron 定時任務命令定期自動運行（這段代碼） 。現在，我們創建一個文件  /etc/letsencrypt/auto_renew.sh。把下面的代碼添加進來，你也可以自己做些修改，實現你想要的功能。
#!/bin/sh# This script renews all the Let's Encrypt certificates with a validity < 30 daysif ! /opt/letsencrypt/letsencrypt-auto renew > /var/log/letsencrypt/renew.log 2>&1 ; then      echo Automated renewal failed:    cat /var/log/letsencrypt/renew.log    exit 1fi  nginx -t && nginx -s reload現在將以上的腳本添加到計劃任務, 執行 sudo crontab -e 添加下面一行代碼:
@daily  /etc/letsencrypt/auto_renew.sh
隱私和安全問題
技術革新領域正在飛速發展，盡管這種發展在用戶的隱私和安全方面并無助益。雖然沒有明確言明，但是用戶變成客戶的過程在交互中已經隱含了雙方的信任。不管是作為開發人員、工程師還是系統管理員，我們都有責任保障用戶權益。保障用戶用 app 發出的任何連接都安全可靠是最佳方案。顯然，沒有一定程度上安全的連接難以輕松實現。Let's Encrypt 巧妙降低了進入開發領域的壁壘，成為開發人員亟需掌握的一步。由此可知，所有以避免為客戶網站提供安全支持為目的的借口都是疏忽和無知。希望本文對解決問題有所助益。總結：如果你對從一個服務器托管多個 HTTPS 域名一無所知，使用 Let's Encrypt 和 Nginx 吧！輕松解決問題。