Embedded System Security Live看到這個標題先別急著把它翻譯成“嵌入式系統(tǒng)安全現(xiàn)場直播”。做設(shè)備安全的人應(yīng)該都有過這種體會真正讓你頭疼的不是買一套安全方案裝上就完事而是設(shè)備在真實環(huán)境里跑著跑著突然有一天跟你鬧脾氣——啟動驗證掛了、USB設(shè)備被策略攔死、CA證書裝不上、數(shù)據(jù)庫視圖又報權(quán)限錯誤。我在最近一次給開發(fā)板做安全加固時一天之內(nèi)把這四類問題挨個遇了一遍從華碩主板開機直接進恢復(fù)界面到調(diào)試器插上電腦彈“當前安全策略已阻止此USB設(shè)備”再到給Android模擬器 push 證書被 read-only 攔下。這篇文章就順著這四個現(xiàn)場講把嵌入式系統(tǒng)安全最核心的四層問題——安全啟動、運行時訪問控制、證書信任鏈、權(quán)限模型——一次講透。適合正在做嵌入式開發(fā)、物聯(lián)網(wǎng)設(shè)備研發(fā)的工程師也適合剛轉(zhuǎn)安全方向、想搞懂“設(shè)備安全到底在防什么”的讀者。1. 嵌入式安全不是“裝個鎖”從一次真機調(diào)試說起1.1 安全事故的“遲到效應(yīng)”做嵌入式系統(tǒng)安全的第一步是接受一個反直覺的事實大部分安全問題不會在你上線那天暴露。設(shè)備可能已經(jīng)在產(chǎn)線上穩(wěn)定跑了半年突然某天因為一次證書過期、一次OTA更新把信任庫刷壞、或者某個安全Agent進程靜默退出問題才真正浮出水面。這種“遲到效應(yīng)”特別容易讓人誤判因為設(shè)備平時看起來一切正常你以為安全配置是生效的實際上它可能在你不知道的時候已經(jīng)悄悄失效了。我在實際調(diào)試中越來越覺得“安全”不是一個靜態(tài)快照不是一個“開啟/關(guān)閉”的開關(guān)。Secure Boot 開著不代表信任鏈上的每個組件都被正確校驗過USB策略配了不代表每個接口都按新策略執(zhí)行證書裝進系統(tǒng)了不代表上層應(yīng)用真的走了系統(tǒng)信任庫的校驗。安全狀態(tài)會漂移這是嵌入式設(shè)備運維里最隱蔽的風險也是我強調(diào)“Live”這個視角的原因——安全不是一個瞬間動作而是在設(shè)備持續(xù)運行過程中不斷被驗證、不斷被維護的動態(tài)過程。1.2 一天之內(nèi)的四次“安全翻車”現(xiàn)場為了把問題講具體我直接復(fù)盤我那次調(diào)試過程。設(shè)備是一塊跑Linux的開發(fā)板配套一臺Windows宿主機外加一個Android模擬器做聯(lián)動測試。一天之內(nèi)我先后遇到四個故障宿主機開機直接進恢復(fù)界面提示“啟動策略變更”Secure Boot 顯示開啟但進不了系統(tǒng)把調(diào)試器插到電腦上Windows 直接彈窗“當前安全策略已阻止此USB設(shè)備”想給 Android 模擬器裝一個自簽 CA 證書用于調(diào)試adb push 到/system/etc/security/cacerts時報 read-only導(dǎo)數(shù)據(jù)庫視圖時報了SQL SECURITY DEFINER相關(guān)錯誤顯示definer賬戶不存在。這四個故障表面看毫不相關(guān)一個是 BIOS/UEFI 層一個是系統(tǒng)外設(shè)層一個是證書信任層一個是數(shù)據(jù)庫權(quán)限層。但它們背后的邏輯是同一件事——信任與權(quán)限。設(shè)備是否允許這段代碼運行、是否允許這個設(shè)備接入、是否允許這個證書通過、是否允許這個賬戶執(zhí)行操作本質(zhì)都是“你的身份是否被當前安全模型接受”。想通了這條主線排查思路一下就清晰了。1.3 一條主線啟動鏈、運行時、證書、應(yīng)用層權(quán)限順著這條“信任與權(quán)限”的主線我把嵌入式系統(tǒng)安全分成了四個層次。設(shè)備上電后的第一件事是啟動鏈校驗由 BootROM、Bootloader、內(nèi)核逐級驗證簽名這是整個信任體系的地基系統(tǒng)跑起來之后運行時訪問控制接管 USB、外設(shè)、文件系統(tǒng)等資源的使用權(quán)限再往上設(shè)備與云端、設(shè)備與調(diào)試工具之間的通信依賴證書信任鏈來保證彼此身份可信最后應(yīng)用和數(shù)據(jù)層的權(quán)限模型決定了一個進程、一個賬戶能對資源做什么操作。這四層不是孤立存在而是層層遞進的。啟動鏈一旦失守后面的所有安全機制都可以被繞過運行時訪問控制如果配置錯誤會讓合法調(diào)試工具也無法使用證書信任鏈如果斷了設(shè)備會變成“誰也不信”或者“誰都信”兩個極端權(quán)限模型如果設(shè)計混亂應(yīng)用層就會出現(xiàn)各種“允許了但執(zhí)行不了”“執(zhí)行得了但權(quán)限過大”的怪問題。后面的內(nèi)容我就按這四層逐個拆開講。2. Secure Boot 與信任根為什么“開了安全啟動”還是進不了系統(tǒng)2.1 華碩主板開機失敗Secure Boot 的 Enabled 狀態(tài)為什么不可信先說我那個最直接的教訓。機器是一塊華碩主板BIOS 里 Secure Boot Control 明明是 EnabledWindows 也裝得好好的但某天早上開機直接進了恢復(fù)界面提示“啟動策略變更系統(tǒng)無法正常啟動”。當時第一反應(yīng)是系統(tǒng)壞了后來才發(fā)現(xiàn)問題出在 Secure Boot 的信任庫上。Secure Boot 的核心機制是用一組密鑰和簽名數(shù)據(jù)庫來約束啟動過程Platform KeyPK是所有權(quán)的根相當于你給大樓配的總鑰匙Key Exchange KeyKEK負責管理簽名數(shù)據(jù)庫的更新相當于物業(yè)手里的鑰匙串DB 是白名單記錄允許啟動的引導(dǎo)程序簽名DBX 是黑名單記錄已知惡意或已撤銷的簽名。計算機啟動時固件會逐級驗證引導(dǎo)程序簽名是否在 DB 白名單里、是否不在 DBX 黑名單里校驗通過才放行。而問題恰恰出在“數(shù)據(jù)庫更新”環(huán)節(jié)。華碩主板把 Secure Boot 分成 Standard 和 Custom 兩種模式Standard 模式由廠家維護默認密鑰Custom 模式允許用戶自定義 PK/KEK/DB。我雖然在 BIOS 里開著 Secure Boot但之前為了調(diào)試一個老系統(tǒng)把模式切到了 Custom并替換了 Platform Key。系統(tǒng)更新時Windows 會嘗試更新 DB/DBX 數(shù)據(jù)庫但在 Custom 模式下新數(shù)據(jù)庫的更新請求需要用正確的 KEK 簽名而我沒有同步更新 KEK導(dǎo)致本地引導(dǎo)程序的簽名不在當前信任列表里。最終結(jié)果是Secure Boot 狀態(tài)顯示 Enabled但信任鏈其實已經(jīng)斷裂系統(tǒng)自然進不去。組件作用類比PKPlatform Key所有權(quán)的根控制 KEK 的更新大樓總鑰匙KEKKey Exchange Key管理簽名數(shù)據(jù)庫更新物業(yè)鑰匙串DB允許啟動的簽名白名單員工門禁名單DBX禁止啟動的簽名黑名單黑名單通緝令這次事故讓我徹底明白Secure Boot 的“Enabled”只是一個狀態(tài)標志它只說明“這個功能在運行”不代表“信任鏈是完整的”。你換了 PK卻沒同步 KEK 和數(shù)據(jù)庫系統(tǒng)照樣進不去。很多嵌入式工程師遇到類似問題第一反應(yīng)是關(guān)掉 Secure Boot 省事但這不是解決問題的辦法正確做法是把密鑰管理納入系統(tǒng)更新的整體流程保證平臺密鑰、交換密鑰、簽名數(shù)據(jù)庫三者始終同步。2.2 嵌入式設(shè)備里的引導(dǎo)驗證U-Boot、TF-A 與 AVB 的實際鏈路PC 上的 Secure Boot 是 UEFI 那一套嵌入式設(shè)備則更復(fù)雜但也更貼近“從零構(gòu)建信任鏈”。以我調(diào)試的這塊開發(fā)板為例用的是常見的 ARM 啟動流程BootROM 固化在芯片內(nèi)部最先執(zhí)行接著是 TF-ATrusted Firmware-A的 BL1、BL2、BL31負責初始化內(nèi)存、加載 EL3 運行時環(huán)境再往后是 U-Boot作為主流引導(dǎo)加載程序加載內(nèi)核和設(shè)備樹如果運行 Android 或需要 AVBAndroid Verified Boot還會多一層 vbmeta 分區(qū)驗證。每一步都需要校驗下一級鏡像的簽名。BootROM 里燒錄了根公鑰BL1 的鏡像簽名由它驗證BL2 加載 BL31 和 BL33U-Boot時用 bootchain 里的密鑰做驗簽U-Boot 加載 kernel 時可以啟用 verified boot 機制要求內(nèi)核鏡像和 DTB 必須是經(jīng)過簽名的 fitImage。這個鏈條只要有一個環(huán)節(jié)沒有驗簽或者簽名密鑰被換掉后面的代碼就可能被替換成惡意版本。我在實際配置 U-Boot 時最常踩的坑是CONFIG_CMD_AVB和CONFIG_ANDROID_AB這些宏沒有正確組合導(dǎo)致 vbmeta 校驗沒有生效或者簽名鏡像和未簽名鏡像混用調(diào)試時把未簽名的內(nèi)核刷進去也啟動了看起來“沒問題”其實整個簽名鏈已經(jīng)失效。嵌入式設(shè)備不像 PC 有成熟的系統(tǒng)更新機制很多團隊把 Secure Boot 開起來就不再管了結(jié)果幾個月后要升級固件發(fā)現(xiàn)新鏡像沒有簽名又要重新燒 Bootloader。2.3 密鑰管理才是大頭開發(fā)密鑰、生產(chǎn)密鑰與回滾保護把 Secure Boot 真正用起來的難點不是開啟功能而是把密鑰生命周期管理好。第一次做簽名方案的工程師很容易陷入一個誤區(qū)拿開發(fā)期間的測試密鑰當生產(chǎn)密鑰或者所有人共用一把簽名私鑰。這樣的結(jié)果就是私鑰泄露后沒有任何補救手段因為一個密鑰被用來簽了所有的鏡像撤銷就等于整個系統(tǒng)重建。我建議從一開始就做密鑰分離。至少分成兩級平臺密鑰和應(yīng)用密鑰。平臺密鑰用于 BootROM 至 U-Boot 的基礎(chǔ)鏈路應(yīng)用密鑰用于內(nèi)核、設(shè)備樹、文件系統(tǒng)等更上層的鏡像。私鑰存放在 HSM 或芯片的 OTP 區(qū)域里生產(chǎn)環(huán)境不要讓它出現(xiàn)在開發(fā)機上開發(fā)機使用的測試密鑰和生產(chǎn)密鑰嚴格區(qū)分即使測試私鑰泄露也不影響生產(chǎn)設(shè)備。回滾保護同樣不能少RPMB 或 TPM NV 里維護一個回滾計數(shù)器每次升級把版本號遞增舊版本鏡像即使簽名有效也會被拒絕加載防止攻擊者把系統(tǒng)降級到存在已知漏洞的版本。實際踩坑后的體會是密鑰管理和更新機制最好在設(shè)備量產(chǎn)前就定義清楚否則后面補會非常痛苦。比如有些團隊在產(chǎn)品發(fā)出去一兩年后才想加簽名驗證卻發(fā)現(xiàn)還需要 OTA 升級 Bootloader而沒有可信升級通道于是只能依賴產(chǎn)線返廠或現(xiàn)場刷機成本高得驚人。2.4 怎么確認安全啟動真的在干活正面測試與負面測試調(diào)試完了 Secure Boot我最想分享的一點是不要只看狀態(tài)位一定要做“正反兩向測試”來確認簽名驗證真的在攔截。正面測試很簡單用已簽名的完整鏡像執(zhí)行一次正常啟動觀察啟動日志中是否出現(xiàn)類似 “Verification passed” 或 “Signature OK” 的字段。每個 Bootloader 的日志位置不一樣但基本都會在加載下一級鏡像時打印驗證結(jié)果。負面測試才是關(guān)鍵。把內(nèi)核鏡像里的一個字節(jié)改掉或者直接用未簽名鏡像重新打包然后嘗試啟動。如果 Secure Boot 生效啟動流程必須被卡住報簽名校驗失敗如果設(shè)備照樣跑起來說明驗證路徑根本沒接通。做過負面測試之后你會對自己的信任鏈有信心得多。很多年前我們調(diào)試一個新平臺所有人以為簽了名結(jié)果發(fā)現(xiàn) BootROM 里的公鑰哈希和實際密鑰不匹配負面測試直接暴露了問題如果沒做這一步設(shè)備到用戶手里過幾天就可能在某個更新后被刷成磚。3. 運行時訪問控制USB設(shè)備被安全策略攔下的完整排查鏈路3.1 插上調(diào)試器就被攔“當前安全策略已阻止此USB設(shè)備”的現(xiàn)場調(diào)試器插上電腦第一時間不是滴一聲然后出現(xiàn)在設(shè)備管理器里而是彈出一個“USB device has been blocked by the current security policy”的提示。設(shè)備管理器里翻半天也看不到新設(shè)備或者看到了也是黃色感嘆號錯誤代碼指向策略攔截。說實話第一次遇到這個問題我愣了一下因為這只調(diào)試器在另一臺機器上插得好好的沒有任何硬件故障跡象。這種攔截大多數(shù)時候并不是設(shè)備壞了而是當前操作系統(tǒng)或管理策略環(huán)境不允許這個 USB 設(shè)備接入。安全策略為什么要管 USB因為 USB 是物理攻擊和數(shù)據(jù)泄露最常見的入口一個惡意 USB 設(shè)備可以被識別成鍵盤輸入指令一個 U 盤可以把內(nèi)部資料拷走。為了控制風險系統(tǒng)從設(shè)備安裝、存儲訪問、設(shè)備類型等好幾個層面都設(shè)置了檢查點任何一個不滿足設(shè)備就會被攔在門外。3.2 三層攔截機制設(shè)備安裝策略、USB存儲隔離與設(shè)備自身策略我排查時會把 USB 被攔的問題分成三個層次來定位。第一層是 Windows 的設(shè)備安裝限制Device Installation Restrictions。這是企業(yè) IT 最常用的策略通過組策略或 MDM 統(tǒng)一下發(fā)可以精確控制允許安裝的硬件 ID、設(shè)備類或設(shè)備實例路徑。如果你插入的調(diào)試器不在允許列表里或者策略配置成“阻止安裝其他策略未描述的設(shè)備”那么系統(tǒng)直接拒絕安裝驅(qū)動設(shè)備自然無法工作。第二層是 USB 存儲隔離。很多公司的安全策略會限制可移動存儲設(shè)備例如禁止寫入 U 盤、禁止掛載未知設(shè)備。這個策略的目的當然是防數(shù)據(jù)泄露但它經(jīng)常誤傷調(diào)試器、TAP 設(shè)備、串口轉(zhuǎn)換器這類雖然長得像外設(shè)但不是存儲設(shè)備的東西。還有一個隱蔽點某些策略會檢查設(shè)備的接口類型如果你的調(diào)試器恰好實現(xiàn)了大容量存儲接口可能被當成 U 盤處理。第三層是設(shè)備自身的安全設(shè)置。嵌入式設(shè)備或 Android 設(shè)備往往有自己的訪問控制例如 Android 的 USB 調(diào)試需要開發(fā)者選項確認指紋某些鎖定 Bootloader 的設(shè)備還會校驗 USB 連接是否來自可信主機。在一些軍工、電力等對安全要求很高的場景設(shè)備會直接限制 USB 配置接口任何未授權(quán)的 USB 操作都會被拒絕。熱搜詞里那個 “this action is not allowed with this security level configuration” 的提示我在設(shè)備端也遇到過意思就是當前安全級別不允許這個操作通常需要先提升權(quán)限或切換安全配置文件。3.3 完整排查鏈路從事件日志到組策略結(jié)果集遇到 USB 被攔不要急著改策略先按下面的鏈路排查。第一步確認攔截發(fā)生在主機側(cè)還是設(shè)備側(cè)。最簡單的辦法是把同一個設(shè)備換到一臺沒有任何管控策略的干凈電腦上試一次。如果干電腦能正常識別問題基本在主機側(cè)如果干電腦也報錯那更可能是設(shè)備自身的問題。第二步如果是主機側(cè)問題在 Windows 上查看組策略結(jié)果集。運行g(shù)presult /h report.html生成 HTML 報告后搜索“設(shè)備安裝”相關(guān)策略重點看是否啟用了“設(shè)備安裝限制”或“阻止其他策略未描述的設(shè)備”。有時候策略來自本地組策略有時候來自域或 MDM 平臺來源不同處理方式也不同。第三步打開事件查看器定位到設(shè)備安裝相關(guān)日志。Windows 在阻止設(shè)備安裝時會記錄設(shè)備安裝事件里面包含被阻止設(shè)備的硬件 ID 和攔截理由。拿到硬件 ID 之后去設(shè)備安裝限制策略里比對確認這個設(shè)備是否在白名單范圍。第四步制定最小化放行方案。如果被攔的是合法調(diào)試工具可以精確放行該設(shè)備的硬件 ID 或者設(shè)備實例路徑而不是把整個設(shè)備安裝限制關(guān)掉。舉個例子如果策略阻止了“其他設(shè)備”你可以單獨添加一條允許規(guī)則用VID_xxxxPID_yyyy指定這只調(diào)試器。我見過有人圖省事直接把“設(shè)備安裝限制”策略停用結(jié)果一個同事把私人的 USB 攝像頭帶進公司第二天安全部門就找上門了。正確的做法永遠是開一個“只允許特定設(shè)備”的窗口而不是把整面墻拆掉。3.4 文件安全權(quán)限的姊妹坑“could not set file security for file”與“wrong security type”同樣屬于運行時訪問控制的還有一個高頻問題就是往設(shè)備復(fù)制文件或給服務(wù)安裝目錄設(shè)置權(quán)限時報 “could not set file security for file”。我第一次遇到這個報錯是在給一塊開發(fā)板的 FAT 分區(qū)寫配置時Windows 報無法設(shè)置文件安全屬性。查了一圈發(fā)現(xiàn)FAT32/exFAT 這類文件系統(tǒng)根本上不支持 Windows 的 ACL 安全描述符系統(tǒng)想往文件上寫權(quán)限規(guī)則文件系統(tǒng)根本不認。NTFS 下用得好好的 ACL到 FAT 分區(qū)上就成了“無效安全類型”。這個報錯和“wrong security type”是姊妹問題。簡單來說安全類型不匹配指你嘗試應(yīng)用的安全主體在目標系統(tǒng)上無法被識別。好比你把一串印著某個制服標識的鑰匙帶到另一個大門口門禁系統(tǒng)里根本沒有這個標識的登記信息它自然不知道該怎么處理你的權(quán)限申請。排查思路很直接先看目標文件系統(tǒng)支不支持 ACL再看目標系統(tǒng)里是否存在當前 SID 或用戶名的映射。嵌入式設(shè)備上尤其常見因為很多設(shè)備分區(qū)采用非 NTFS 格式或者使用獨立的用戶體系和 Windows 的 SID 完全映射不上。解決方案分幾種如果只是為了在宿主機和設(shè)備之間傳文件把目標分區(qū)換成支持 ACL 的文件系統(tǒng)或者干脆通過 adb/scp 等工具傳文件不走 Windows 文件共享如果必須在設(shè)備上設(shè)置權(quán)限要使用設(shè)備自身的用戶體系和權(quán)限命令而不是在宿主機側(cè)設(shè)置安全屬性。嵌入式設(shè)備上很多權(quán)限管理必須“到現(xiàn)場做”跨系統(tǒng)的安全描述符千成不能直接搬。4. 證書信任鏈裝個CA證書怎么就撞上了read-only文件系統(tǒng)4.1 用 adb 裝證書被 read-only 擋下的那一刻調(diào)試設(shè)備 HTTPS 流量時最常用的操作是給測試設(shè)備裝一個自簽 CA 證書讓設(shè)備信任代理服務(wù)器的證書這樣才能抓到加密包內(nèi)容。我那次在 Android 模擬器上執(zhí)行adb push my-ca.crt /system/etc/security/cacerts/結(jié)果直接報 “remote couldnt create file: read-only”也就是熱搜里那條mumu adb /system/etc/security/cacerts remote couldnt create file: read-only的完整場景。第一反應(yīng)是權(quán)限不夠于是adb root再試一次還是 read-only。這時候才反應(yīng)過來問題不是權(quán)限而是這個分區(qū)本身就是只讀掛載。Android 系統(tǒng)證書目錄在/system/etc/security/cacerts/system分區(qū)在生產(chǎn)鏡像里默認以只讀方式掛載這不是為了防止你裝證書而是為了保護系統(tǒng)完整性。如果任何進程都能往系統(tǒng)目錄里寫文件那惡意軟件也能把自己的惡意 CA 證書塞進去之后所有 TLS 流量都能被它劫持。所以系統(tǒng)鏡像的只讀屬性本身就是一條安全邊界。4.2 Android 證書存儲機制的兩次收緊從用戶證書到 APEX很多老工程師習慣用老辦法先拿到 root然后 remount 系統(tǒng)分區(qū)把證書 push 進去重啟生效。這套流程在 Android 9 之前還行得通但 Android 系統(tǒng)的證書存儲機制已經(jīng)收得非常緊。用戶證書和系統(tǒng)證書是兩回事。通過設(shè)置里的“安裝證書”裝進去的證書屬于用戶證書存儲只能被一部分應(yīng)用信任很多應(yīng)用為了安全默認不信任用戶 CA。系統(tǒng)證書存儲位于/system/etc/security/cacerts全系統(tǒng)進程都信任所以抓包工具都希望把證書裝到這里。Android 14 之后系統(tǒng) CA 證書被進一步收進了com.android.conscrypt這個 APEXAndroid Package EXtension模塊。APEX 本身是一個只讀的、經(jīng)過簽名的系統(tǒng)組件包即使你adb root后 remount 成功看到的/system/etc/security/cacerts也是一個由 APEX 管理、運行時可重置的內(nèi)容直接往里寫文件并不能穩(wěn)定生效。在模擬器上調(diào)試比較可靠的做法是啟動時加-writable-system參數(shù)讓模擬器以可寫系統(tǒng)模式運行再配合adb root和adb remount來修改證書目錄。在自有測試設(shè)備上最簡單且合法的路徑是把證書安裝為“用戶證書”然后在應(yīng)用的網(wǎng)絡(luò)安全配置里手動信任該用戶證書。雖然不如系統(tǒng)證書徹底但已驗證場景足夠用。需要強調(diào)的是以上操作只適用于開發(fā)者自有測試設(shè)備生產(chǎn)環(huán)境中的設(shè)備證書必須通過工廠預(yù)置或正式的 OTA 更新機制絕不能在運行現(xiàn)場用 root 硬塞證書那會徹底破壞設(shè)備的信任體系。4.3 設(shè)備端與云端信任驗證別在兩端偷懶證書信任鏈的問題不只出現(xiàn)在“往設(shè)備里裝證書”這一步。設(shè)備作為客戶端去訪問云端時同樣需要校驗服務(wù)端證書。我在不少項目里看到過這樣的代碼為了省事把 TLS 證書校驗直接關(guān)掉或者設(shè)置一個“信任所有證書”的 SSLContext。開發(fā)階段這么干可以理解但如果帶著這個開關(guān)上生產(chǎn)等于讓設(shè)備裸奔——中間人輕輕松松就能把設(shè)備到云端的流量截走改指令、換固件、盜數(shù)據(jù)為所欲為。設(shè)備端校驗證書我建議要么走系統(tǒng) CA 庫讓設(shè)備信任常見 CA 鏈同時一定要校驗主機名hostname防止證書鏈雖然有效但簽給了另一個域名要么對特定的服務(wù)端證書做固定公鑰校驗pinning把預(yù)期公鑰直接內(nèi)置到固件里。前者維護成本低但依賴 CA 體系的安全后者對公共服務(wù)器的證書輪換比較敏感需要提前設(shè)計好證書更新方案。兩種方式都要配套時間同步因為證書有效期驗證依賴設(shè)備當前時間很多設(shè)備 RTC 電池沒電或者從未做過 NTP 同步結(jié)果證書明明沒過期設(shè)備卻一直報“證書無效”。4.4 證書排查三步法設(shè)備信任庫、應(yīng)用加載路徑、時間同步證書類問題排查我總結(jié)了一個三層檢查法