最近給一個內(nèi)部業(yè)務(wù)系統(tǒng)做HTTPS改造順便把登錄環(huán)節(jié)升級成了雙向認(rèn)證整個過程涉及用OpenSSL從零搭建一套私有CA再基于它簽發(fā)HTTPS服務(wù)器證書和用于身份校驗(yàn)的客戶端證書。這套流程不算新但真跑一遍會發(fā)現(xiàn)細(xì)節(jié)非常多——證書鏈的組裝順序、SAN字段漏填導(dǎo)致的瀏覽器告警、客戶端證書如何讓Java服務(wù)端認(rèn)下來、吊銷列表要不要維護(hù)等等任何一個點(diǎn)沒處理好線上就會冒出各種看起來很神秘的報錯。這篇就按我實(shí)際操作的順序把從零搭建私有CA到簽發(fā)HTTPS證書再到雙向認(rèn)證落地的完整流程捋一遍該解釋的原理和該避開的坑都會一并說清楚。這篇內(nèi)容適合這幾類讀者剛接觸證書體系、想搞清楚自簽名證書、私有CA和HTTPS之間關(guān)系的人正在做內(nèi)部系統(tǒng)或微服務(wù)網(wǎng)關(guān)、需要一個內(nèi)部可信證書體系的人以及被瀏覽器“證書不受信任”紅屏折磨、想一次性解決團(tuán)隊內(nèi)部證書問題的運(yùn)維或后端開發(fā)。1. 項目概述與整體思路拆解1.1 什么場景下需要自己搭一套私有CA很多團(tuán)隊一開始圖省事直接生成一個自簽名證書丟到Nginx里瀏覽器打開紅色警告頁點(diǎn)“繼續(xù)訪問”也就過去了。這種做法在開發(fā)環(huán)境里能湊合但一旦涉及多臺服務(wù)器、多個服務(wù)、多個同事問題就來了每臺機(jī)器的證書都長得不一樣每臺機(jī)器都得手動信任一次而且下次換證書又會冒出一堆“不受信任”的告警。私有CA解決的核心問題是把“信任”沉淀下來。你只需要建一個根CA把根證書導(dǎo)入到團(tuán)隊所有人的電腦或所有服務(wù)器的信任區(qū)一次之后這個CA簽發(fā)的所有證書都會被自動信任。后續(xù)無論新增多少臺服務(wù)器、簽多少張證書都不用再逐臺處理瀏覽器告警。類似地在微服務(wù)或API網(wǎng)關(guān)場景里服務(wù)間通信做雙向認(rèn)證時客戶端證書也統(tǒng)一由私有CA簽發(fā)校驗(yàn)邏輯就非常干凈只信任這個CA簽過的證書。具體場景包括內(nèi)部管理系統(tǒng)、測試環(huán)境、CI/CD流水線的制品簽名、設(shè)備證書、網(wǎng)關(guān)與后端之間的mTLS認(rèn)證、以及代碼庫或消息隊列的傳輸加密。只要這些系統(tǒng)的用戶都是企業(yè)內(nèi)部人員而不是面向公網(wǎng)的海量用戶自建私有CA都是一種成本低、可控性高的方案。1.2 HTTPS單向認(rèn)證與雙向認(rèn)證的差別先理清兩個概念。日常說的HTTPS默認(rèn)是單向認(rèn)證瀏覽器驗(yàn)證服務(wù)器的證書是否可信、域名是否匹配確認(rèn)沒問題后建立加密通道服務(wù)器并不驗(yàn)證瀏覽器的身份。凡是連到這個服務(wù)器的人都能正常訪問只是傳輸過程加密了。雙向認(rèn)證也就是mTLS多了一步服務(wù)器也要驗(yàn)證客戶端出示的證書。這個客戶端證書不是瀏覽器自動帶的而是你親自頒發(fā)給某個具體用戶或某臺設(shè)備的。服務(wù)器校驗(yàn)通過后才允許建立連接。這樣既能保證數(shù)據(jù)在傳輸過程中加密又能明確知道“正在訪問的是誰”。在實(shí)際項目里單向認(rèn)證適合對外提供服務(wù)的Web站點(diǎn)雙向認(rèn)證適合內(nèi)部API、管理后臺、設(shè)備接入這些對身份要求嚴(yán)格的場景。我這次改造的系統(tǒng)恰好兩類都要對外訪問的管理頁面用HTTPS單向加密內(nèi)部服務(wù)之間的API調(diào)用用mTLS雙向認(rèn)證。用一套私有CA兩條線一次搞定。1.3 為什么選OpenSSL而不是現(xiàn)成的圖形化管理平臺市面上有不少開源PKI管理平臺界面好看、有Web管理端、支持證書申請審批流。但對于中小規(guī)模團(tuán)隊來說引入這類系統(tǒng)會增加一套基礎(chǔ)設(shè)施數(shù)據(jù)庫、中間件、額外的運(yùn)維負(fù)擔(dān)。而且證書體系本身就是非常底層的東西一旦平臺本身出了故障整個簽發(fā)鏈路都動不了。OpenSSL的命令行方式雖然看起來原始但勝在透明和可控。每條命令干了什么、每個文件放在哪兒、每份證書包含什么字段都是一清二楚的。出了問題可以直接看日志和文件排查不需要在平臺代碼里翻原因。另外OpenSSL是系統(tǒng)自帶或者極易安裝的基礎(chǔ)工具任何一臺Linux服務(wù)器上都有沒有額外的依賴包袱。我的建議是如果只是十幾臺服務(wù)器、幾十個用戶的規(guī)模直接用OpenSSL手工維護(hù)完全夠用而且能讓你對整個證書體系有深刻理解。等到證書簽發(fā)變成高頻操作、需要多人協(xié)作審批的時候再考慮引入專業(yè)的管理系統(tǒng)也不遲。這套手工流程跑通了你自己寫的簽發(fā)腳本就是未來對接管理平臺的最佳需求文檔。2. 環(huán)境準(zhǔn)備與OpenSSL核心配置2.1 檢查OpenSSL版本與基礎(chǔ)環(huán)境我這次是在一臺專用的內(nèi)部服務(wù)器上操作的系統(tǒng)是常見的Linux發(fā)行版。開始之前先確認(rèn)OpenSSL版本openssl version如果輸出顯示1.1.1或3.x版本基本沒問題。如果還在用1.0.2甚至更老的版本建議先升級。舊版本對現(xiàn)代TLS協(xié)議、SAN擴(kuò)展、證書算法的支持都不夠好很多在這個流程里要用的參數(shù)在老版本下會報錯或者靜默失效。大多數(shù)Linux發(fā)行版的包管理器都能直接安裝# Debian/Ubuntu系 sudo apt update sudo apt install openssl # RHEL/CentOS系 sudo yum install opensslWindows和macOS上也可以用但生產(chǎn)環(huán)境建議統(tǒng)一在Linux上操作文件路徑和命令行為都更標(biāo)準(zhǔn)。我習(xí)慣把整套CA相關(guān)文件放在/opt/ca目錄下所有操作都在這個目錄里完成不散落到各處。2.2 一份能直接落地的OpenSSL配置文件OpenSSL雖然支持在命令行里直接指定很多參數(shù)但涉及多個擴(kuò)展字段時還是建議把所有配置集中到一個文件里。這個文件是整個CA體系的“需求文檔”后續(xù)所有證書簽發(fā)都依賴它。我在/opt/ca/openssl.cnf里放了一份核心配置內(nèi)容如下字段含義隨后逐段解釋[ ca ] default_ca CA_default [ CA_default ] dir /opt/ca database $dir/index.txt new_certs_dir $dir/newcerts certificate $dir/ca.crt private_key $dir/private/ca.key serial $dir/serial crlnumber $dir/crlnumber crl $dir/crl/ca.crl private_key_pass 你的根密鑰密碼 default_md sha256 default_days 825 policy policy_loose unique_subject no copy_extensions copy [ policy_loose ] countryName optional stateOrProvinceName optional organizationName optional organizationalUnitName optional commonName supplied emailAddress optional [ req ] default_bits 2048 distinguished_name req_distinguished_name string_mask utf8only x509_extensions v3_ca [ req_distinguished_name ] countryName Country Name (2 letter code) countryName_default CN stateOrProvinceName State or Province Name stateOrProvinceName_default Beijing organizationName Organization Name organizationName_default Example Internal organizationalUnitName Organizational Unit Name organizationalUnitName_default IT Security commonName Common Name [ v3_ca ] basicConstraints critical, CA:TRUE subjectKeyIdentifier hash authorityKeyIdentifier keyid:always, issuer [ server_ext ] basicConstraints CA:FALSE keyUsage digitalSignature, keyEncipherment extendedKeyUsage serverAuth subjectKeyIdentifier hash authorityKeyIdentifier keyid, issuer subjectAltName DNS:example.internal [ client_ext ] basicConstraints CA:FALSE keyUsage digitalSignature extendedKeyUsage clientAuth subjectKeyIdentifier hash authorityKeyIdentifier keyid, issuer剛接觸配置文件時容易懵我說下關(guān)鍵段落的作用。[ CA_default ]是CA簽發(fā)證書時的工作參數(shù)。dir指定所有CA文件的根目錄database指向index.txt這個文件記錄了所有已簽發(fā)證書的狀態(tài)是后續(xù)吊銷操作的基礎(chǔ)serial指向序列號文件每簽發(fā)一張證書序列號自動遞增保證不會重復(fù)crlnumber是吊銷列表的編號文件后面配吊銷時要用到。copy_extensions copy這個參數(shù)很關(guān)鍵它允許CA在簽發(fā)時將CSR里帶的擴(kuò)展字段比如SAN復(fù)制到最終證書里省去了每次在命令行手動補(bǔ)擴(kuò)展的麻煩。[ req_distinguished_name ]是生成CSR或自簽證書時提示輸入組織信息的模板。這里我預(yù)填了默認(rèn)值實(shí)際操作時會自動帶入省去大量手工輸入。注意默認(rèn)組織名要和你計劃拿到的證書用途匹配不需要和真實(shí)營業(yè)執(zhí)照單位一致因?yàn)檫@是內(nèi)部CA只服務(wù)于你自己的信任體系。[ v3_ca ]定義了根證書的擴(kuò)展屬性。CA:TRUE表示這是證書頒發(fā)機(jī)構(gòu)critical標(biāo)記讓客戶端嚴(yán)格處理這個字段。[ server_ext ]和[ client_ext ]分別定義了服務(wù)器證書和客戶端證書要帶的擴(kuò)展后面簽發(fā)時會用-extensions參數(shù)指定。2.3 配置文件里的兩個隱藏坑配置文件里unique_subject no是否開啟直接決定了你能不能給同一個Common Name反復(fù)簽發(fā)新證書。默認(rèn)情況下OpenSSL拒絕為相同DN簽發(fā)第二張證書因?yàn)樗縤ndex.txt里的記錄判斷。我在配置里設(shè)置了unique_subject no這樣同一臺服務(wù)器證書到期后續(xù)期或者同一域名多次簽發(fā)不會報ERROR:Already exists之類的錯誤。但代價是歷史證書沒法簡單通過DN區(qū)分所以一定要靠序列號來追蹤每張證書。另一個容易踩的坑是copy_extensions。這個參數(shù)只對通過openssl ca命令簽發(fā)時生效對直接openssl x509 -req自簽是不生效的。很多教程喜歡用后者但它處理擴(kuò)展字段很不靈活。除非你只是做一次性測試否則建議一律使用openssl ca。我自己早期就吃過虧用openssl x509 -req命令簽發(fā)證書SAN字段始終帶不進(jìn)去瀏覽器一直報域名不匹配。后來換回openssl ca配合copy_extensions一次性解決。3. 私有CA的完整構(gòu)建過程3.1 創(chuàng)建目錄結(jié)構(gòu)與初始化文件在執(zhí)行任何OpenSSL命令之前先把目錄骨架搭好。我在/opt/ca下執(zhí)行mkdir -p /opt/ca/{newcerts,crl,private} cd /opt/ca touch index.txt echo 1000 serial echo 1000 crlnumber各目錄的用途newcerts存放CA簽發(fā)的所有證書原始文件crl存放吊銷列表文件private存放CA私鑰這個目錄后續(xù)要單獨(dú)設(shè)置權(quán)限index.txt是證書數(shù)據(jù)庫OpenSSL每簽一張證書就往里面追加一條記錄serial是序列號來源首張證書從1000開始crlnumber是吊銷列表的編號來源。這些文件看起來不起眼但它們是整個CA運(yùn)作的“賬本”。如果某天你發(fā)現(xiàn)openssl ca命令報錯大概率是這個賬本結(jié)構(gòu)不對或者某個文件被誤刪了。3.2 生成根私鑰與根證書根私鑰是整個CA體系里最敏感的文件。我用如下命令生成cd /opt/ca openssl genrsa -aes256 -out private/ca.key 4096命令執(zhí)行后會要求設(shè)置一個密碼這個密碼用于保護(hù)根私鑰每次用根密鑰簽發(fā)證書都要輸入。-aes256表示用AES-256加密私鑰文件即使文件泄露沒有密碼也無法使用。位數(shù)上我選4096因?yàn)楦鵆A是長期信任錨點(diǎn)密鑰強(qiáng)度高一點(diǎn)更安心。接著生成根證書openssl req -x509 -new -nodes -key private/ca.key \ -sha256 -days 7300 \ -out ca.crt \ -config openssl.cnf \ -extensions v3_ca-x509表示直接生成自簽名證書而不是CSR-days 7300設(shè)置了20年有效期-extensions v3_ca引入了配置文件里的CA擴(kuò)展。執(zhí)行后會按配置文件里的提示填入國家、省份、組織、Common Name。Common Name建議填一個能代表這個CA的名字比如Example Internal Root CA方便識別。生成后可以驗(yàn)證一下關(guān)鍵字段openssl x509 -in ca.crt -noout -text | grep -A1 Basic Constraints如果看到CA:TRUE根證書就創(chuàng)建成功了。順便說一下密鑰算法選擇。根CA我堅持用RSA 4096因?yàn)榧嫒菪宰顝V幾乎所有客戶端、服務(wù)器、物聯(lián)網(wǎng)設(shè)備都支持。ECC密鑰雖然更小、更快但在一些老設(shè)備上會遇到算法不支持的問題。對于內(nèi)部CA這種追求穩(wěn)定兼容的場景RSA是更穩(wěn)妥的起點(diǎn)。后續(xù)如果要做性能優(yōu)化可以為葉子證書單獨(dú)使用ECC密鑰不影響根CA的兼容性。3.3 根私鑰保護(hù)與日常使用規(guī)范根私鑰生成后第一件事就是收緊權(quán)限chmod 700 /opt/ca/private chmod 600 /opt/ca/private/ca.key我見過一些團(tuán)隊的CA私鑰權(quán)限是644任何登錄服務(wù)器的用戶都能讀到這種情況根私鑰和沒加密沒區(qū)別。正確做法是private目錄只允許CA管理用戶訪問其他用戶一律不可讀。日常簽發(fā)證書時我的習(xí)慣是盡量不使用根密鑰直接簽發(fā)。更規(guī)范的架構(gòu)是根CA之下再建一個中間CA日常簽發(fā)都用中間CA的密鑰根CA私鑰離線存放只在給中間CA續(xù)期或極少數(shù)特殊情況下才動用。這樣做的好處是即使日常使用的中間CA密鑰泄露也能立即吊銷中間CA證書并用根CA重建一個不必推倒整個信任體系。對絕大多數(shù)中小團(tuán)隊來說直接使用根CA簽發(fā)也能接受前提是根私鑰的存放位置要安全。我自己的做法是根私鑰放在一臺不對外暴露任何服務(wù)的內(nèi)網(wǎng)機(jī)器上平時 SSH 都關(guān)閉需要簽發(fā)證書時才臨時開啟并立即關(guān)閉。不要圖方便把根私鑰復(fù)制到每一臺應(yīng)用服務(wù)器上那樣風(fēng)險面太大了。4. HTTPS服務(wù)器證書簽發(fā)與部署4.1 生成服務(wù)器私鑰與CSR含SAN證書簽發(fā)的第一步是在目標(biāo)服務(wù)器上生成私鑰和CSR。私鑰放在應(yīng)用服務(wù)器本地不需要傳給CA。這次為客戶內(nèi)部管理系統(tǒng)簽發(fā)證書假設(shè)域名是app.example.internal。openssl genrsa -out /etc/nginx/ssl/app.key 2048 openssl req -new -key /etc/nginx/ssl/app.key \ -out /opt/ca/app.csr \ -config /opt/ca/openssl.cnf \ -subj /CNapp.example.internal/OExample Internal/OUIT \ -addext subjectAltNameDNS:app.example.internal,DNS:api.example.internal服務(wù)器私鑰選2048位即可不需要和根CA一樣用4096。因?yàn)槿~子證書更新頻率高密鑰生命周期短2048位在當(dāng)前安全強(qiáng)度下完全夠用性能開銷也更低。-subj參數(shù)避免了交互式填寫信息-addext直接添加SAN字段。san里除了主域名如果這臺服務(wù)器還要承擔(dān)API域名也可以一并寫進(jìn)去。這樣一張證書可以覆蓋多個域名。生成CSR后立刻檢查擴(kuò)展字段是否帶上openssl req -in app.csr -noout -text | grep -A1 Subject Alternative Name如果SAN沒有顯示出來不要繼續(xù)簽發(fā)否則后面瀏覽器一定報域名不匹配。SAN缺失是最容易犯的錯下面第6章會專門說。4.2 用CA簽發(fā)證書并驗(yàn)證證書鏈把CSR放到CA機(jī)器上執(zhí)行簽發(fā)cd /opt/ca openssl ca -in app.csr -out app.crt \ -config openssl.cnf \ -extensions server_ext \ -days 825過程中的交互主要是確認(rèn)簽名請求。-days 825對應(yīng)兩年多一點(diǎn)的有效期LetsEncrypt今年改規(guī)則后的最長長度也是825天這個值兼顧了續(xù)期成本和證書安全。簽發(fā)完成后用openssl verify驗(yàn)證整條鏈路openssl verify -CAfile /opt/ca/ca.crt app.crt如果輸出app.crt: OK證書鏈就通了。接下來把證書文件拷貝回應(yīng)用服務(wù)器準(zhǔn)備部署。4.3 Nginx部署與全鏈測試Nginx上需要配置三個文件私鑰、服務(wù)器證書、CA根證書。先創(chuàng)建一個合并的證書鏈文件cat /opt/ca/app.crt /opt/ca/ca.crt /etc/nginx/ssl/app_fullchain.crt為什么要合并因?yàn)榉?wù)器證書是由私有CA簽發(fā)的瀏覽器如果只拿到服務(wù)器證書本身無法自行建立“服務(wù)器證書→根證書”的信任關(guān)系。把CA證書跟在后面一起發(fā)出去瀏覽器能沿著證書鏈找到自己信任的根證書。順序必須先是服務(wù)器證書再是CA證書反了的話部分客戶端會直接拒絕。Nginx站點(diǎn)配置如下server { listen 443 ssl; server_name app.example.internal; ssl_certificate /etc/nginx/ssl/app_fullchain.crt; ssl_certificate_key /etc/nginx/ssl/app.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; location / { proxy_pass http://127.0.0.1:8080; } }配置完成后重載Nginxnginx -t systemctl reload nginx在命令行用curl驗(yàn)證單向HTTPScurl --cacert /opt/ca/ca.crt https://app.example.internal -v--cacert讓curl使用我們的根證書作為信任錨正常應(yīng)返回業(yè)務(wù)內(nèi)容且沒有證書告警。如果要測試瀏覽器體驗(yàn)把ca.crt導(dǎo)入操作系統(tǒng)或?yàn)g覽器的受信任根證書區(qū)訪問https://app.example.internal就不會再出現(xiàn)紅色警告。這里有個小小的經(jīng)驗(yàn)內(nèi)網(wǎng)域名如果不想讓瀏覽器總是跳到搜索引擎或者出現(xiàn)奇怪提示最好在內(nèi)部DNS里把域名解析到正確IP同時確保訪問時用的是帶HTTPS的完整域名。很多“證書不受信任”其實(shí)是輸入了IP地址而不是證書上的域名導(dǎo)致的。5. 雙向認(rèn)證mTLS證書簽發(fā)與落地5.1 客戶端證書簽發(fā)全流程單向HTTPS部署完成后開始處理內(nèi)部API的雙向認(rèn)證。為某臺API調(diào)用客戶端機(jī)器簽發(fā)客戶端證書流程類似但用途字段不同。openssl genrsa -out client1.key 2048 openssl req -new -key client1.key \ -out client1.csr \ -config /opt/ca/openssl.cnf \ -subj /CNclient1/OExample Internal/OUAPI Clients簽發(fā)時用client_ext擴(kuò)展cd /opt/ca openssl ca -in client1.csr -out client1.crt \ -config openssl.cnf \ -extensions client_ext \ -days 825簽發(fā)完成后客戶端私鑰和證書一般打包成PKCS12格式方便瀏覽器或Java環(huán)境導(dǎo)入openssl pkcs12 -export \ -in client1.crt \ -inkey client1.key \ -certfile ca.crt \ -out client1.p12執(zhí)行時會要求設(shè)置PKCS12文件的導(dǎo)出密碼。這個密碼要單獨(dú)發(fā)給使用方不要和私鑰密碼混用。-certfile ca.crt的作用是把根證書也打包進(jìn)去接收方導(dǎo)入后不僅有自己的身份證書還自動信任了根CA省去額外導(dǎo)入根證書的步驟。這里有個細(xì)節(jié)我要強(qiáng)調(diào)客戶端證書的CommonName不要隨便填寫它通常是服務(wù)器端用來識別用戶或設(shè)備的主要依據(jù)。比如網(wǎng)關(guān)可以根據(jù)證書的CN字段判斷是哪個服務(wù)在調(diào)用配合$ssl_client_s_dn變量可以拿到完整的DN信息做權(quán)限控制。如果亂填后面做訪問控制會非常痛苦。5.2 Nginx雙向認(rèn)證配置與驗(yàn)證還是在Nginx層面開啟雙向認(rèn)證修改之前的server塊server { listen 443 ssl; server_name api.example.internal; ssl_certificate /etc/nginx/ssl/app_fullchain.crt; ssl_certificate_key /etc/nginx/ssl/app.key; ssl_client_certificate /opt/ca/ca.crt; ssl_verify_client on; ssl_verify_depth 2; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header X-Client-DN $ssl_client_s_dn; proxy_set_header X-Client-Verified $ssl_client_verify; } }ssl_client_certificate指定了根CA證書服務(wù)器用它對客戶端證書做鏈驗(yàn)證ssl_verify_client on強(qiáng)制要求所有連接都出示客戶端證書ssl_verify_depth 2設(shè)置了證書鏈深度防止太深的偽造鏈蒙混過關(guān)。驗(yàn)證時在客戶端機(jī)器執(zhí)行curl --cacert ca.crt --cert client1.crt --key client1.key https://api.example.internal帶上證書后請求正常返回業(yè)務(wù)內(nèi)容。如果去掉--cert和--key再請求Nginx會直接返回400錯誤這是預(yù)期結(jié)果。應(yīng)用層可以拿到我在配置里設(shè)置的X-Client-DN請求頭從里面解析出CNclient1就能知道是哪個客戶端在調(diào)用做基于身份的訪問控制就非常方便了。這種方式比在HTTP頭里偽造一個客戶端標(biāo)識要可靠得多因?yàn)樽C書是經(jīng)過私鑰簽名驗(yàn)證的。5.3 Java端與瀏覽器側(cè)導(dǎo)入內(nèi)部系統(tǒng)相當(dāng)一部分是Java寫的Java客戶端和服務(wù)端對證書的處理方式略有不同。如果要讓Java應(yīng)用信任我們私有CA簽發(fā)的服務(wù)器證書需要把根證書導(dǎo)入JVM的truststorekeytool -importcert -alias internal-ca -file ca.crt \ -keystore /path/to/truststore.jks -storepass changeit如果要讓Java應(yīng)用作為雙向認(rèn)證的客戶端也就是調(diào)用方需要把之前生成的PKCS12文件導(dǎo)入到keystore并配合密碼參數(shù)使用keytool -importkeystore \ -srckeystore client1.p12 -srcstoretype PKCS12 \ -destkeystore client1.jks -deststoretype JKS實(shí)際調(diào)用HTTPS接口時Java代碼或框架配置里設(shè)置這兩個對象即可。很多人踩的坑是只設(shè)置了信任服務(wù)器證書的truststore卻忘了配客戶端身份導(dǎo)致服務(wù)端一直要求客戶端證書而客戶端拿不出來連接被RST。記住一個口訣truststore是“我信任誰”keystore是“我是誰”。瀏覽器側(cè)導(dǎo)入就更簡單了。雙擊client1.p12輸入導(dǎo)出密碼就會進(jìn)入系統(tǒng)證書導(dǎo)入向?qū)А?dǎo)入后重啟瀏覽器再訪問需要雙向認(rèn)證的站點(diǎn)瀏覽器會自動彈出證書選擇框選對客戶端證書就能正常訪問不選則直接403或400。5.4 雙向認(rèn)證的幾個安全細(xì)節(jié)提醒雙向認(rèn)證不等于“加了證書就絕對安全”幾個細(xì)節(jié)必須注意。第一客戶端私鑰的管理。如果客戶端私鑰泄露等于身份被盜用。除了提醒使用者妥善保管還應(yīng)該規(guī)劃證書吊銷流程。一旦發(fā)現(xiàn)疑似泄露立即在CA上執(zhí)行吊銷openssl ca -revoke client1.crt -config openssl.cnf吊銷后生成新的吊銷列表openssl ca -gencrl -out /opt/ca/crl/ca.crl -config openssl.cnf然后把新的ca.crl分發(fā)給所有需要校驗(yàn)吊銷狀態(tài)的Nginx或網(wǎng)關(guān)。這一步很多人會忽略但它是證書體系閉環(huán)里不可少的一環(huán)。第二ssl_verify_client on一旦開啟所有不攜證書的請求都會失敗。如果有監(jiān)控系統(tǒng)、健康檢查腳本、外部定時任務(wù)也在訪問這個端點(diǎn)都要同步更新它們的證書。我在一次改造中就是因?yàn)闆]提前排查監(jiān)控鏈路開啟雙向認(rèn)證后監(jiān)控數(shù)據(jù)斷了好幾個小時才發(fā)現(xiàn)。第三證書鏈深度的含義要清楚。ssl_verify_depth 2意味著客戶端證書→中間CA→根CA兩層路徑。如果你的體系之后引入了中間CA深度要相應(yīng)調(diào)整否則合法證書也會被拒。6. 常見問題與排查技巧實(shí)錄6.1 證書鏈不完整導(dǎo)致的各種“無法驗(yàn)證服務(wù)器證書”最典型的報錯是curl直接提示curl: (60) SSL certificate problem: unable to get local issuer certificate或者瀏覽器顯示“無法建立到服務(wù)器的安全連接”。排查方式很簡單用openssl自己模擬客戶端看服務(wù)器實(shí)際下發(fā)的內(nèi)容openssl s_client -connect app.example.internal:443 -showcerts如果輸出里只有服務(wù)器證書沒有CA證書那就是證書鏈沒合并好?；氐降?.3節(jié)重新合并fullchain文件確認(rèn)順序是“服務(wù)器證書在前CA證書在后”再重載Nginx即可。這個問題的本質(zhì)是服務(wù)器沒有把完整的信任鏈交給客戶端客戶端拿著半截鏈子無法走到自己信任的根證書。實(shí)際排障時我見過把ca.crt內(nèi)容寫到server.crt文件的前面導(dǎo)致鏈順序顛倒的情況客戶端解析直接失敗。合并完文件后先用openssl crl2pkcs7 -nocrl -certfile app_fullchain.crt | openssl pkcs7 -print_certs -noout看看整體結(jié)構(gòu)確認(rèn)順序無誤再部署。6.2 SAN缺失導(dǎo)致瀏覽器不信任自2017年瀏覽器普遍收緊策略以來證書里如果SAN字段里沒有當(dāng)前訪問的域名即便證書鏈完整、CA受信任瀏覽器也一樣報錯。Chrome會提示“此服務(wù)器發(fā)送的證書與此URL不匹配”Firefox提示“證書僅對某些名稱有效”。排查時用openssl x509 -in app.crt -noout -text | grep -A1 Subject Alternative Name如果輸出為空說明簽發(fā)時沒帶上SAN。解決方法是回到4.1節(jié)重新生成CSR并加上-addext然后重新簽發(fā)。如果CSR本身帶了SAN但簽發(fā)出來的證書沒有檢查配置文件里的copy_extensions copy是否生效以及簽發(fā)命令是否用了-extensions server_ext。這個坑在舊教程里特別常見很多人還在沿用只填Common Name的老方法但在現(xiàn)行瀏覽器規(guī)則下已經(jīng)行不通。Common Name目前只是“顯示名”域名匹配完全看SAN。6.3 時間不同步導(dǎo)致的證書“尚未生效”另一種隱蔽的坑是服務(wù)器時間不對。證書里有notBefore和notAfter兩個時間字段如果客戶端機(jī)器或服務(wù)器機(jī)器時間漂移超出有效期范圍一個明明有效的證書會被判定為“尚未生效”或“已過期”。親歷過一次搭建完成后瀏覽器一直報“證書無效”查遍了證書鏈和SAN都沒有問題最后用date一看服務(wù)器時間比真實(shí)時間快了12分鐘而證書才剛簽發(fā)幾分鐘正好落在“尚未生效”區(qū)間內(nèi)。同步時間后立刻恢復(fù)。證書相關(guān)排障一定要先確認(rèn)所有相關(guān)機(jī)器的時間是同步的。建議在基礎(chǔ)設(shè)施層就配置好時間同步服務(wù)省去這類本可避免的奇怪問題。一個容易引起混亂的點(diǎn)是Nginx啟動時會檢查證書文件的時間但有些版本對時間要求并不嚴(yán)格反而是客戶端瀏覽器較真。結(jié)果就是服務(wù)器自己覺得一切正常瀏覽器卻一直在報錯。出現(xiàn)這種“服務(wù)器沒癥狀、客戶端有癥狀”的情況十有八九是時間問題。6.4 雙向認(rèn)證客戶端連接失敗排查雙向認(rèn)證場景下最常見的報錯是Nginx返回400 No required SSL certificate was sent意思很直白服務(wù)器要求客戶端證書客戶端沒給。排查步驟確認(rèn)客戶端安裝了證書curl情況下的--cert和--key參數(shù)或Java的keystore配置確認(rèn)客戶端證書確實(shí)是這個CA簽發(fā)的用openssl verify -CAfile ca.crt client1.crt驗(yàn)證確認(rèn)Nginx的ssl_client_certificate指向的CA文件路徑正確且Nginx能讀到查看Nginx錯誤日志通常會有更詳細(xì)的TLS握手階段信息。另一個高頻場景是Java客戶端報“PKIX path building failed”。這通常意味著信任鏈不完整也就是客戶端應(yīng)用沒有把我們私有CA的根證書導(dǎo)入truststore。注意Java的默認(rèn)truststore和操作系統(tǒng)信任區(qū)是兩個概念只導(dǎo)入系統(tǒng)證書是不夠的必須用keytool往Java自己的truststore里也導(dǎo)入一份。這個問題讓我在某個項目里卡了大半天后來才發(fā)現(xiàn)團(tuán)隊里其他同事根本沒有在JVM配置里加根證書?，F(xiàn)象可能原因快速排查curl報60錯誤證書鏈不完整openssl s_client -showcerts瀏覽器提示域名不匹配SAN缺失openssl x509 -text查看SAN證書尚未生效/已過期服務(wù)器時間漂移date對比當(dāng)前時間400 No required SSL certificate客戶端沒帶證書檢查curl參數(shù)或Java keystoreJava報PKIX path building failedtruststore沒有根CA用keytool導(dǎo)入ca.crtNginx啟動失敗私鑰權(quán)限過寬檢查證書key文件權(quán)限整套流程跑下來我的體會有幾條也是最后想分享的第一根CA一旦建成根私鑰就鎖起來日常簽發(fā)證書的密鑰和根密鑰分開管理。不要為了省事讓所有操作都走根密鑰一旦泄露整個信任體系就得重建。第二證書有效期寧可定短一點(diǎn)配合自動化的續(xù)簽?zāi)_本也不要一簽十年。有效期越長風(fēng)險窗口越大而且到期前的維護(hù)成本遠(yuǎn)高于重新簽發(fā)的成本。第三配置文件一定固定下來統(tǒng)一維護(hù)在代碼倉庫里不要每次簽發(fā)都臨時寫命令行參數(shù)。過幾個月回頭看你大概率記不住當(dāng)時簽的證書用了什么參數(shù)一個結(jié)構(gòu)清晰的配置文件能幫你省掉大量精力。如果正在搭私有CA的路上建議先把配置文件吃透再動手。配置文件就是你的需求文檔這一步盯住了后面基本就是流水線作業(yè)。