簡介這是一份面向Java開發(fā)者的PGP加密與數(shù)字簽名實戰(zhàn)Demo資源適用于需要在HTTP通信中集成端到端安全機(jī)制的中高級工程師尤其適合處理敏感數(shù)據(jù)傳輸、合規(guī)性驗簽如金融、政務(wù)接口等場景。資源包含兩個完整可運(yùn)行項目一個專注PGP密鑰生成、文件加解密與簽名驗簽全流程實現(xiàn)另一個則基于HttpClient封裝PGP加密后的內(nèi)容發(fā)送邏輯并預(yù)留OkHttp替換接口支持?jǐn)y帶CA證書的HTTPS安全投遞。壓縮包共42個文件涵蓋13個核心Bouncy Castle加密庫jar包、8個關(guān)鍵Java源碼、2個密鑰文件public.key/private.key、2個ASCII格式公鑰證書.asc以及項目配置類文件整體11.75MB結(jié)構(gòu)清晰、依賴明確開箱即用。目前已有1028人學(xué)習(xí)下載讀者可直接復(fù)用加解密工具類、理解PGP與SSL/TLS協(xié)同工作模式并獲得真實環(huán)境下的證書集成參考方案。1. 這不是“加個密就完事”的玩具JAVA-PGP加密驗簽完整Demo專治HTTP通信中「數(shù)據(jù)被篡改卻渾然不覺」的玄學(xué)翻車你有沒有遇到過這種場景用 HttpClient 調(diào)第三方 API傳的是 JSON對方說“你發(fā)的簽名不對”你查日志發(fā)現(xiàn)請求體明文是對的但對方驗簽失敗或者更糟——某天突然發(fā)現(xiàn)生產(chǎn)環(huán)境里一批訂單金額被中間人悄悄改了兩位小數(shù)而你的 HTTPS SSL 看起來明明牢不可破別急著罵運(yùn)維或懷疑證書鏈PGPPretty Good Privacy層的端到端加密驗簽才是 HTTP 協(xié)議之上真正兜底的數(shù)據(jù)完整性與身份可信性防線。這個JAVA-PGP加密驗簽完整Demo.rar不是教科書示例它是一套可直接嵌入 Spring Boot 微服務(wù)、兼容 JDK 8–17、帶完整密鑰生成→消息簽名→密文傳輸→服務(wù)端解密→驗簽全流程的實戰(zhàn)包。它解決的不是“能不能加密”而是“怎么讓簽名在 HttpClient 的 RequestBody 流式寫入、GZIP 壓縮、代理轉(zhuǎn)發(fā)、Nginx 緩存等真實鏈路中依然穩(wěn)如磐石”。適合正在做金融級接口對接、政務(wù)系統(tǒng)數(shù)據(jù)交換、或被甲方反復(fù)要求提供“不可抵賴性證明”的 Java 后端工程師。2. PGP 在 Java 生態(tài)里為什么選 Bouncy Castle 而不是原生 JCE2.1 為什么 JDK 自帶的 JCE 不足以支撐生產(chǎn)級 PGP 驗簽Java 原生安全庫JCE只提供基礎(chǔ)的對稱/非對稱算法如 AES、RSA但PGP 是一套協(xié)議規(guī)范不是單一算法它包含密鑰環(huán)KeyRing管理、OpenPGP 消息封裝格式RFC 4880、壓縮ZIP/ZLIB、對稱加密CAST5/AES、公鑰加密RSA/ElGamal、數(shù)字簽名DSA/ECDSA、以及最關(guān)鍵的——子包嵌套結(jié)構(gòu)Signature Subpackets和簽名時間戳綁定機(jī)制。JCE 沒有PGPSignatureGenerator、PGPEncryptedDataGenerator這類高層抽象你得自己拼接二進(jìn)制頭、計算 SHA-1/SHA256 摘要、手動處理 MPIMultiple Precision Integer編碼……這在 HTTP 場景下極易因字節(jié)序、填充方式、摘要截斷長度不一致導(dǎo)致驗簽失敗。某跨平臺系統(tǒng)曾因此在灰度期連續(xù)三天驗簽失敗率 37%最后發(fā)現(xiàn)是 JDK 11 的MessageDigest默認(rèn)輸出字節(jié)數(shù)組順序與 OpenPGP 規(guī)范要求的“大端網(wǎng)絡(luò)序”不一致而 Bouncy Castle 內(nèi)部已做標(biāo)準(zhǔn)化處理。2.2 Bouncy Castle 的三個不可替代能力Bouncy CastleBC是 Java 生態(tài)中唯一被廣泛驗證、持續(xù)維護(hù)、且完全遵循 RFC 4880 的 OpenPGP 實現(xiàn)。它的核心價值不在“能用”而在“能穩(wěn)用”密鑰環(huán)原子操作PGPSecretKeyRing和PGPPublicKeyRing支持從文件/流/字節(jié)數(shù)組加載并自動解析子密鑰Subkey、用戶IDUserID、簽名認(rèn)證Self-Signature、密鑰過期時間等元數(shù)據(jù)。HTTP 客戶端調(diào)用時可按userIdapipartner.com動態(tài)匹配對應(yīng)密鑰而非硬編碼 keyId。流式加解密支持PGPCompressedDataGeneratorPGPEncryptedDataGenerator可直接包裝HttpEntity#getContent()返回的InputStream避免將整個報文加載進(jìn)內(nèi)存——這對 10MB 的 PDF 報表附件傳輸至關(guān)重要。簽名時間戳強(qiáng)綁定BC 的PGPSignatureGenerator允許顯式注入SignatureSubpacket例如強(qiáng)制添加Signature Creation Time和Issuer Fingerprint服務(wù)端驗簽時可校驗“簽名是否在密鑰有效期內(nèi)生成”杜絕用已吊銷密鑰偽造舊簽名。提示本 Demo 使用 BC 1.70 版本2023 年后發(fā)布已修復(fù) JDK 17 下SecureRandom初始化阻塞問題。若你項目仍用 BC 1.60 以下請務(wù)必升級否則在容器化部署時可能因/dev/random耗盡導(dǎo)致線程卡死。2.3 如何在 Spring Boot 項目中無侵入集成不是簡單加個bcprov-jdk15on.jar就完事。BC 需注冊為安全提供者Security Provider且必須在SpringApplication.run()之前完成否則RestTemplate或WebClient初始化時會跳過 BC 提供的算法。本 Demo 采用SpringApplicationRunListener方式在prepareEnvironment()階段注入// src/main/java/com/demo/config/BouncyCastleRegistrar.java public class BouncyCastleRegistrar implements SpringApplicationRunListener { public BouncyCastleRegistrar(SpringApplication application, String[] args) {} Override public void starting(ConfigurableBootstrapContext bootstrapContext) { // 必須在 Security 初始化前注冊否則部分算法不可見 if (Security.getProvider(BC) null) { Security.insertProviderAt(new BouncyCastleProvider(), 1); } } }并在META-INF/spring.factories中聲明org.springframework.boot.SpringApplicationRunListener\ com.demo.config.BouncyCastleRegistrar這樣做的好處是所有后續(xù)創(chuàng)建的HttpClient、RestTemplate、甚至KeyStore.getInstance(PKCS12)都能無縫使用 BC 提供的增強(qiáng)算法無需修改任何業(yè)務(wù)代碼。3. HttpClient 與 PGP 的三重握手如何把簽名消息塞進(jìn) HTTP Body 而不被破壞3.1 HTTP 層面的“隱形殺手”Content-Encoding 與 Transfer-Encoding很多開發(fā)者以為“只要我用setContentType(application/pgp-encrypted)就萬事大吉”結(jié)果在 Nginx 或 CDN 后驗簽失敗。根本原因是 HTTP 協(xié)議棧的多層編碼干擾干擾層行為說明PGP 影響Content-Encoding: gzipHttpClient 或服務(wù)端自動對 body 壓縮PGP 密文是二進(jìn)制流gzip 會破壞其字節(jié)結(jié)構(gòu)導(dǎo)致解密時InvalidPacketExceptionTransfer-Encoding: chunked分塊傳輸時每塊前綴含長度十六進(jìn)制字符串如a\r\n...若未在 chunked 編碼前完成 PGP 封裝PGP 解析器會把a(bǔ)\r\n當(dāng)作無效 packet 頭Content-Type字符集聲明如charsetUTF-8某些老舊 HttpClient 實現(xiàn)會嘗試對 body 做字符編碼轉(zhuǎn)換PGP 密文含大量非 ASCII 字節(jié)0x00–0xFFUTF-8 強(qiáng)制轉(zhuǎn)碼會引入 \uFFFD 替換符徹底毀掉密文本 Demo 的解決方案是在 HttpClient 發(fā)送前將 PGP 操作收束為最終字節(jié)數(shù)組禁用所有自動編碼走原始ByteArrayEntity。// src/main/java/com/demo/client/PgpHttpClient.java public HttpResponse sendEncryptedRequest(String url, String plainText, PGPSecretKey secretKey) throws Exception { // 1. 生成 PGP 加密簽名后的字節(jié)數(shù)組非字符串 byte[] pgpMessage PgpUtil.encryptAndSign(plainText.getBytes(StandardCharsets.UTF_8), secretKey, publicKeyRing); // 公鑰環(huán)來自配置 // 2. 構(gòu)造原始字節(jié)數(shù)組實體禁用所有自動處理 ByteArrayEntity entity new ByteArrayEntity(pgpMessage); entity.setContentType(application/pgp-encrypted); // 不帶 charset entity.setChunked(false); // 強(qiáng)制關(guān)閉分塊 // 3. 設(shè)置 HttpClient 參數(shù)繞過默認(rèn) Content-Encoding CloseableHttpClient client HttpClients.custom() .disableContentCompression() // 關(guān)鍵禁用 gzip 壓縮 .build(); HttpPost post new HttpPost(url); post.setEntity(entity); return client.execute(post); }注意disableContentCompression()是 Apache HttpClient 4.5 才有的方法。若你用的是老版本4.3需手動設(shè)置RequestConfig并禁用ContentEncoding頭。3.2 如何讓服務(wù)端正確識別并解析 PGP 消息服務(wù)端不能依賴RequestBody String因為 Spring 默認(rèn)會用StringHttpMessageConverter嘗試 UTF-8 解碼而 PGP 密文不是合法 UTF-8。必須接管原始字節(jié)流// src/main/java/com/demo/controller/PgpController.java PostMapping(value /api/v1/data, consumes application/pgp-encrypted) public ResponseEntityString handlePgpData(RequestBody byte[] encryptedBytes) { try { // 直接傳入字節(jié)數(shù)組給 PGP 解析器 PgpDecryptionResult result PgpUtil.decryptAndVerify( encryptedBytes, secretKeyRing, // 服務(wù)端私鑰環(huán) publicKeyRing // 用于驗簽的對方公鑰環(huán) ); if (!result.isValidSignature()) { return ResponseEntity.status(400).body(Signature verification failed); } String plainText new String(result.getDecryptedData(), StandardCharsets.UTF_8); return ResponseEntity.ok(Success: plainText.length() chars received); } catch (PgpException e) { log.error(PGP decryption failed, e); return ResponseEntity.status(400).body(Decryption error: e.getMessage()); } }關(guān)鍵點(diǎn)在于consumes application/pgp-encryptedRequestBody byte[]的組合它會跳過所有HttpMessageConverter直通ServletInputStream確保字節(jié)零失真。3.3 PGP 消息體的結(jié)構(gòu)化設(shè)計為什么不用 base64 編碼有人會問“二進(jìn)制 HTTP body 不好調(diào)試為啥不 base64” —— 這是個血淚經(jīng)驗。Base64 編碼會使體積膨脹 33%更重要的是base64 編碼后的字符串可能被中間件如某些 WAF誤判為“可疑 payload”而攔截或清洗。某公司曾因 WAF 對base64字符串做 HTML 實體轉(zhuǎn)義→#43;導(dǎo)致解密時IllegalStateException: unknown object in stream。本 Demo 采用ASCII Armor 封裝即-----BEGIN PGP MESSAGE-----開頭的文本格式它本質(zhì)仍是 base64但被 OpenPGP 規(guī)范明確定義所有合規(guī)中間件都認(rèn)識它且支持行末補(bǔ)齊、換行符標(biāo)準(zhǔn)化\r\n比裸 base64 更健壯。生成代碼如下// PgpUtil.java 中的封裝方法 public static String armorEncode(byte[] binaryData) { ByteArrayOutputStream out new ByteArrayOutputStream(); ArmoredOutputStream armoredOut new ArmoredOutputStream(out); try { armoredOut.write(binaryData); armoredOut.close(); return out.toString(StandardCharsets.US_ASCII); } catch (IOException e) { throw new RuntimeException(e); } }這樣生成的 message 既可讀方便日志記錄和人工排查又符合標(biāo)準(zhǔn)還能被gpg --dearmor直接轉(zhuǎn)回二進(jìn)制。4. 避坑那些讓你凌晨三點(diǎn)還在看 WireShark 的 PGP 驗簽失敗現(xiàn)場4.1 現(xiàn)象PGPException: Unknown signature type: 0x00原因客戶端簽名時用了PGPSignature.BINARY_DOCUMENT類型 0x00但服務(wù)端驗簽代碼硬編碼只接受PGPSignature.CANONICAL_TEXT_DOCUMENT類型 0x01。OpenPGP 規(guī)范中BINARY_DOCUMENT表示“原始字節(jié)不做歸一化”而CANONICAL_TEXT_DOCUMENT會將\n統(tǒng)一轉(zhuǎn)為\r\n再哈?！艨蛻舳税l(fā)的是 JSON含\n服務(wù)端用CANONICAL模式驗簽必然失敗。解決統(tǒng)一使用PGPSignature.BINARY_DOCUMENT并在文檔中明確約定“所有 PGP 消息均以二進(jìn)制模式處理”禁用任何文本歸一化。4.2 現(xiàn)象InvalidPacketException: unknown packet type 19原因BC 1.70 默認(rèn)啟用Experimental Packet Type 19即Symmetrically Encrypted Integrity Protected Data Packet但某些老舊 PGP 庫如早期 GnuPG不識別該類型直接拋異常。解決降級為傳統(tǒng)加密包在PGPEncryptedDataGenerator初始化時指定PGPEncryptedDataGenerator encGen new PGPEncryptedDataGenerator( new JcePGPDataEncryptorBuilder(PGPEncryptedData.CAST5) .setWithIntegrityPacket(false) // 關(guān)鍵禁用 integrity packet .setSecureRandom(new SecureRandom()) );4.3 現(xiàn)象Signature check failed: signature doesnt match但gpg --verify成功原因服務(wù)端驗簽時PGPSignatureGenerator未設(shè)置setHashAlgorithm導(dǎo)致 BC 默認(rèn)用SHA1而客戶端用的是SHA256。更隱蔽的是某些 BC 版本在PGPSignatureGenerator初始化時若未顯式調(diào)用generateOnePassVersion(true)會生成不帶 One-Pass Signature 的消息而部分服務(wù)端解析器要求必須有該包。解決客戶端簽名時強(qiáng)制指定signGen.init(PGPSignature.BINARY_DOCUMENT, signingKey); signGen.setHashAlgorithm(HashAlgorithmTags.SHA256); // 顯式設(shè)哈希 signGen.generateOnePassVersion(true); // 強(qiáng)制生成 One-Pass 包服務(wù)端驗簽前先檢查signature.getHashAlgorithm()是否等于SHA256不匹配則拒絕。4.4 現(xiàn)象NullPointerExceptionatPGPSignature.verifyCertification()原因公鑰環(huán)PGPPublicKeyRing中缺少自簽名Self-Signature或用戶IDUserID包。BC 驗簽時會遍歷所有PGPSignature子包若某個PGPSignature的getEncoded()返回 null因損壞或截斷就會 NPE。解決加載公鑰環(huán)后強(qiáng)制校驗完整性public static void validatePublicKeyRing(PGPPublicKeyRing ring) { for (PGPPublicKey key : ring.getPublicKeys()) { if (key.isEncryptionKey() || key.isSigningKey()) { for (IteratorPGPSignature sigIt key.getSignatures(); sigIt.hasNext(); ) { PGPSignature sig sigIt.next(); if (sig.getEncoded() null) { throw new IllegalArgumentException(Corrupted signature in key key.getKeyID()); } } } } }4.5 現(xiàn)象本地測試全通過上 K8s 后SecureRandom初始化超時原因容器內(nèi)/dev/random設(shè)備熵池不足new SecureRandom()阻塞等待。BC 1.68 已優(yōu)化但若你項目間接依賴了老版本 BC如通過spring-boot-starter-security仍可能觸發(fā)。解決啟動 JVM 時強(qiáng)制指定熵源java -Djava.security.egdfile:/dev/./urandom -jar app.jar或在代碼中替換SecureRandom// 替換全局 SecureRandom 實例 SecureRandom prng new SecureRandom(); prng.setProvider(new SecureRandom().getProvider()); // 強(qiáng)制用默認(rèn) provider5. 密鑰生命周期管理從生成、分發(fā)到輪換一個都不能少5.1 生成符合生產(chǎn)要求的密鑰對參數(shù)不是隨便填的很多 Demo 用RSA_GENERAL 1024 位這在 2024 年已是高危操作。本 Demo 的KeyGenerator類強(qiáng)制執(zhí)行以下策略主密鑰Master KeyRSA 4096 位僅用于證書簽名Certify永不用于加密或簽名數(shù)據(jù)子密鑰Subkey加密子密鑰RSA 3072 位有效期 2 年簽名子密鑰Ed25519非 RSA因 EdDSA 簽名更快、密鑰更短、抗量子特性更好用戶ID 格式API Service servicedomain.com含郵箱便于追溯簽名策略主密鑰對子密鑰簽名時必須包含Signature Creation Time、Key Expiration Time、Preferred Symmetric AlgorithmsAES256三個子包。生成代碼節(jié)選// KeyGenerator.java public static PGPSecretKeyRing generateKeyRing(String userId, String passphrase) { PGPDigestCalculator sha256Calc new JcaPGPDigestCalculatorProviderBuilder() .build().get(HashAlgorithmTags.SHA256); // 主密鑰4096 RSA僅 Certify RSAKeyPairGenerator masterKpg new RSAKeyPairGenerator(); masterKpg.init(new RSAKeyGenerationParameters( BigInteger.valueOf(0x10001), new SecureRandom(), 4096, 12)); // 子密鑰3072 RSA 加密 Ed25519 簽名 AsymmetricCipherKeyPair encKeyPair generateRsaKeyPair(3072); AsymmetricCipherKeyPair signKeyPair generateEd25519KeyPair(); // 構(gòu)建主密鑰 PGPKeyRingGenerator keyRingGen new PGPKeyRingGenerator( PGPSignature.POSITIVE_CERTIFICATION, masterKeyPair, userId, sha256Calc, null, null, new JcaPGPContentSignerBuilder(masterKeyPair.getPublicKey().getAlgorithm(), HashAlgorithmTags.SHA256), new JcePBESecretKeyEncryptorBuilder(PGPEncryptedData.AES_256, sha256Calc) .setProvider(BC).build(passphrase.toCharArray()) ); // 添加加密子密鑰 keyRingGen.addSubKey(encKeyPair, null, null); // 添加簽名子密鑰 keyRingGen.addSubKey(signKeyPair, null, null); return keyRingGen.generateKeyRing(); }提示Ed25519 子密鑰需 BC 1.69 支持。若目標(biāo)環(huán)境受限可降級為 RSA 3072但必須禁用MD5和SHA1哈希算法。5.2 密鑰分發(fā)的兩種安全路徑密鑰絕不能以明文文件形式郵件發(fā)送。本 Demo 提供雙通道分發(fā)方案方式適用場景安全要點(diǎn)離線 USB 交付首次對接、高敏感系統(tǒng)使用gpg --export --armor導(dǎo)出公鑰環(huán).asc私鑰環(huán).asc用強(qiáng)密碼加密后交付接收方用gpg --decrypt解密HTTPS API 注冊SaaS 多租戶、動態(tài)密鑰輪換租戶調(diào)用POST /v1/keys/register傳入armoredPublicKey和tenantId服務(wù)端校驗userId格式、密鑰強(qiáng)度、簽名有效性后存入數(shù)據(jù)庫服務(wù)端密鑰加載邏輯// KeyManager.java public PGPPublicKeyRing loadPublicKeyRing(String tenantId) { String armored keyRepository.findByTenantId(tenantId).getArmoredPublicKey(); try (ArmoredInputStream aIn new ArmoredInputStream( new ByteArrayInputStream(armored.getBytes(StandardCharsets.US_ASCII)))) { PGPPublicKeyRingCollection pgpPub new PGPPublicKeyRingCollection(aIn); // 只取第一個 ring單租戶單密鑰 return pgpPub.getKeyRings().nextElement(); } }5.3 密鑰輪換的平滑過渡技巧密鑰不能“一刀切”切換必須支持新舊密鑰并存期Grace Period。本 Demo 的PgpVerifier實現(xiàn)了雙密鑰鏈路public class PgpVerifier { private final MapString, PGPPublicKeyRing activeKeys; // 當(dāng)前有效密鑰 private final MapString, PGPPublicKeyRing deprecatedKeys; // 已廢棄但仍在寬限期的密鑰 public boolean verify(byte[] data, String issuerUserId) { // 優(yōu)先用 activeKeys 驗簽 PGPPublicKeyRing ring activeKeys.get(issuerUserId); if (ring ! null verifyWithRing(data, ring)) { return true; } // 寬限期嘗試 deprecatedKeys ring deprecatedKeys.get(issuerUserId); if (ring ! null verifyWithRing(data, ring)) { log.warn(Deprecated key used for {}, issuerUserId); return true; } return false; } }寬限期設(shè)為 30 天由定時任務(wù)每天掃描deprecatedKeys中密鑰的getExpirationTime()過期則自動清理。6. 驗證閉環(huán)用真實抓包 單元測試構(gòu)建不可繞過的 PGP 信任鏈6.1 用 Wireshark 抓包驗證 PGP 消息的“端到端保真”光跑單元測試不夠必須看到真實字節(jié)流。本 Demo 提供PgpTrafficCapture工具類可在測試中啟動嵌入式 WireMock捕獲原始 HTTP 請求體// PgpTrafficCaptureTest.java Test public void testPgpRequestIntegrity() throws Exception { // 1. 啟動 WireMock記錄原始請求體 WireMockServer wireMock new WireMockServer(options().port(8089)); wireMock.start(); wireMock.stubFor(post(/api/v1/data) .willReturn(aResponse().withStatus(200))); // 2. 發(fā)送 PGP 請求 PgpHttpClient client new PgpHttpClient(wireMock.baseUrl()); client.sendEncryptedRequest(/api/v1/data, {\amount\:100}, secretKey); // 3. 獲取原始字節(jié)數(shù)組 LoggedRequest request wireMock.findAll(RequestPatternBuilder.newRequestPattern() .withMethod(POST) .withUrl(/api/v1/data)).get(0); byte[] rawBody request.getBody(); // 4. 用 BC 獨(dú)立解析驗證結(jié)構(gòu) try (InputStream in new ByteArrayInputStream(rawBody)) { PGPObjectFactory factory new PGPObjectFactory(in, new BcKeyFingerprintCalculator()); Object obj factory.nextObject(); assertTrue(obj instanceof PGPEncryptedDataList); // 必須是加密數(shù)據(jù)列表 } }抓包后用 Wireshark 打開.pcap文件過濾http.request.uri contains v1/data右鍵 → “Follow → HTTP Stream”確認(rèn)響應(yīng)體開頭是-----BEGIN PGP MESSAGE-----且無亂碼、無\r\n損壞。這是 PGP 在 HTTP 鏈路中存活的鐵證。6.2 單元測試覆蓋的五個致命邊界本 Demo 的PgpUtilTest包含 5 個不可跳過的測試用例每個都對應(yīng)一個真實翻車場景測試用例驗證點(diǎn)失敗后果testSignWithExpiredKey()客戶端用已過期的私鑰簽名服務(wù)端應(yīng)拒絕舊密鑰泄露后被濫用testDecryptWithWrongPassphrase()私鑰環(huán)密碼錯誤應(yīng)拋PGPException而非NullPointerException日志無法定位密鑰加載失敗原因testVerifyTamperedSignature()手動篡改密文最后 1 字節(jié)驗簽必須返回false中間人篡改無法被發(fā)現(xiàn)testHandleChunkedEncoding()模擬 HttpClient 分塊發(fā)送驗證PgpUtil是否能正確重組字節(jié)流Nginx 后驗簽失敗testEd25519VsRsaInteroperability()用 Ed25519 簽名服務(wù)端用 RSA 公鑰驗簽反之亦然必須失敗算法不匹配導(dǎo)致靜默失敗每個測試都用ParameterizedTest覆蓋 JDK 8/11/17 三版本確保 BC 兼容性。6.3 生產(chǎn)環(huán)境的 PGP 健康檢查 Endpoint上線后不能等故障才排查。本 Demo 內(nèi)置/actuator/pgp-health端點(diǎn)返回結(jié)構(gòu)化診斷{ status: UP, details: { keyRingLoaded: true, masterKeyValid: true, subKeysExpiringSoon: [2024-12-01], signatureAlgorithm: Ed25519, encryptionAlgorithm: AES256, lastVerified: 2024-05-20T14:22:33Z } }實現(xiàn)邏輯Component public class PgpHealthIndicator implements HealthIndicator { Override public Health health() { Health.Builder builder Health.up(); try { // 檢查密鑰環(huán)加載 assertNotNull(publicKeyRing); // 檢查主密鑰未過期 assertTrue(masterKey.getExpirationTime() null || masterKey.getExpirationTime().after(new Date())); // 檢查子密鑰有效期預(yù)警 30 天內(nèi)過期 ListDate expiringSoon findExpiringSubKeys(30); builder.withDetail(keyRingLoaded, true) .withDetail(masterKeyValid, true) .withDetail(subKeysExpiringSoon, expiringSoon) .withDetail(signatureAlgorithm, getSignatureAlgorithm()) .withDetail(lastVerified, new Date()); } catch (Exception e) { builder.down().withException(e); } return builder.build(); } }從那以后我每次上線新密鑰都強(qiáng)制走一遍/actuator/pgp-health Wireshark 抓包雙驗證再通知對接方。不是信不過代碼是信不過自己手抖復(fù)制錯一行userId。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取