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