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