我凌晨一點(diǎn)多在群里看到一條消息某公司一個(gè)小程序后臺(tái)接口集體報(bào)錯(cuò)用戶端頁面全打不開。值班的人第一反應(yīng)是服務(wù)器掛了結(jié)果端口通、進(jìn)程在、日志干干凈凈最后用一條命令定位了問題——證書已經(jīng)過期兩天了。這種事故我這些年見過太多次而且絕大多數(shù)和“技術(shù)不會(huì)修”沒關(guān)系就是單純忘了SSL證書有有效期。今天借這個(gè)標(biāo)題把證書更新的完整鏈路、原理、格式坑和自動(dòng)續(xù)期方案一次講清楚也當(dāng)給自己留一份備忘。1. 一張過期的證書到底能坑多少人1.1 客戶端報(bào)錯(cuò)里其實(shí)寫著答案證書過期這件事最直觀的表現(xiàn)是瀏覽器或者客戶端直接拒連。拿Chrome舉例地址欄不會(huì)變成紅色而是直接給你一整頁錯(cuò)誤提示錯(cuò)誤碼是NET::ERR_CERT_DATE_INVALID。很多人一看“DATE”就懵了以為服務(wù)器時(shí)間不對(duì)其實(shí)這個(gè)報(bào)錯(cuò)的意思是“證書的有效期已經(jīng)過了”。在命令行里測(cè)試更直接。用 curl 訪問一個(gè)證書過期的站點(diǎn)結(jié)果大概長(zhǎng)這樣$ curl -vI https://expired.example.com ... * SSL certificate problem: certificate has expired * closing connection 0 curl: (60) SSL certificate problem: certificate has expired注意這個(gè)退出碼 60它是 curl 對(duì)“證書驗(yàn)證失敗”的統(tǒng)一返回碼。再用 openssl 手工做一次 TLS 握手輸出里會(huì)有一行Verify return code: 10 (certificate has expired)這個(gè) return code 10 就是證書過期的標(biāo)準(zhǔn)標(biāo)記。所以判斷證書是不是過期不需要等瀏覽器渲染頁面openssl 一次握手就能得到明確結(jié)論。1.2 影響范圍遠(yuǎn)比你想的廣網(wǎng)頁打不開只是最小的影響面。真正麻煩的是那些“沒有瀏覽器界面”的東西手機(jī) App 內(nèi)置的接口、小程序服務(wù)端、企業(yè)內(nèi)網(wǎng)的老系統(tǒng)、CI/CD 部署腳本、IoT 設(shè)備上報(bào)鏈路、VSFTPD 這類 FTP over TLS 服務(wù)、還有各種自研客戶端。它們內(nèi)部用的 TLS 庫驗(yàn)證方式更嚴(yán)格證書一過期直接拋異常而且很多客戶端異常信息寫得很含糊比如“handshake failed”“connection reset”“SSL error”根本不會(huì)告訴你“證書過期了”。我甚至見過因?yàn)橐粡堊C書過期整個(gè)公司的自動(dòng)化報(bào)表鏈路停了兩天的情況。報(bào)表腳本每天凌晨跑一次某天開始全部失敗運(yùn)維查了數(shù)據(jù)庫、查了網(wǎng)絡(luò)、查了權(quán)限最后才發(fā)現(xiàn)是調(diào)用外部接口的 HTTPS 證書過期了。這種場(chǎng)景最要命的地方在于服務(wù)端看起來一切正常日志也沒有明顯報(bào)錯(cuò)你根本不會(huì)第一時(shí)間往證書方向去想。1.3 別把排查方向帶偏證書相關(guān)報(bào)錯(cuò)還有幾個(gè)容易混淆的變體排查時(shí)需要區(qū)分清楚現(xiàn)象可能原因?yàn)g覽器提示“證書過期”證書真的過期或本地系統(tǒng)時(shí)間超前瀏覽器提示“證書尚未生效”服務(wù)器時(shí)間比真實(shí)時(shí)間慢或本地時(shí)間落后curl 報(bào)證書驗(yàn)證失敗但日期看著正常中間證書沒配全證書鏈不完整個(gè)別老設(shè)備/老客戶端打不開證書簽名算法或 TLS 版本不兼容服務(wù)器時(shí)間飄了openssl 校驗(yàn)不過NTP 沒配好系統(tǒng)時(shí)鐘偏差超過有效期邊界這里最有迷惑性的就是時(shí)間同步。如果你的服務(wù)器時(shí)間比真實(shí)時(shí)間慢了幾天而證書恰好還剩兩三天才到期客戶端會(huì)認(rèn)為證書“尚未生效”valid from 還沒到同樣報(bào)出 DATE 相關(guān)錯(cuò)誤。我曾經(jīng)排過一個(gè)故障最后發(fā)現(xiàn)是服務(wù)器 CMOS 電池沒電每次重啟時(shí)間都回退證書永遠(yuǎn)“還沒到生效時(shí)間”。所以排查證書問題時(shí)第一件事除了看證書日期還要順手看一眼服務(wù)器系統(tǒng)時(shí)間和 NTP 同步狀態(tài)。2. 讀懂有效期機(jī)制才知道為什么現(xiàn)在“更新頻繁”2.1 證書里到底存了什么很多人以為 SSL 證書就是個(gè)“證明我網(wǎng)站安全的文件”這理解有點(diǎn)偏差。實(shí)際上一張 X.509 證書里存的是一組結(jié)構(gòu)化信息綁定的域名、公鑰、簽發(fā)機(jī)構(gòu)CA、有效期起止時(shí)間以及 CA 對(duì)整段內(nèi)容做的數(shù)字簽名。瀏覽器或客戶端在驗(yàn)證證書時(shí)做的事可以簡(jiǎn)化成兩步第一步用 CA 的公鑰驗(yàn)證證書上的數(shù)字簽名是否有效確認(rèn)這張證書確實(shí)是那個(gè) CA 簽發(fā)的第二步把系統(tǒng)當(dāng)前時(shí)間和證書里的 notBefore、notAfter 兩個(gè)時(shí)間戳做比較確認(rèn)當(dāng)前時(shí)間落在有效期內(nèi)。兩步都通過才算建立信任。所以證書的有效期不是“一個(gè)建議”而是信任驗(yàn)證的一個(gè)硬性輸入。你把一張 2023 年過期的證書放到 2025 年無論簽名多完美、CA 多權(quán)威客戶端都會(huì)直接拒掉。這有點(diǎn)像小區(qū)門禁卡卡是真的門禁系統(tǒng)也認(rèn)這個(gè)發(fā)卡機(jī)構(gòu)但卡本身的授權(quán)期限過了刷上去就是進(jìn)不了門。2.2 有效期為什么越縮越短前些年 SSL 證書有效期還很長(zhǎng)三年、五年都不稀奇。后來整個(gè) CA/B 論壇CA/Browser Forum全球 CA 機(jī)構(gòu)和瀏覽器廠商的聯(lián)合組織一直在收縮有效期上限我記得比較清楚的時(shí)間線早期證書最長(zhǎng)可達(dá) 8 年甚至更長(zhǎng)后來縮減到 5 年2018 年前后縮到 825 天約 27 個(gè)月2020 年 9 月之后簽發(fā)的證書有效期上限是 398 天約 13 個(gè)月?，F(xiàn)在 Chrome、Apple 等還在推動(dòng)把 TLS 證書有效期進(jìn)一步壓到 90 天。背后的邏輯不復(fù)雜證書有效期內(nèi)綁定的私鑰一直在生產(chǎn)環(huán)境里跑暴露時(shí)間越長(zhǎng)被泄露、被暴力破解的風(fēng)險(xiǎn)窗口越大。萬一某個(gè) CA 被攻破或者私鑰丟失、算法被證明不安全比如當(dāng)年的 SHA-1、1024 位 RSA有效期越短能自動(dòng)淘汰舊問題證書的速度就越快。2.3 免費(fèi)證書為什么大多是 90 天現(xiàn)在大家常用的免費(fèi)證書像 Lets Encrypt、阿里云免費(fèi)版、騰訊云免費(fèi)版有效期基本都是 90 天上下。Lets Encrypt 從第一天起就是 90 天目的很簡(jiǎn)單用短期證書倒逼自動(dòng)化。因?yàn)橹挥凶C書足夠短你才必須建立自動(dòng)續(xù)期機(jī)制而自動(dòng)化簽發(fā)、自動(dòng)化部署本身就是提升安全水平的路徑。國(guó)內(nèi)云廠商的免費(fèi)證書策略也跟隨這個(gè)方向阿里云的免費(fèi)版 SSL 證書目前也是 3 個(gè)月有效期到期后在控制臺(tái)重新申請(qǐng)并部署。90 天意味著什么意味著如果你純靠記憶力去續(xù)期一年至少要記得四次而且每次都要留出操作余量。這不是“盡量別忘”的問題而是“必須建立機(jī)制”的問題。后面我詳細(xì)講怎么把這件事自動(dòng)化先把各種證書格式和常規(guī)申請(qǐng)流程理清楚。3. 免費(fèi)證書的申請(qǐng)、續(xù)期與自動(dòng)化部署3.1 阿里云免費(fèi)證書續(xù)期其實(shí)是重新簽發(fā)一張阿里云 SSL 證書的免費(fèi)續(xù)期實(shí)操過的朋友應(yīng)該都知道控制臺(tái)里點(diǎn)“續(xù)期”本質(zhì)上不是把舊證書的有效期延長(zhǎng)而是重新簽發(fā)一張新證書然后你手動(dòng)下載、替換到服務(wù)器上。具體流程大概是登錄阿里云控制臺(tái)搜索“數(shù)字證書管理服務(wù)”也叫 SSL 證書找到你之前申請(qǐng)的免費(fèi)證書如果臨近到期控制臺(tái)會(huì)有提醒也有“續(xù)期”入口提交續(xù)期申請(qǐng)后需要做域名驗(yàn)證驗(yàn)證方式一般是 DNS 解析驗(yàn)證或者文件驗(yàn)證驗(yàn)證通過后等證書簽發(fā)免費(fèi)證書一般幾分鐘到幾小時(shí)在證書列表里下載注意選擇服務(wù)器類型Nginx 下下來的是 PEM 格式證書和私鑰文件Tomcat 下下來的是 PFX 或 JKSIIS 下的是 PFX把新證書替換到服務(wù)器對(duì)應(yīng)目錄重啟或 reload Web 服務(wù)驗(yàn)證生效。這里有幾個(gè)我自己趟過的坑別在快過期時(shí)才去申請(qǐng)。免費(fèi)證書的驗(yàn)證流程雖然不復(fù)雜但如果用的是文件驗(yàn)證你得能往網(wǎng)站根目錄寫文件DNS 驗(yàn)證則需要你有域名解析控制權(quán)。遇到節(jié)假日、域名不在自己手里、DNS 服務(wù)商反應(yīng)慢都可能卡住。提前兩周提交是最低要求。替換證書后一定要 reload 服務(wù)。Nginx 是nginx -t nginx -s reloadTomcat 是重啟或 reload connector。有人替換了文件但忘記 reload頁面仍然加載舊證書檢查半天以為是沒替換成功。下載時(shí)選對(duì)類型。同一張證書在不同服務(wù)器類型下打包格式完全不同最穩(wěn)妥的做法是下載 Nginx 版PEM KEY然后再按自己需要轉(zhuǎn)成 PFX 或 JKS。關(guān)于格式轉(zhuǎn)換下一節(jié)專門展開講。3.2 用 certbot 讓自建服務(wù)器實(shí)現(xiàn)自動(dòng)續(xù)期如果是自己管理的服務(wù)器和域名我強(qiáng)烈建議直接上 Lets Encrypt certbot把 90 天續(xù)期做成全自動(dòng)。這套方案適合大多數(shù)自建 Nginx、Apache 之類的場(chǎng)景而且完全免費(fèi)。安裝 certbot 之后假設(shè)你的 Nginx 配置已經(jīng)指向了域名example.com第一次簽發(fā)可以這樣# 用 nginx 插件自動(dòng)簽發(fā)并修改 nginx 配置 $ sudo certbot --nginx -d example.com -d www.example.com # 或者用 webroot 模式不改 nginx 配置只負(fù)責(zé)簽發(fā) $ sudo certbot certonly --webroot -w /var/www/html -d example.com簽發(fā)成功后證書文件在/etc/letsencrypt/live/example.com/目錄下。Nginx 配置里指向它server { listen 443 ssl; server_name example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; }自動(dòng)續(xù)期的關(guān)鍵在于 cron 或 systemd timer。我習(xí)慣用 cron簡(jiǎn)單直接# 每天凌晨3點(diǎn)檢查一次到期前30天內(nèi)才續(xù)續(xù)完自動(dòng) reload nginx 0 3 * * * /usr/bin/certbot renew --quiet --deploy-hook /bin/systemctl reload nginxcertbot renew本身是冪等的沒到續(xù)期時(shí)間它不會(huì)做任何操作天天跑也沒壓力。--deploy-hook里的systemctl reload nginx是續(xù)期成功后重新加載證書的關(guān)鍵沒有這一步Nginx 還會(huì)繼續(xù)用內(nèi)存里的舊證書。配置完之后先手動(dòng)驗(yàn)證一遍$ sudo certbot renew --dry-run看到Congratulations, all simulated renewals succeeded就代表自動(dòng)化鏈路通了。3.3 續(xù)期時(shí)最容易漏掉的證書鏈拼接無論是阿里云免費(fèi)證書還是 Lets Encrypt證書文件通常不是一個(gè)而是一組葉證書你的域名證書、中間證書Intermediate CA、可能還有根證書。Nginx 配置里的ssl_certificate必須指向一個(gè)包含完整證書鏈的文件一般叫fullchain.pem。只知道填第一個(gè)證書文件、沒鏈中間證書的配置瀏覽器端會(huì)報(bào)ERR_CERT_COMMON_NAME_INVALID或者unable to get local issuer certificate在 curl 和 openssl 里則表現(xiàn)為 verify error。所以用 Lets Encrypt 就直接填fullchain.pem別去填cert.pem用阿里云下載的 Nginx 包解壓后會(huì)有full_chain.pem和privkey.pem兩個(gè)文件對(duì)應(yīng)填到ssl_certificate和ssl_certificate_key用在線檢測(cè)工具比如 SSL Labs后面會(huì)提到可以非常直觀地看到證書鏈?zhǔn)欠裢暾?. cer、pem、pfx 這些格式別被繞暈一次講清轉(zhuǎn)換與部署4.1 這些格式到底誰是誰做證書部署繞不開格式轉(zhuǎn)換。很多人第一次看到.cer、.crt、.pem、.pfx、.jks直接被繞暈其實(shí)它們之間的關(guān)系沒那么復(fù)雜。擴(kuò)展名本質(zhì)通常包含內(nèi)容常見場(chǎng)景.cer / .crt證書編碼可能是 DER 或 PEM只有證書沒有私鑰Windows、各類平臺(tái)下載.pemBase64 文本內(nèi)容可以多樣證書、私鑰、證書鏈都可能Nginx、Apache、多數(shù) Linux 服務(wù).key私鑰文件編碼可能是 PEM 或 DER只有私鑰各類服務(wù)端配置.pfx / .p12PKCS#12 打包容器證書 私鑰可能帶中間證書IIS、Tomcat、Windows 導(dǎo)入.jksJava KeyStore證書 私鑰Java 專有格式老版本 Tomcat、Java 應(yīng)用最關(guān)鍵的認(rèn)知是PEM 其實(shí)是“文本編碼方式”PFX 是“打包容器”JKS 是“Java 專用倉庫”。同一份證書材料可以在這幾種形態(tài)之間來回轉(zhuǎn)換理論上不丟信息實(shí)際操作里大多數(shù)人卡在命令記不住和編碼格式識(shí)別上。4.2 只有cer沒有私鑰轉(zhuǎn)不出能用的pfx很多人在 Tomcat 部署時(shí)拿到一個(gè).cer文件然后嘗試轉(zhuǎn)換成.pfx結(jié)果各種報(bào)錯(cuò)。這里有一個(gè)必須說清楚的規(guī)則只有證書cer沒有配套私鑰key永遠(yuǎn)轉(zhuǎn)不出能用于服務(wù)器部署的 pfx。因?yàn)?pfx 里的核心是私鑰公鑰證書本身是公開的誰都可以下載。服務(wù)器端做 TLS 握手必須持有私鑰只有證書沒有私鑰等于只有指紋沒有本人。所以從平臺(tái)下載證書時(shí)除非平臺(tái)明確給了私鑰文件否則那個(gè) cer 只能用于“查看證書信息”或“導(dǎo)出給別人驗(yàn)證”不能用于服務(wù)器部署。正常轉(zhuǎn)換的前提是你手里同時(shí)有證書文件和私鑰文件。比如你在阿里云下載證書時(shí)選了 Nginx 類型拿到full_chain.pem和privkey.pem這時(shí)想轉(zhuǎn)成 Tomcat 用的 pfx命令如下# 先確認(rèn)證書和私鑰是 PEM 編碼文本文件第一行是 BEGIN CERTIFICATE / BEGIN PRIVATE KEY $ file cert.pem key.pem # 轉(zhuǎn)換成 pfx過程中需要設(shè)置導(dǎo)出密碼后面配置 Tomcat 要填 $ openssl pkcs12 -export \ -out server.pfx \ -inkey privkey.pem \ -in full_chain.pem \ -name tomcat如果你拿到的 cer 是 DER 二進(jìn)制編碼瀏覽器或 Windows 可以直接打開但 openssl 處理前需要先轉(zhuǎn)成 PEM# DER - PEM $ openssl x509 -inform DER -in cert.cer -out cert.pem轉(zhuǎn)換完成后可以用這條命令檢查 pfx 里的內(nèi)容確認(rèn)證書和私鑰是否齊全、匹配$ openssl pkcs12 -in server.pfx -info -noout這里會(huì)提示輸入密碼輸入后能看到bag attributes、subject、issuer等信息。重點(diǎn)確認(rèn)里面有friendlyName: tomcat對(duì)應(yīng)的私鑰條目同時(shí)證書的域名和你要部署的域名一致。4.3 Tomcat 裝載 PFX 的配置與驗(yàn)證拿到 server.pfx 之后把它放到 Tomcat 的配置目錄比如${CATALINA_HOME}/conf/下然后修改conf/server.xml。對(duì)于 Tomcat 8.5 以上的版本推薦直接使用 Java 標(biāo)準(zhǔn) SSL 連接器配置如下Connector port8443 protocolHTTP/1.1 SSLEnabledtrue maxThreads150 schemehttps securetrue keystoreFileconf/server.pfx keystorePass你的密碼 keystoreTypePKCS12 clientAuthfalse sslProtocolTLS /關(guān)鍵屬性就三個(gè)keystoreFile指向 pfx 文件路徑keystorePass填轉(zhuǎn)換時(shí)設(shè)置的密碼keystoreType必須寫PKCS12。如果這兩個(gè)地方錯(cuò)了最常見的報(bào)錯(cuò)是java.io.IOException: keystore password was incorrect java.security.KeyStoreException: Unrecognized Java KeyStore format前者是密碼不對(duì)后者通常是文件類型和keystoreType不匹配。修改完成后重啟 Tomcat然后用 curl 或 openssl 驗(yàn)證# 檢查8443端口 HTTPS 握手是否能拿到證書 $ echo | openssl s_client -connect localhost:8443 -servername example.com 2/dev/null | openssl x509 -noout -subject -dates能看到subjectCN example.com并且notAfter日期還是未來就說明 pfx 部署成功了。5. vsftpd 配置 SSL 證書的隱藏要求與翻車現(xiàn)場(chǎng)5.1 vsftpd 需要什么樣的證書文件VSFTPD 是老牌 FTP 服務(wù)器了很多人還用它做文件傳輸配合 TLS 加密后就是 FTPS。它加載證書用的是 OpenSSL 庫所以只要 PEM 格式的文件就能用不需要 pfx也不需要 jks。但有幾個(gè)隱藏要求網(wǎng)上很多教程沒說清楚證書和私鑰可以分開兩個(gè)文件分別用rsa_cert_file和rsa_private_key_file指定也可以把證書和私鑰拼在同一個(gè) PEM 文件里兩個(gè)配置項(xiàng)指向同一個(gè)文件私鑰文件權(quán)限必須嚴(yán)格控制。VSFTPD 是 root 啟動(dòng)、后續(xù)降權(quán)運(yùn)行但它讀私鑰是在啟動(dòng)階段用 root 讀的所以私鑰權(quán)限設(shè)成600、屬主 root 最穩(wěn)妥。我見過有人把私鑰權(quán)限改成644后 VSFTPD 直接拒絕加載OpenSSL 層面對(duì)私鑰文件權(quán)限有安全檢查過不了就會(huì)報(bào)錯(cuò)。證書過期后VSFTPD 還能正常啟動(dòng)但所有要求 TLS 的客戶端會(huì)在握手階段失敗日志里出現(xiàn)一行類似SSL_accept: 14094415 ...或者certificate has expired的錯(cuò)誤。這種故障隱蔽性很強(qiáng)因?yàn)?FTP 服務(wù)本身是“通”的普通連接也能建立但一啟用隱式 TLS 或者顯式 TLS 就廢。5.2 一份可以照抄的 vsftpd.conf SSL 配置我整理一份當(dāng)前環(huán)境下比較穩(wěn)妥的 VSFTPD SSL 配置ssl_enableYES rsa_cert_file/etc/vsftpd/ssl/vsftpd-cert.pem rsa_private_key_file/etc/vsftpd/ssl/vsftpd-key.pem # 匿名用戶不允許走加密也不允許傳數(shù)據(jù) allow_anon_sslNO force_local_data_sslYES force_local_logins_sslYES # 關(guān)閉空密碼用戶的SSL要求避免某些客戶端被卡住 require_ssl_reuseNO # 嚴(yán)格限定 TLS 版本禁用古老的 SSLv2/SSLv3 ssl_tlsv1YES ssl_sslv2NO ssl_sslv3NO重點(diǎn)解釋幾個(gè)配置項(xiàng)force_local_logins_sslYES本地用戶登錄時(shí)必須走 TLS 加密防止密碼在網(wǎng)絡(luò)上裸奔force_local_data_sslYES數(shù)據(jù)傳輸也必須加密require_ssl_reuseNO這個(gè)必須解釋一下。VSFTPD 默認(rèn)要求客戶端復(fù)用 SSL 會(huì)話但 FileZilla 等主流客戶端對(duì)這個(gè)特性支持得不好不關(guān)掉的話會(huì)出現(xiàn)“可以登錄但列目錄或傳輸文件時(shí)斷開”的詭異問題。這個(gè)配置一開始直接害我排查了大半天后來查到是 session reuse 的坑關(guān)掉后一切正常。5.3 三個(gè)高頻 SSL 報(bào)錯(cuò)與定位報(bào)錯(cuò)/現(xiàn)象常見原因處理方式500 OOPS: SSL: cannot load RSA private key私鑰路徑錯(cuò)、權(quán)限不對(duì)、證書和私鑰不匹配檢查rsa_private_key_file路徑用openssl rsa -in key.pem -check校驗(yàn)私鑰用openssl x509 -in cert.pem -noout -modulus和私鑰 modulus 對(duì)比客戶端能連但登錄/傳輸瞬間斷開require_ssl_reuseYES導(dǎo)致客戶端會(huì)話復(fù)用不兼容配置里加require_ssl_reuseNO握手失敗日志有certificate has expired證書過期更新證書并重啟 vsftpd同時(shí)檢查客戶端有沒有緩存舊證書這里額外提醒一句更新 VSFTPD 證書之后務(wù)必重啟服務(wù)不是 reload 一下就行。VSFTPD 很多版本的配置和證書都是在啟動(dòng)時(shí)加載的reload 不一定生效。我一般是這樣做的$ sudo systemctl restart vsftpd $ sudo tail -f /var/log/vsftpd.log然后拿著 FileZilla 連接測(cè)試用openssl s_client -connect your-server:21 -starttls ftp也能確認(rèn)證書有沒有換成功。6. 一套最簡(jiǎn)單的檢查與巡檢方法把“忘記續(xù)期”變成小概率事件6.1 隨手可查證書有效期檢查遠(yuǎn)程站點(diǎn)的證書$ echo | openssl s_client \ -servername example.com \ -connect example.com:443 2/dev/null \ | openssl x509 -noout -dates輸出兩行notBeforeJan 1 00:00:00 2025 GMT notAfterApr 1 00:00:00 2025 GMT檢查本地證書文件$ openssl x509 -in /path/to/cert.pem -noout -dates如果是 pfx 或 jks稍微多一步# pfx 需要先導(dǎo)出證書或者直接看 pkcs12 信息 $ openssl pkcs12 -in server.pfx -clcerts -nokeys -out /tmp/cert.pem $ openssl x509 -in /tmp/cert.pem -noout -dates這套命令跑完你就能算出還剩多少天到期。順手看一眼服務(wù)器系統(tǒng)時(shí)間$ date $ timedatectl如果發(fā)現(xiàn) NTP 沒開啟先把這個(gè)隱患解決掉否則證書時(shí)間校驗(yàn)會(huì)被系統(tǒng)時(shí)鐘拖下水。6.2 寫一個(gè)批量巡檢腳本服務(wù)器多的話我建議寫個(gè)幾行的 bash 腳本放進(jìn) crontab 每天跑。下面這個(gè)腳本會(huì)檢查一批域名輸出證書的過期時(shí)間和服務(wù)狀態(tài)#!/bin/bash check_domain() { local d$1 local port${2:-443} local enddate local exp_epoch local now_epoch local days_left enddate$(echo | openssl s_client \ -servername $d \ -connect $d:$port 2/dev/null \ | openssl x509 -noout -enddate 2/dev/null \ | cut -d -f2) if [ -z $enddate ]; then echo $d:$port 獲取證書失敗 return fi exp_epoch$(date -d $enddate %s) now_epoch$(date %s) days_left$(( (exp_epoch - now_epoch) / 86400 )) echo $d:$port 剩余 ${days_left} 天 ($enddate) } for domain in example.com api.example.com ftp.example.com; do check_domain $domain done把這個(gè)腳本放到/usr/local/bin/check_cert.sh然后加一個(gè) crontab0 9 * * * /bin/bash /usr/local/bin/check_cert.sh /var/log/cert_check.log 21每天看一眼日志或者把輸出重定向到監(jiān)控告警里到期前 30 天開始提醒。如果你用的云平臺(tái)有云監(jiān)控、事件服務(wù)也可以直接把檢查結(jié)果接進(jìn)去做成更自動(dòng)化的告警。6.3 我的個(gè)人習(xí)慣講了這么多理論和命令最后說幾個(gè)我自己的實(shí)際習(xí)慣供參考申請(qǐng)證書當(dāng)天就在日歷里設(shè)提醒提前 30 天和提前 7 天各一次。免費(fèi)的 90 天證書一年至少四個(gè)周期日歷提醒是最低成本的保底方案。別把所有站點(diǎn)部署在同一張證書的到期日上。如果都是 Lets Encrypt 自動(dòng)續(xù)期還好如果是手動(dòng)續(xù)期盡量錯(cuò)開時(shí)間避免某個(gè)月突然要換五六張證書。acme.sh 配合 DNS API 是更省心的替代方案。如果你不想裝 certbot 那一套acme.sh 支持通過 DNS API 自動(dòng)完成域名驗(yàn)證簽發(fā)后還能定義 install-cert 鉤子自動(dòng)重載 Nginx、Tomcat。對(duì)阿里云、Cloudflare 等 DNS 服務(wù)商都有現(xiàn)成腳本設(shè)置一次之后也是全自動(dòng)。每個(gè)季度抽十分鐘用 SSL Labs 跑一次全站 HTTPS 評(píng)分能一次性看到證書鏈、TLS 協(xié)議版本、弱密碼套件等細(xì)節(jié)。這個(gè)習(xí)慣能幫你把“證書有效期”之外的問題也提前暴露出來。我在實(shí)際維護(hù)中發(fā)現(xiàn)SSL 證書管理最危險(xiǎn)的時(shí)間點(diǎn)不是“忘了續(xù)期”的那一天而是第一次手動(dòng)續(xù)期成功之后的松懈。第一次坑爬出來之后大多數(shù)人會(huì)想“我都知道怎么換了下次提前換就行”結(jié)果第二次還是會(huì)在某個(gè)凌晨被用戶提醒。所以我的原則是任何能用腳本、定時(shí)任務(wù)、日歷提醒自動(dòng)化的事絕不依賴自己的記性?；ㄊ昼姲褭z查機(jī)制搭好遠(yuǎn)比每年臨到頭來折騰幾次從容得多。