CentOS 8 上給 Nginx或 Tengine裝 SSL 證書(shū)這事我前前后后做過(guò)不下幾十次從最早的裸配 443 端口到后來(lái)批量遷移站點(diǎn)、接入自動(dòng)續(xù)期每一步都踩過(guò)不少坑。最近又幫朋友處理了一臺(tái)CentOS 8服務(wù)器上的證書(shū)續(xù)期問(wèn)題索性把整套流程、配置思路和排查經(jīng)驗(yàn)整理成這篇實(shí)操記錄。這篇文章解決的是“拿到證書(shū)文件之后到底怎么放、怎么配、怎么驗(yàn)證、怎么續(xù)期”的問(wèn)題適合正在用 Nginx 或 Tengine 跑業(yè)務(wù)的運(yùn)維、站長(zhǎng)以及需要自己動(dòng)手部署 HTTPS 的后端開(kāi)發(fā)。很多人覺(jué)得裝證書(shū)就是填兩個(gè)文件路徑那么簡(jiǎn)單真上手就會(huì)發(fā)現(xiàn)證書(shū)鏈拼接、權(quán)限限制、跳轉(zhuǎn)配置、OCSP 裝訂、自動(dòng)續(xù)期這些環(huán)節(jié)每一個(gè)都能卡住你半小時(shí)。這篇文章我會(huì)按從設(shè)計(jì)到落地的順序把這幾個(gè)環(huán)節(jié)全部拆開(kāi)講透。1. 先想清楚證書(shū)選型與 Nginx/Tengine 方案拆解1.1 為什么非上 HTTPS 不可先說(shuō)點(diǎn)基礎(chǔ)的。SSL 證書(shū)這個(gè)名字其實(shí)有點(diǎn)誤導(dǎo)準(zhǔn)確說(shuō)它是一套公鑰基礎(chǔ)設(shè)施里的身份憑證。服務(wù)器持有私鑰對(duì)外公開(kāi)的是證書(shū)里的公鑰和身份信息?？蛻舳诉B上來(lái)時(shí)服務(wù)器把證書(shū)發(fā)給客戶端客戶端用內(nèi)置的 CA 根證書(shū)去驗(yàn)證這個(gè)證書(shū)是不是可信 CA 簽發(fā)的驗(yàn)證通過(guò)后雙方再通過(guò)密鑰協(xié)商生成會(huì)話密鑰后續(xù)所有數(shù)據(jù)都用對(duì)稱加密傳輸。這個(gè)過(guò)程解決了兩個(gè)核心問(wèn)題數(shù)據(jù)在傳輸途中不被竊聽(tīng)篡改以及客戶端確認(rèn)自己連的確實(shí)是目標(biāo)服務(wù)器而不是中間人。有人覺(jué)得自己的站沒(méi)有登錄功能、不涉及敏感數(shù)據(jù)就不用上 HTTPS。這個(gè)想法在現(xiàn)在的網(wǎng)絡(luò)環(huán)境下已經(jīng)行不通了。主流瀏覽器對(duì)純 HTTP 站點(diǎn)會(huì)直接打上“不安全”的標(biāo)記用戶看到這個(gè)標(biāo)識(shí)的跳出率非常高。另外 HTTP/2 和即將全面推廣的 HTTP/3 在主流瀏覽器里都要求 HTTPS 才能啟用不上證書(shū)你連現(xiàn)代協(xié)議的紅利都吃不到性能上就先輸一截。單純的 HTTP 數(shù)據(jù)就像明信片路上經(jīng)手的人都能看到內(nèi)容HTTPS 是上了鎖的快遞箱只有收件人手里的鑰匙能打開(kāi)箱子上的封條還能證明中途沒(méi)有被拆過(guò)。1.2 Nginx 和 Tengine 選哪個(gè)Nginx 和 Tengine 的關(guān)系可以理解成 Tengine 是 Nginx 的增強(qiáng)兼容分支配置語(yǔ)法、模塊體系、目錄結(jié)構(gòu)基本一致。Tengine 基于 Nginx 做了很多性能優(yōu)化和功能增強(qiáng)比如動(dòng)態(tài)模塊加載、更好的負(fù)載均衡算法但值得注意的是它從某個(gè)版本開(kāi)始基于 Nginx 1.24 分支演進(jìn)兩者在 SSL/TLS 相關(guān)配置指令上幾乎完全兼容。我的建議很簡(jiǎn)單如果你已經(jīng)在跑 Nginx 就沒(méi)必要為了“更好用”冒險(xiǎn)遷移到 Tengine如果新項(xiàng)目且團(tuán)隊(duì)對(duì) Tengine 有維護(hù)經(jīng)驗(yàn)用它也沒(méi)問(wèn)題。這篇文章里的所有配置在兩個(gè)環(huán)境里都可以直接照抄。從 HTTP 服務(wù)層面上說(shuō)證書(shū)配置的核心就三個(gè)要素證書(shū)文件放哪、私鑰文件放哪、443 端口怎么監(jiān)聽(tīng)。這個(gè)邏輯在 Nginx 和 Tengine 里毫無(wú)區(qū)別。真正需要注意的是底層 OpenSSL 版本差異它決定了你支持哪些 TLS 協(xié)議版本和加密套件。CentOS 8 系統(tǒng)自帶的 OpenSSL 1.1.1 已經(jīng)支持 TLS 1.3這意味著只要 Nginx 版本不是太老你不需要額外編譯就能開(kāi)啟 TLS 1.3這一點(diǎn)比 CentOS 7 時(shí)代省事不少。1.3 證書(shū)文件格式和構(gòu)成申請(qǐng)到的證書(shū)通常會(huì)有幾個(gè)文件服務(wù)器證書(shū)、中間證書(shū)、私鑰有的 CA 還會(huì)給你根證書(shū)。部署時(shí)需要把服務(wù)器證書(shū)和中間證書(shū)拼成一個(gè)完整鏈路文件這叫 fullchain私鑰單獨(dú)放。PEM 格式就是 base64 編碼的文本塊以-----BEGIN CERTIFICATE-----開(kāi)頭這是 Linux 環(huán)境下 Nginx 唯一需要關(guān)心的格式。如果從 Windows 平臺(tái)導(dǎo)出的是 PFX 格式需要先轉(zhuǎn)成 PEM 再部署。2. 動(dòng)手前準(zhǔn)備生成密鑰、申請(qǐng)證書(shū)與環(huán)境自查2.1 證書(shū)類型選哪種證書(shū)類型直接決定申請(qǐng)流程和成本。低防護(hù)級(jí)別的域名驗(yàn)證型證書(shū)只驗(yàn)證域名所有權(quán)申請(qǐng)流程最快幾分鐘就能簽發(fā)適合個(gè)人站點(diǎn)、測(cè)試環(huán)境、中小業(yè)務(wù)。高防護(hù)級(jí)別的企業(yè)驗(yàn)證型證書(shū)需要提交企業(yè)營(yíng)業(yè)執(zhí)照等材料CA 會(huì)人工審核簽發(fā)時(shí)間按天算適合電商、金融、政企類站點(diǎn)。還有更高級(jí)別的擴(kuò)展驗(yàn)證型證書(shū)瀏覽器地址欄會(huì)顯示企業(yè)名申請(qǐng)流程更嚴(yán)格。如果你的場(chǎng)景就是給公司官網(wǎng)、API 網(wǎng)關(guān)或內(nèi)部系統(tǒng)加 HTTPS低防護(hù)級(jí)別的免費(fèi)證書(shū)無(wú)論是安全性還是成本上都?jí)蛴昧恕＿@里重點(diǎn)推薦通過(guò) ACME 協(xié)議自動(dòng)簽發(fā)和續(xù)期的免費(fèi)證書(shū)。ACME 是自動(dòng)化證書(shū)管理協(xié)議客戶端程序向 CA 證明你對(duì)域名的控制權(quán)后CA 自動(dòng)簽發(fā)證書(shū)有效期通常為 90 天。它最大的價(jià)值在于全流程自動(dòng)化申請(qǐng)、驗(yàn)證、簽發(fā)、部署、續(xù)期一條龍徹底告別“證書(shū)過(guò)期導(dǎo)致站點(diǎn)掛掉”這種低級(jí)事故。商業(yè)證書(shū)的優(yōu)勢(shì)是有效期更長(zhǎng)、有企業(yè)身份背書(shū)、有技術(shù)支持但價(jià)格不菲且續(xù)期操作繁瑣。自簽名證書(shū)只適合內(nèi)網(wǎng)測(cè)試瀏覽器會(huì)報(bào)不受信任不要用在生產(chǎn)環(huán)境。2.2 用 OpenSSL 生成私鑰和 CSR申請(qǐng)證書(shū)之前需要自己生成私鑰和證書(shū)簽名請(qǐng)求。私鑰生成我建議用 RSA 2048 位起步保守一點(diǎn)可以上 3072 位。ECDSA 密鑰性能更好但兼容性要看你客戶端的廣泛程度生產(chǎn)環(huán)境我通常 RSA 和 ECDSA 雙證書(shū)配合。生成命令如下openssl genrsa -out example.com.key 2048 openssl req -new -key example.com.key -out example.com.csr \ -subj /CCN/STBeijing/LBeijing/OExample Inc/OUIT/CNexample.com這里有一個(gè)關(guān)鍵點(diǎn)現(xiàn)在 CA 普遍要求證書(shū)里必須帶 SAN也就是主題備用名稱純 CN 字段的證書(shū)已經(jīng)不被信任了。所以要么在 CSR 生成時(shí)加上 SAN 擴(kuò)展要么在 CA 的控制面板里重新填寫域名列表。多域名證書(shū)和泛域名證書(shū)在 CSR 階段就要聲明對(duì)應(yīng)域名。建議把example.com和www.example.com都寫上否則訪問(wèn)根域名時(shí)證書(shū)不匹配瀏覽器照樣報(bào)警。私鑰生成時(shí)不要設(shè)置密碼短語(yǔ)。如果設(shè)置了Nginx 每次啟動(dòng)或 reload 都需要人工輸入密碼雖然可以用ssl_password_file指令解決但多一個(gè)文件就多一份泄露風(fēng)險(xiǎn)純屬自找麻煩。私鑰的權(quán)限后面講這里先記住一條鐵律私鑰永遠(yuǎn)不要出現(xiàn)在命令行參數(shù)里不要上傳到任何第三方平臺(tái)不要提交到 Git 倉(cāng)庫(kù)。2.3 CentOS 8 環(huán)境檢查與依賴準(zhǔn)備動(dòng)手配置之前先把環(huán)境狀態(tài)摸清楚。CentOS 8 官方源已經(jīng)停止維護(hù)如果這臺(tái)機(jī)器還在用舊版系統(tǒng)跑生產(chǎn)你需要先確認(rèn) yum 源還能不能用、核心組件的安全補(bǔ)丁怎么解決。我建議至少把系統(tǒng)升級(jí)到兼容評(píng)估版本或者換用其他長(zhǎng)期維護(hù)的發(fā)行版這臺(tái)機(jī)器上的 Nginx 和 OpenSSL 版本直接決定后續(xù)配置方式。需要檢查的內(nèi)容按順序來(lái)cat /etc/redhat-release # 確認(rèn)系統(tǒng)版本 nginx -v # 確認(rèn) Nginx 版本建議 1.20 以上 openssl version # 確認(rèn) OpenSSL 版本1.1.1 以上才支持 TLS 1.3 sestatus # 確認(rèn) SELinux 狀態(tài)SELinux 這個(gè)問(wèn)題特別容易坑新手。CentOS 8 默認(rèn) SELinux 是 enforcing 模式如果 Nginx 嘗試讀取一個(gè)沒(méi)有正確上下文的私鑰文件會(huì)被 SELinux 直接拒絕表現(xiàn)就是nginx -t提示權(quán)限不足。解決辦法有兩個(gè)一是用restorecon -v /etc/nginx/ssl/example.com.key恢復(fù)正確上下文二是對(duì)自定義證書(shū)目錄執(zhí)行semanage fcontext -a -t httpd_config_t /etc/nginx/ssl(/.*)?然后restorecon -Rv /etc/nginx/ssl。我強(qiáng)烈建議用第二種方式直接把整個(gè)目錄的 SELinux 類型指定好以后新增證書(shū)文件只要執(zhí)行一次restorecon就完事。直接用setenforce 0關(guān)掉 SELinux 雖然省事但生產(chǎn)環(huán)境絕對(duì)不建議這么干屬于把門鎖拆了換安全感。3. 核心實(shí)操把 SSL 證書(shū)配置進(jìn) Nginx 并強(qiáng)制跳轉(zhuǎn) HTTPS3.1 證書(shū)文件放置與權(quán)限管理我習(xí)慣把所有站點(diǎn)的證書(shū)統(tǒng)一放在/etc/nginx/ssl/下面每個(gè)域名一個(gè)子目錄比如/etc/nginx/ssl/example.com/。目錄里面放fullchain.pem和example.com.key兩個(gè)文件。fullchain.pem 是服務(wù)器證書(shū)和中間證書(shū)拼接后的完整鏈路文件順序必須是服務(wù)器證書(shū)在最前中間證書(shū)在后順序反了客戶端校驗(yàn)鏈就會(huì)失敗。私鑰權(quán)限設(shè)置為 root 有讀寫權(quán)限其他人一律不可訪問(wèn)mkdir -p /etc/nginx/ssl/example.com mv fullchain.pem /etc/nginx/ssl/example.com/ mv example.com.key /etc/nginx/ssl/example.com/ chown -R root:root /etc/nginx/ssl chmod 600 /etc/nginx/ssl/example.com/example.com.key chmod 644 /etc/nginx/ssl/example.com/fullchain.pem很多人不理解為什么私鑰是 600 權(quán)限后 Nginx 還能讀。Nginx master 進(jìn)程是以 root 身份啟動(dòng)的只有 worker 進(jìn)程會(huì)降權(quán)到 nginx 用戶。讀取私鑰這個(gè)動(dòng)作發(fā)生在 master 進(jìn)程解析配置階段所以 root 能讀就夠了。如果你用非 root 方式啟動(dòng) Nginx比如通過(guò) systemd 指定了Usernginx那私鑰權(quán)限就得改成chown root:nginx且權(quán)限至少是 640否則 reload 的時(shí)候會(huì)報(bào)cannot load certificate key。3.2 寫一份能直接用的 443 配置核心配置塊長(zhǎng)這樣這是我目前在生產(chǎn)環(huán)境用的精簡(jiǎn)模板server { listen 443 ssl; http2 on; server_name example.com www.example.com; ssl_certificate /etc/nginx/ssl/example.com/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/example.com/example.com.key; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_stapling on; ssl_stapling_verify on; resolver 127.0.0.1 valid300s; location / { root /usr/share/nginx/html; index index.html; } }逐個(gè)說(shuō)參數(shù)含義。listen 443 ssl是監(jiān)聽(tīng) 443 端口并啟用 SSL 協(xié)議的舊式寫法新版本 Nginx 也支持。http2 on是 Nginx 1.25.1 之后推薦的寫法老版本是在listen后面直接加http2參數(shù)如果你用的版本較老改成listen 443 ssl http2;就行。ssl_certificate指向拼接好的完整鏈路文件ssl_certificate_key指向私鑰這兩個(gè)是所有配置的基石。ssl_session_cache設(shè)置會(huì)話緩存10m 大約能存 10 萬(wàn)個(gè)會(huì)話 ID對(duì)于中小流量站點(diǎn)完全夠用作用是讓相同客戶端復(fù)用會(huì)話密鑰減少重復(fù)握手開(kāi)銷。ssl_session_timeout 1d設(shè)置會(huì)話有效期一天。ssl_protocols直接關(guān)掉 TLS 1.0 和 1.1這兩個(gè)老版本協(xié)議已經(jīng)有嚴(yán)重已知漏洞現(xiàn)在沒(méi)有任何業(yè)務(wù)場(chǎng)景需要兼容它們。只保留 TLS 1.2 和 1.3覆蓋了目前所有主流瀏覽器和移動(dòng)設(shè)備。ssl_ciphers那一長(zhǎng)串是推薦的現(xiàn)代加密套件集合優(yōu)先使用 ECDHE 密鑰交換和 AEAD 對(duì)稱加密算法。這樣的配置在安全掃描里的評(píng)級(jí)通常是 A 或 A。ssl_prefer_server_ciphers on表示優(yōu)先使用服務(wù)端定義的加密套件而不是客戶端建議的這能防住一些老客戶端主動(dòng)降級(jí)到弱加密套件的行為。3.3 HTTP 全部跳轉(zhuǎn)到 HTTPS光配好 443 還不夠還要把 80 端口的所有訪問(wèn)請(qǐng)求指到 HTTPS 上。80 端口單獨(dú)開(kāi)一個(gè) server 塊做跳轉(zhuǎn)server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; }這里用$host而不是$server_name是有講究的。$host會(huì)取請(qǐng)求頭里的 Host 字段能保證用戶通過(guò) IP、泛域名或臨時(shí)域名訪問(wèn)時(shí)跳轉(zhuǎn)到對(duì)應(yīng)域名如果用$server_name就會(huì)固定跳轉(zhuǎn)到配置里的域名碰到用戶用 IP 訪問(wèn)的場(chǎng)景就白屏了。301 跳轉(zhuǎn)是永久跳轉(zhuǎn)瀏覽器會(huì)記住這個(gè)跳轉(zhuǎn)關(guān)系下次直接請(qǐng)求 HTTPS減少一次往返開(kāi)銷。網(wǎng)上一堆用 rewrite 實(shí)現(xiàn)跳轉(zhuǎn)的教程其實(shí)完全沒(méi)必要rewrite 會(huì)跑一遍正則性能上不如 return。如果你的站點(diǎn)想徹底杜絕 HTTPS 降級(jí)風(fēng)險(xiǎn)可以加上 HSTS 響應(yīng)頭add_header Strict-Transport-Security max-age31536000; includeSubDomains; preload always;但這里有個(gè)大坑HSTS 一旦下發(fā)瀏覽器會(huì)在設(shè)定的時(shí)長(zhǎng)內(nèi)強(qiáng)制走 HTTPS中途如果你想臨時(shí)關(guān)閉 HTTPS 排查問(wèn)題用戶那邊會(huì)直接訪問(wèn)失敗。所以生產(chǎn)環(huán)境務(wù)必在 HTTPS 穩(wěn)定運(yùn)行一段時(shí)間后再加 HSTS并且先用max-age86400短時(shí)長(zhǎng)驗(yàn)證確認(rèn)沒(méi)問(wèn)題再改成一年。3.4 驗(yàn)證配置并平滑重載每次改完配置都要先測(cè)試再重載nginx -t systemctl reload nginxnginx -t會(huì)解析配置文件并檢查證書(shū)文件是否能正常讀取如果這里報(bào)錯(cuò)根據(jù)報(bào)錯(cuò)信息修改。配置文件合法后執(zhí)行systemctl reload這個(gè)動(dòng)作是平滑重載已有的連接不會(huì)中斷新連接會(huì)走新配置。注意生產(chǎn)環(huán)境千萬(wàn)不要用systemctl restart nginx重啟會(huì)瞬間斷開(kāi)所有活躍連接如果站點(diǎn)正在跑長(zhǎng)連接或正在上傳下載大文件用戶端會(huì)直接被切斷。重載后用 OpenSSL 自帶的客戶端工具做一次握手驗(yàn)證openssl s_client -connect example.com:443 -servername example.com \ -showcerts /dev/null重點(diǎn)看輸出里subject是不是你的域名、issuer是不是簽發(fā)證書(shū)的 CA、verify return code是不是 0并且鏈條顯示0 s:到根證書(shū)每一環(huán)都完整。再配合curl -vI https://example.com檢查 HTTP 響應(yīng)頭確認(rèn)返回 200 而不是證書(shū)錯(cuò)誤。4. 證書(shū)續(xù)期與自動(dòng)化別再等瀏覽器彈警告才更新4.1 手動(dòng)續(xù)期的完整流程無(wú)論免費(fèi)證書(shū)還是商業(yè)證書(shū)都有有效期。商業(yè)證書(shū)通常是一年ACME 簽發(fā)的是 90 天。手工續(xù)期的流程和第一次申請(qǐng)基本一樣重新生成 CSR私鑰可以復(fù)用提交給 CA通過(guò)驗(yàn)證后下載新證書(shū)替換服務(wù)器上的 fullchain.pem然后 reload。整個(gè)過(guò)程最耗時(shí)的是 CA 的驗(yàn)證環(huán)節(jié)。ACME 協(xié)議通常用兩種驗(yàn)證方式。HTTP 方式要求 CA 能訪問(wèn)到http://example.com/.well-known/acme-challenge/token這個(gè) URLChallenge 文件需要放在站點(diǎn)根目錄下。如果你用的是類似/usr/share/nginx/html的默認(rèn)目錄記得確認(rèn)這個(gè)路徑下能正常寫入文件并且 Nginx 不會(huì)因?yàn)?location 規(guī)則攔截.well-known路徑。DNS 方式要求你在域名的 DNS 解析服務(wù)商那里臨時(shí)添加一條 TXT 記錄這種方式適合域名沒(méi)有對(duì)外開(kāi)放 80 端口、或者正在遷移服務(wù)器的場(chǎng)景。4.2 ACME 自動(dòng)化續(xù)期部署思路如果你用 ACME 客戶端自動(dòng)管理證書(shū)建議把私鑰和證書(shū)統(tǒng)一放到/etc/nginx/ssl/域名/目錄客戶端的部署鉤子腳本在續(xù)期成功后自動(dòng)把新證書(shū)拷貝過(guò)去、執(zhí)行nginx -t并觸發(fā) reload。部署鉤子的偽代碼大致是這樣的#!/bin/bash DOMAINexample.com DEPLOY_DIR/etc/nginx/ssl/$DOMAIN cp $CERT_PATH $DEPLOY_DIR/fullchain.pem cp $KEY_PATH $DEPLOY_DIR/example.com.key chown root:root $DEPLOY_DIR/* chmod 600 $DEPLOY_DIR/example.com.key restorecon -Rv $DEPLOY_DIR 2/dev/null || true nginx -t systemctl reload nginx這里最關(guān)鍵的一步是nginx -t放前面只有配置合法才執(zhí)行 reload。我見(jiàn)過(guò)有人寫的鉤子直接systemctl reload nginx結(jié)果某次續(xù)期拿到的新證書(shū)和配置不匹配Nginx 直接加載失敗整站瞬間掛掉。這種事故完全可以通過(guò)前置校驗(yàn)來(lái)避免。自動(dòng)化任務(wù)建議用系統(tǒng)自帶的定時(shí)器每天跑一次檢查。ACME 客戶端本身會(huì)判斷證書(shū)剩余有效期一般剩余不足 30 天才會(huì)真正續(xù)期所以每日任務(wù)開(kāi)銷很小。4.3 多域名和泛域名證書(shū)管理如果你的站有多個(gè)子域名建議申請(qǐng)一張多域名證書(shū)把域名全部列進(jìn)去。子域名多到一定規(guī)模一張泛域名證書(shū)覆蓋*.example.com更省事。泛域名證書(shū)只能通過(guò) DNS 方式驗(yàn)證因?yàn)?CA 要為所有子域名做驗(yàn)證HTTP 方式不可能逐一處理。管理的目錄結(jié)構(gòu)我建議按域名拆/etc/nginx/ssl/ ├── example.com/ │ ├── fullchain.pem │ └── example.com.key ├── api.example.com/ │ ├── fullchain.pem │ └── api.example.com.key └── *.example.com/ ├── fullchain.pem └── wildcard.example.com.key這樣每個(gè) server 塊引用的路徑一目了然排錯(cuò)時(shí)不用猜。多域名證書(shū)續(xù)期只需要跑一次 ACME 流程但泛域名和單域名證書(shū)要分開(kāi)跑別寫進(jìn)同一個(gè)任務(wù)里。5. 排坑實(shí)錄證書(shū)鏈、混合內(nèi)容、OCSP 裝訂一次說(shuō)清5.1 證書(shū)鏈不完整引發(fā)的信任告警癥狀是瀏覽器地址欄出現(xiàn)鎖異常用curl返回證書(shū)鏈驗(yàn)證失敗但純用openssl s_client又看起來(lái)正常。經(jīng)典原因是你只把服務(wù)器證書(shū)填進(jìn)了ssl_certificate少了中間證書(shū)。CA 簽發(fā)的證書(shū)鏈里服務(wù)器證書(shū)是葉子它需要被中間 CA 簽名中間 CA 又被根 CA 簽名。客戶端只信任內(nèi)置的根證書(shū)如果服務(wù)端不發(fā)中間證書(shū)客戶端就沒(méi)法構(gòu)建出完整的信任鏈。解決辦法是把中間證書(shū)內(nèi)容追加到服務(wù)器證書(shū)后面也就是 fullchain 拼接。文件里有兩個(gè)BEGIN CERTIFICATE塊第一個(gè)是服務(wù)器證書(shū)第二個(gè)是中間證書(shū)。如果拼接反了有的客戶端會(huì)報(bào)錯(cuò)有的能自動(dòng)修正但增加驗(yàn)證開(kāi)銷。拼接完用這條命令檢查鏈條順序openssl crl2pkcs7 -nocrl -certfile fullchain.pem | openssl pkcs7 -print_certs -noout輸出結(jié)果里第一條應(yīng)該是你的域名證書(shū)第二條是中間證書(shū)。順序不對(duì)就調(diào)整后重新nginx -t systemctl reload nginx。證書(shū)鏈問(wèn)題在校驗(yàn)命令里其實(shí)一眼就能看出來(lái)只要verify return code不是 0基本就是鏈路拼接的問(wèn)題。5.2 混合內(nèi)容被瀏覽器攔截證書(shū)配好、HTTPS 正常訪問(wèn)之后經(jīng)常遇到頁(yè)面排版錯(cuò)亂、圖片不顯示、接口加載失敗的情況。打開(kāi)瀏覽器開(kāi)發(fā)者工具的 Console 面板會(huì)看到大量類似“Mixed Content”的報(bào)錯(cuò)。原因很簡(jiǎn)單頁(yè)面主體已經(jīng)走 HTTPS但頁(yè)面里引用的 JS、CSS、圖片、接口請(qǐng)求還是 HTTP 地址。瀏覽器出于安全策略會(huì)直接阻止這些不安全子資源的加載。排查思路分三步。第一在源碼層面把資源引用改成相對(duì)路徑比如//example.com/js/app.js這種方式會(huì)自動(dòng)跟隨當(dāng)前頁(yè)面的協(xié)議。第二檢查后端接口返回的 URL 是不是寫死了 HTTP這段邏輯要全局搜。第三如果有反向代理確認(rèn)代理轉(zhuǎn)發(fā)時(shí)正確處理了X-Forwarded-Proto頭否則后端程序在生成頁(yè)面鏈接時(shí)仍然以為是 HTTP 請(qǐng)求。5.3 OCSP 裝訂配置的意外狀況OCSP 裝訂是 Nginx 的一個(gè)性能和安全優(yōu)化特性。它的作用是讓服務(wù)器主動(dòng)從 CA 的 OCSP 服務(wù)器查詢證書(shū)吊銷狀態(tài)把結(jié)果緩存并隨證書(shū)一起發(fā)給客戶端省去客戶端自己反向連接 CA 查詢的等待時(shí)間。配置我已經(jīng)在模板里寫了但這里要說(shuō)一個(gè)容易踩的坑Nginx 在開(kāi)啟ssl_stapling on后需要配置resolver指令指定 DNS 解析服務(wù)器否則 Nginx 無(wú)法解析 OCSP 服務(wù)器地址功能等于沒(méi)開(kāi)。更麻煩的是如果 CA 的 OCSP 服務(wù)器訪問(wèn)不穩(wěn)定Nginx 可能整個(gè)站點(diǎn)都拒絕服務(wù)。我的建議是生產(chǎn)環(huán)境先ssl_stapling_verify on配合日志觀察一段確認(rèn)沒(méi)有報(bào)錯(cuò)后再長(zhǎng)期開(kāi)著。另外部分 CDN 和云負(fù)載均衡器本身就帶 OCSP 裝訂能力做了多層架構(gòu)時(shí)不需要每層都開(kāi)啟反而容易出連鎖故障。5.4 高頻問(wèn)題速查表癥狀檢查命令常見(jiàn)原因解決要點(diǎn)nginx -t報(bào)權(quán)限不足ls -l /etc/nginx/ssl/*.key私鑰權(quán)限過(guò)寬或?qū)僦鞑粚?duì)SELinux 上下文錯(cuò)誤chmod 600chown root:rootrestorecon瀏覽器提示“不安全”或證書(shū)已過(guò)期openssl s_client -connect 域名:443 -servername 域名證書(shū)到期、證書(shū)鏈不完整、域名不匹配檢查證書(shū)有效期和 subject拼接 fullchainHTTP 能訪問(wèn)HTTPS 一直轉(zhuǎn)圈curl -vI https://域名443 端口沒(méi)監(jiān)聽(tīng)、防火墻攔截確認(rèn)ss -lntp里 443 已監(jiān)聽(tīng)firewall-cmd 放行頁(yè)面布局亂了但證書(shū)正常瀏覽器控制臺(tái)看 Mixed Content頁(yè)面有 HTTP 子資源資源改成相對(duì)協(xié)議或 HTTPS移動(dòng)端訪問(wèn)證書(shū)報(bào)錯(cuò)但電腦正常openssl s_client看 chain 數(shù)量缺少中間證書(shū)部分移動(dòng)端不自動(dòng)補(bǔ)鏈拼接完整證書(shū)鏈TLS 版本顯示 1.0nginx -V看 TLS 支持Nginx 太老或配置沒(méi)生效升級(jí) Nginx確認(rèn)ssl_protocols TLSv1.2 TLSv1.3reload 后老連接斷開(kāi)systemctl status nginx誤用 restart 替代 reload以后統(tǒng)一用systemctl reload nginx我做批量 HTTPS 遷移時(shí)交過(guò)一次學(xué)費(fèi)當(dāng)時(shí)圖快直接在服務(wù)器上用腳本批量替換證書(shū)文件結(jié)果有幾臺(tái)機(jī)器證書(shū)鏈拼接順序搞錯(cuò)了偏偏瀏覽器本地緩存了舊的驗(yàn)證結(jié)果很多用戶直到第二天才發(fā)現(xiàn)問(wèn)題。后來(lái)我立了一條規(guī)矩任何證書(shū)變更必須在測(cè)試環(huán)境走完nginx -t加openssl s_client的完整驗(yàn)證鏈確認(rèn)足夠安全后再推到生產(chǎn)絕不跨過(guò)驗(yàn)證直接上。這個(gè)方法雖然慢一點(diǎn)但風(fēng)險(xiǎn)屏障厚很多也推薦你照此執(zhí)行。最后再分享一個(gè)小技巧證書(shū)文件目錄里保留上一次的 fullchain 副本命名帶日期后綴比如fullchain.pem.20250101.bak。證書(shū)更新后如果出現(xiàn)異?？梢栽趲酌雰?nèi)回滾到舊版本。這個(gè)習(xí)慣救過(guò)我兩次成本幾乎為零但價(jià)值極高。