1. 項(xiàng)目概述與核心痛點(diǎn)最近在幫一個(gè)醫(yī)療信息化團(tuán)隊(duì)部署一套基于VMware Cloud FoundationVCF的私有AI服務(wù)Private AI Services 簡稱PAIS環(huán)境。這個(gè)環(huán)境主要用于處理一些敏感的醫(yī)療數(shù)據(jù)分析和模型訓(xùn)練比如輔助診斷影像分析、病歷文本挖掘等。由于數(shù)據(jù)隱私和安全合規(guī)的硬性要求整個(gè)服務(wù)必須運(yùn)行在內(nèi)網(wǎng)并且所有組件間的通信都需要啟用TLS加密。在預(yù)算和流程上暫時(shí)沒法走正規(guī)的CA證書頒發(fā)機(jī)構(gòu)渠道去申請(qǐng)受信證書所以自簽名證書就成了唯一的選擇。聽起來很簡單不就是生成個(gè)證書然后配上去嗎但實(shí)際操作下來從VCF的管理平面到PAIS的各個(gè)微服務(wù)組件再到客戶端連接這一路踩的坑簡直能寫滿一張A4紙。最典型的問題就是你在瀏覽器或者用curl訪問服務(wù)時(shí)那個(gè)經(jīng)典的“您的連接不是私密連接”或者“SSL certificate problem: self signed certificate”錯(cuò)誤。在PAIS這種復(fù)雜的、容器化、微服務(wù)架構(gòu)的環(huán)境里這個(gè)問題會(huì)被放大因?yàn)樽C書需要在多個(gè)層級(jí)被信任VCF Manager、負(fù)載均衡器、Kubernetes Ingress Controller、以及跑在Pod里的各個(gè)服務(wù)本身。所以這篇指南的目的就是把我從生成證書開始到最終讓PAIS所有服務(wù)都能被內(nèi)網(wǎng)客戶端無警告訪問的完整過程、核心原理和那些“坑點(diǎn)”記錄下來。無論你是運(yùn)維工程師、架構(gòu)師還是開發(fā)者只要你在處理VCF、PAIS或者任何類似私有云環(huán)境下自簽名證書的配置希望這篇“避坑實(shí)錄”能幫你省下大量排查時(shí)間。2. 自簽名證書的核心原理與VCF/PAIS環(huán)境特殊性在開始動(dòng)手之前我們必須搞清楚自簽名證書和受信CA簽發(fā)的證書本質(zhì)區(qū)別是什么以及這對(duì)VCF和PAIS意味著什么。2.1 自簽名證書的信任鏈問題一個(gè)標(biāo)準(zhǔn)的TLS/SSL證書信任鏈?zhǔn)沁@樣的你的服務(wù)證書Server Certificate由一個(gè)中間CA證書Intermediate CA Certificate簽名而這個(gè)中間CA證書又由一個(gè)根CA證書Root CA Certificate簽名。你的操作系統(tǒng)或?yàn)g覽器里預(yù)置了這些受信的根CA證書列表。當(dāng)客戶端連接到你的服務(wù)時(shí)它會(huì)收到服務(wù)證書并沿著這個(gè)鏈向上驗(yàn)證直到找到一個(gè)它信任的根CA驗(yàn)證就通過了。自簽名證書則完全不同。它自己就是自己的根CA。也就是說證書的“頒發(fā)者”Issuer和“主題”Subject通常是同一個(gè)。沒有任何公共的、預(yù)置的根CA為它背書。因此所有客戶端瀏覽器、curl、openssl、Java應(yīng)用等在默認(rèn)情況下都會(huì)拒絕信任它拋出安全警告。注意自簽名證書在加密能力上和CA簽發(fā)的證書沒有區(qū)別它同樣能提供強(qiáng)加密的HTTPS連接。問題的核心 solely 在于“信任”。你必須手動(dòng)地將這個(gè)自簽名證書的根CA也就是證書本身或者你專門創(chuàng)建的CA證書安裝到每一個(gè)需要連接該服務(wù)的客戶端信任庫中。2.2 VCF與PAIS架構(gòu)下的證書層級(jí)在VCF環(huán)境中部署PAIS證書的配置涉及多個(gè)層面理解這個(gè)層級(jí)對(duì)排查問題至關(guān)重要VCF管理平面這是入口。VCF Manager本身有一個(gè)管理界面可能還有NSX Manager、vCenter等。這些服務(wù)可能已經(jīng)使用了VCF內(nèi)置或你之前配置的證書。負(fù)載均衡器如NSX ALB/AviPAIS的入口流量通常由負(fù)載均衡器接收。你需要在這里配置一個(gè)包含私鑰和證書的SSL證書對(duì)象并將其綁定到虛擬服務(wù)Virtual Service。這個(gè)證書就是客戶端瀏覽器第一個(gè)會(huì)遇到的。Kubernetes IngressPAIS部署在由VCF管理的Kubernetes集群通常是Tanzu Kubernetes Grid上。外部流量通過負(fù)載均衡器后會(huì)到達(dá)Kubernetes的Ingress資源。Ingress Controller如Contour、NGINX也需要使用證書來終止TLS或者進(jìn)行TLS透傳。PAIS服務(wù)內(nèi)部PAIS本身由多個(gè)微服務(wù)組成如模型服務(wù)、數(shù)據(jù)服務(wù)、API網(wǎng)關(guān)等。這些服務(wù)之間通過Service Mesh如Istio或直接通過Kubernetes Service進(jìn)行通信。如果啟用了mTLS雙向TLS那么每個(gè)服務(wù)都需要自己的證書和信任庫。我們的核心工作就是確保第2層負(fù)載均衡器使用的自簽名證書其根CA被所有內(nèi)網(wǎng)客戶端信任。同時(shí)也要確保內(nèi)部服務(wù)間的證書信任如果涉及正確配置。3. 證書生成一步錯(cuò)步步錯(cuò)很多坑其實(shí)在生成證書的那一刻就埋下了。這里我推薦使用一個(gè)自建的私有CA來為所有服務(wù)簽發(fā)證書而不是為每個(gè)服務(wù)生成單獨(dú)的自簽名證書。這樣做有兩個(gè)巨大優(yōu)勢一是你只需要將這一個(gè)私有CA的根證書導(dǎo)入客戶端它簽發(fā)的所有證書都會(huì)被信任二是管理起來更規(guī)范。3.1 創(chuàng)建私有根CA首先我們創(chuàng)建自己的根CA。# 1. 創(chuàng)建用于存放CA的目錄 mkdir -p my_private_ca cd my_private_ca # 2. 生成根CA的私鑰使用強(qiáng)密碼保護(hù) openssl genrsa -aes256 -out ca.key 4096 # 系統(tǒng)會(huì)提示你輸入并驗(yàn)證密碼。請(qǐng)務(wù)必牢記此密碼。 # 3. 生成根CA的自簽名證書有效期為10年 openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj /CCN/STBeijing/LBeijing/OMyCompany/OUIT/CNMyPrivateRootCA關(guān)鍵參數(shù)解析-subj: 這里設(shè)置了證書的主題信息。CNCommon Name通常被用作CA的名稱。在內(nèi)部環(huán)境你可以根據(jù)自己組織情況設(shè)置C國家、ST省、O組織等字段。特別注意對(duì)于現(xiàn)代瀏覽器和工具CN的作用在減弱更多依賴Subject Alternative NameSAN但根CA的CN仍然重要。-days 3650: 根CA證書有效期很長設(shè)為10年減少維護(hù)頻率。-aes256: 加密私鑰增加安全性。現(xiàn)在你得到了兩個(gè)核心文件ca.key加密的根CA私鑰和ca.crt根CA證書。ca.crt就是將來要導(dǎo)入到所有客戶端機(jī)器上的那個(gè)“信任根源”。3.2 為PAIS服務(wù)簽發(fā)證書假設(shè)我們的PAIS服務(wù)將通過域名pais.internal.mycompany.com來訪問?，F(xiàn)在用剛才創(chuàng)建的CA為它簽發(fā)證書。# 1. 創(chuàng)建服務(wù)私鑰不加密便于服務(wù)器自動(dòng)加載 openssl genrsa -out pais.internal.mycompany.com.key 2048 # 2. 創(chuàng)建證書簽名請(qǐng)求CSR openssl req -new -key pais.internal.mycompany.com.key -out pais.internal.mycompany.com.csr -subj /CCN/STBeijing/LBeijing/OMyCompany/OUPAIS/CNpais.internal.mycompany.com關(guān)鍵一步創(chuàng)建包含SAN的擴(kuò)展配置文件。這是現(xiàn)代TLS的強(qiáng)制要求尤其是Chrome等瀏覽器如果證書不包含SAN擴(kuò)展即使CN正確也會(huì)報(bào)錯(cuò)。創(chuàng)建一個(gè)文件pais.ext內(nèi)容如下authorityKeyIdentifierkeyid,issuer basicConstraintsCA:FALSE keyUsage digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName alt_names [alt_names] DNS.1 pais.internal.mycompany.com DNS.2 *.pais.internal.mycompany.com # 如果你需要通配符 # 如果有IP訪問需求務(wù)必加上IP地址 # IP.1 10.1.1.100踩坑實(shí)錄1最初我只配置了CN沒有配SAN。結(jié)果Chrome和curl都報(bào)錯(cuò)“證書缺少主題備用名稱(SAN)”。所以SAN擴(kuò)展現(xiàn)在是必須的DNS.1的值應(yīng)該和你要訪問的域名完全一致。# 3. 使用根CA簽署CSR生成最終的服務(wù)端證書 openssl x509 -req -in pais.internal.mycompany.com.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out pais.internal.mycompany.com.crt -days 365 -sha256 -extfile pais.ext參數(shù)解析-CAcreateserial: 首次簽署時(shí)創(chuàng)建序列號(hào)文件。-days 365: 服務(wù)證書有效期通常為1年需要建立續(xù)訂流程。-extfile pais.ext: 應(yīng)用我們剛才創(chuàng)建的擴(kuò)展配置文件注入SAN信息?，F(xiàn)在你得到了服務(wù)端所需的三個(gè)文件pais.internal.mycompany.com.key: 服務(wù)私鑰pais.internal.mycompany.com.crt: 服務(wù)證書由我們的私有CA簽名ca.crt: 根CA證書需要和服務(wù)器證書一起配置或單獨(dú)讓客戶端信任4. 在VCF/NSX ALB負(fù)載均衡器上配置證書這是客戶端接觸到的第一道關(guān)卡。我們以VMware NSX Advanced Load BalancerAvi為例它是VCF中常用的負(fù)載均衡解決方案。4.1 準(zhǔn)備證書文件在Avi中配置證書通常需要將私鑰和證書鏈合并成一個(gè)PEM格式的文件。證書鏈的順序是你的服務(wù)證書在前中間CA證書如果有在中間根CA證書在最后。因?yàn)槲覀冇玫氖亲越–A直接簽名所以鏈就是服務(wù)證書 根CA證書。# 將服務(wù)證書和根CA證書合并成鏈 cat pais.internal.mycompany.com.crt ca.crt pais_cert_chain.pem # 私鑰文件保持獨(dú)立或者也可以合并進(jìn)同一個(gè)文件Avi支持分開上傳 # 對(duì)于Avi通常我們上傳兩個(gè)文件包含鏈的pem文件和獨(dú)立的私鑰key文件。4.2 在NSX ALB控制器上創(chuàng)建SSL證書對(duì)象登錄到NSX ALB控制器管理界面。導(dǎo)航到模板-安全-SSL/TLS證書。點(diǎn)擊創(chuàng)建。證書類型選擇“證書”。格式選擇“PEM”。證書將pais_cert_chain.pem文件的內(nèi)容全部復(fù)制粘貼進(jìn)去。私鑰將pais.internal.mycompany.com.key文件的內(nèi)容復(fù)制粘貼進(jìn)去。為證書起一個(gè)名字例如ssl-pais-internal。點(diǎn)擊保存。踩坑實(shí)錄2粘貼證書和密鑰時(shí)務(wù)必確保格式完全正確沒有多余的空格、換行或不可見字符。特別是私鑰必須以-----BEGIN PRIVATE KEY-----開頭以-----END PRIVATE KEY-----結(jié)尾。我曾經(jīng)因?yàn)閺腤indows記事本復(fù)制粘貼導(dǎo)致格式混亂Avi校驗(yàn)失敗排查了很久。4.3 將證書綁定到虛擬服務(wù)找到負(fù)責(zé)PAIS入口流量的虛擬服務(wù)Virtual Service。編輯該虛擬服務(wù)。在SSL/TLS配置部分啟用SSL。在SSL證書下拉框中選擇你剛剛創(chuàng)建的ssl-pais-internal。SSL配置文件根據(jù)安全要求選擇例如可以使用系統(tǒng)默認(rèn)的“System-Standard”或“System-Standard-PFS”。這決定了加密套件和協(xié)議版本。保存配置。此時(shí)負(fù)載均衡器層面已經(jīng)配置完成。但如果你直接用瀏覽器訪問https://pais.internal.mycompany.com依然會(huì)看到安全警告因?yàn)槟愕碾娔X還不信任我們自建的根CAMyPrivateRootCA。5. 客戶端信任根CA證書這是讓警告消失的關(guān)鍵一步。你需要將ca.crt文件安裝到所有需要訪問PAIS服務(wù)的客戶端機(jī)器的信任根證書存儲(chǔ)區(qū)。5.1 Windows系統(tǒng)將ca.crt文件復(fù)制到Windows客戶端。雙擊ca.crt文件會(huì)打開證書查看器。點(diǎn)擊安裝證書。存儲(chǔ)位置選擇本地計(jì)算機(jī)需要管理員權(quán)限點(diǎn)擊下一步。選擇將所有的證書都放入下列存儲(chǔ)然后點(diǎn)擊瀏覽。選擇受信任的根證書頒發(fā)機(jī)構(gòu)點(diǎn)擊確定然后下一步。點(diǎn)擊完成。會(huì)彈出安全警告點(diǎn)擊“是”。安裝成功后重啟瀏覽器Chrome、Edge使用系統(tǒng)的證書存儲(chǔ)再次訪問PAIS地址警告應(yīng)該消失顯示為安全的鎖標(biāo)志。5.2 macOS系統(tǒng)將ca.crt文件復(fù)制到Mac客戶端。雙擊ca.crt文件這會(huì)打開“鑰匙串訪問”應(yīng)用。在鑰匙串訪問中確保左側(cè)選中的是“系統(tǒng)”鑰匙串需要輸入密碼。找到你剛剛導(dǎo)入的證書名稱是MyPrivateRootCA雙擊打開。在“信任”部分將“使用此證書時(shí)”設(shè)置為“始終信任”。關(guān)閉窗口輸入密碼保存更改。重啟Safari或Chrome訪問。5.3 Linux系統(tǒng) (Ubuntu/CentOS)# 將根CA證書復(fù)制到系統(tǒng)CA存儲(chǔ)目錄 sudo cp ca.crt /usr/local/share/ca-certificates/MyPrivateRootCA.crt # 注意文件擴(kuò)展名必須是 .crt # 更新CA證書存儲(chǔ) sudo update-ca-certificates # 輸出應(yīng)顯示Adding debian:MyPrivateRootCA.pem # 驗(yàn)證證書是否被添加 openssl verify /usr/local/share/ca-certificates/MyPrivateRootCA.crt # 應(yīng)輸出/usr/local/share/ca-certificates/MyPrivateRootCA.crt: OK對(duì)于使用curl、wget等命令行工具系統(tǒng)更新后即可生效。對(duì)于Firefox瀏覽器它有自己的證書存儲(chǔ)需要單獨(dú)導(dǎo)入打開Firefox設(shè)置 - 隱私與安全 - 查看證書 - 證書機(jī)構(gòu) - 導(dǎo)入選擇ca.crt文件勾選“信任由此證書頒發(fā)機(jī)構(gòu)標(biāo)識(shí)的網(wǎng)站”確定。5.4 瀏覽器與命令行工具的差異Chrome/Edge/IE依賴操作系統(tǒng)的證書存儲(chǔ)。系統(tǒng)信任了它們就信任。Firefox使用自帶的NSS證書庫需要單獨(dú)導(dǎo)入。Java應(yīng)用使用獨(dú)立的cacerts信任庫。需要將根CA證書導(dǎo)入到JRE的cacerts中使用keytool命令。Pythonrequests庫默認(rèn)使用系統(tǒng)的CA包。在Linux上配置系統(tǒng)存儲(chǔ)后通常生效。也可以手動(dòng)指定verify參數(shù)為ca.crt的路徑。Docker Client如果Docker守護(hù)進(jìn)程配置了TLS客戶端也需要信任相應(yīng)的CA證書。踩坑實(shí)錄3團(tuán)隊(duì)里一位數(shù)據(jù)分析師的Python腳本調(diào)用PAIS API失敗報(bào)SSL錯(cuò)誤。檢查后發(fā)現(xiàn)他是在Windows的Anaconda環(huán)境里運(yùn)行而Anaconda可能使用了自帶的OpenSSL庫沒有讀取系統(tǒng)證書存儲(chǔ)。解決方法是在requests請(qǐng)求中顯式指定證書路徑requests.get(url, verify‘C:\path\to\ca.crt’)。所以在復(fù)雜環(huán)境下不能假設(shè)所有客戶端都自動(dòng)繼承了系統(tǒng)信任。6. PAIS Kubernetes Ingress與內(nèi)部服務(wù)配置負(fù)載均衡器處理了外部流量但流量進(jìn)入K8s集群后還需要經(jīng)過Ingress。如果PAIS的部署包如Helm Chart要求配置TLS證書通常指的是Ingress TLS。6.1 創(chuàng)建Kubernetes TLS Secret在部署PAIS的Kubernetes命名空間中我們需要?jiǎng)?chuàng)建一個(gè)包含證書和私鑰的Secret類型為kubernetes.io/tls。# 假設(shè)你在部署PAIS的目錄下且已配置好kubectl上下文連接到TKG集群 kubectl create namespace pais-production # 創(chuàng)建TLS Secret kubectl create secret tls pais-tls-secret \ --namespacepais-production \ --certpais.internal.mycompany.com.crt \ --keypais.internal.mycompany.com.key重要這里使用的證書和私鑰必須與在負(fù)載均衡器上配置的證書是同一套。否則會(huì)出現(xiàn)“證書不匹配”的錯(cuò)誤。負(fù)載均衡器可能做SSL終止也可能做SSL透傳。如果是終止模式負(fù)載均衡器用一套證書Ingress可以用另一套甚至不用。但在我們的自簽名場景下為了簡化通常讓負(fù)載均衡器做SSL終止然后將HTTP流量轉(zhuǎn)發(fā)給Ingress。這樣Ingress就不需要配置TLS了。具體采用哪種模式需要看PAIS的部署說明和負(fù)載均衡器的配置。6.2 配置PAIS Helm Chart的Ingress TLS查看PAIS的Helm Chart的values.yaml文件通常會(huì)有Ingress相關(guān)的配置項(xiàng)ingress: enabled: true className: contour # 或 nginx取決于集群的Ingress Controller hosts: - host: pais.internal.mycompany.com paths: - path: / pathType: Prefix tls: - secretName: pais-tls-secret # 引用我們上面創(chuàng)建的Secret hosts: - pais.internal.mycompany.com在部署時(shí)通過--set參數(shù)或修改的values.yaml文件來啟用這些配置。6.3 服務(wù)網(wǎng)格如Istio的證書配置如果啟用如果PAIS部署在啟用了Istio服務(wù)網(wǎng)格的集群中并且開啟了嚴(yán)格的mTLS模式那么證書配置會(huì)更復(fù)雜一層。你需要考慮入口網(wǎng)關(guān)Istio IngressGateway證書這相當(dāng)于替代了原生的Kubernetes Ingress。你需要將證書和私鑰配置到Istio的Gateway資源中方式也是通過創(chuàng)建Secret但Secret必須放在istio-system命名空間并且遵循Istio的命名規(guī)范如istio-ingressgateway-certs。內(nèi)部服務(wù)間通信證書Istio通常會(huì)通過其citadel組件自動(dòng)為每個(gè)服務(wù)簽發(fā)和管理證書。這些證書的根CA是Istio自帶的。關(guān)鍵點(diǎn)來了如果你有集群外的客戶端如另一個(gè)傳統(tǒng)VM上的應(yīng)用需要直接調(diào)用PAIS的某個(gè)內(nèi)部服務(wù)非通過入口網(wǎng)關(guān)并且該服務(wù)啟用了mTLS那么這個(gè)外部客戶端就需要信任Istio的根CA證書。你需要從Istio中提取這個(gè)根CA證書istio-system命名空間中的istio-ca-secret并將其安裝到外部客戶端上。踩坑實(shí)錄4我們有一個(gè)位于VCF外部的監(jiān)控系統(tǒng)需要調(diào)用PAIS的某個(gè)指標(biāo)接口。PAIS集群啟用了Istio且策略為STRICT。直接調(diào)用一直失敗。后來發(fā)現(xiàn)是mTLS問題。解決方案是要么為該監(jiān)控服務(wù)創(chuàng)建一個(gè)ServiceEntry并將其納入網(wǎng)格要么在目標(biāo)服務(wù)的DestinationRule中為該監(jiān)控系統(tǒng)的IP設(shè)置一個(gè)豁免策略使用trafficPolicy.tls.mode: DISABLE但后者安全性降低。最終我們選擇了為監(jiān)控系統(tǒng)安裝Istio的根CA證書并配置客戶端證書的方式實(shí)現(xiàn)了安全的mTLS通信。7. 常見問題排查與調(diào)試技巧即使按照步驟操作你可能還是會(huì)遇到問題。下面是一個(gè)快速排查清單和調(diào)試命令。7.1 問題排查清單現(xiàn)象可能原因排查步驟瀏覽器顯示“不是私密連接”1. 根CA證書未安裝到客戶端。2. 證書域名不匹配SAN配置錯(cuò)誤。3. 證書已過期。1. 檢查客戶端證書存儲(chǔ)。2. 用openssl x509 -in cert.crt -text -noout查看證書詳情核對(duì)SAN和有效期。3. 檢查瀏覽器錯(cuò)誤代碼如NET::ERR_CERT_AUTHORITY_INVALID。curl報(bào)錯(cuò) “SSL certificate problem: self signed certificate”客戶端不信任自簽名CA。使用curl --cacert /path/to/ca.crt https://...指定CA證書。如果成功證明是信任問題。curl報(bào)錯(cuò) “SSL certificate problem: certificate has expired”證書過期。檢查證書有效期openssl x509 -in cert.crt -enddate -nooutcurl報(bào)錯(cuò) “SSL certificate problem: unable to get local issuer certificate”證書鏈不完整。服務(wù)器沒有發(fā)送完整的證書鏈缺少中間CA或根CA。1. 用openssl s_client -connect host:port -showcerts查看服務(wù)器發(fā)送的完整鏈。2. 確保負(fù)載均衡器或服務(wù)器配置中包含了完整的證書鏈。訪問負(fù)載均衡器VIP正常但訪問Ingress域名報(bào)錯(cuò)1. DNS解析問題。2. 負(fù)載均衡器到Ingress Controller的健康檢查或路由配置錯(cuò)誤。3. Ingress Controller未正確配置TLS或后端服務(wù)不可用。1.nslookup pais.internal.mycompany.com。2. 檢查負(fù)載均衡器虛擬服務(wù)的池Pool成員狀態(tài)和健康檢查。3. 檢查K8s Ingress資源狀態(tài)kubectl describe ingress name。4. 檢查Ingress Controller Pod日志。部分客戶端正常部分報(bào)錯(cuò)1. 客戶端系統(tǒng)/瀏覽器證書存儲(chǔ)未同步更新。2. 客戶端應(yīng)用如Java、Python使用了獨(dú)立的信任庫。3. 客戶端有代理或防火墻攔截導(dǎo)致證書驗(yàn)證行為不同。1. 確認(rèn)報(bào)錯(cuò)客戶端已正確安裝根CA證書并重啟了應(yīng)用。2. 檢查特定應(yīng)用的信任庫配置如Java的-Djavax.net.ssl.trustStore。3. 在報(bào)錯(cuò)客戶端上用openssl s_client進(jìn)行測試對(duì)比與正?？蛻舳说妮敵霾町?。7.2 必備調(diào)試命令檢查證書詳細(xì)信息openssl x509 -in pais.internal.mycompany.com.crt -text -noout重點(diǎn)關(guān)注Subject尤其是CNIssuerValidity起止時(shí)間以及最重要的X509v3 Subject Alternative Name部分。模擬客戶端連接查看服務(wù)器發(fā)送的證書鏈openssl s_client -connect pais.internal.mycompany.com:443 -showcerts這個(gè)命令會(huì)打印出建立TLS連接的全過程包括服務(wù)器返回的所有證書。你可以看到證書鏈?zhǔn)欠裢暾约敖K端實(shí)體證書的SAN信息。驗(yàn)證證書鏈和信任# 使用系統(tǒng)CA存儲(chǔ)驗(yàn)證 openssl verify pais.internal.mycompany.com.crt # 使用指定的CA證書驗(yàn)證 openssl verify -CAfile ca.crt pais.internal.mycompany.com.crt檢查Kubernetes Secret內(nèi)容kubectl get secret pais-tls-secret -n pais-production -o yaml # 證書和密鑰是Base64編碼的可以解碼查看 kubectl get secret pais-tls-secret -n pais-production -o jsonpath{.data.tls\.crt} | base64 -d | openssl x509 -text -noout kubectl get secret pais-tls-secret -n pais-production -o jsonpath{.data.tls\.key} | base64 -d | openssl rsa -check -noout7.3 證書過期監(jiān)控與續(xù)訂自簽名證書最大的運(yùn)維負(fù)擔(dān)就是續(xù)訂。證書過期會(huì)導(dǎo)致服務(wù)突然中斷且錯(cuò)誤不明顯。記錄有效期將證書的過期日期記錄到日歷或監(jiān)控系統(tǒng)中。自動(dòng)化續(xù)訂腳本編寫腳本自動(dòng)化證書續(xù)訂流程包括生成新CSR、用CA簽名、更新負(fù)載均衡器和K8s Secret。關(guān)鍵步驟更新Secret后需要重啟相關(guān)的Pod如Ingress Controller Pod以加載新證書?？梢酝ㄟ^給Pod添加注解如kubectl annotate pod pod-name date$(date)來觸發(fā)滾動(dòng)更新。使用證書管理工具對(duì)于更復(fù)雜的環(huán)境可以考慮使用cert-manager這樣的Kubernetes原生證書管理工具。它可以集成私有CA如step-ca自動(dòng)為Ingress等資源簽發(fā)和輪換證書大大減輕管理壓力。雖然初始設(shè)置復(fù)雜但長期來看是更優(yōu)解。整個(gè)配置過程從原理到實(shí)操最深的體會(huì)就是“細(xì)節(jié)決定成敗”。一個(gè)SAN字段的缺失、一個(gè)證書鏈的不完整、一個(gè)客戶端信任庫的遺漏都可能導(dǎo)致連接失敗。尤其是在VCF和PAIS這種多層級(jí)的云原生環(huán)境里清晰地理解流量路徑和每一層的安全邊界是成功配置自簽名TLS證書的關(guān)鍵。建議在正式部署前先在一個(gè)簡單的測試環(huán)境中走通全流程記錄下每一步的命令和配置形成屬于你們團(tuán)隊(duì)的標(biāo)準(zhǔn)化操作手冊(cè)這會(huì)為后續(xù)的運(yùn)維和問題排查帶來極大的便利。