简介围绕Java数字签名与数字证书的源码示例面向中高级Java开发者及安全编程初学者演示如何在网络通信中利用非对称加密保障数据完整性与发送方身份验证。压缩包为RAR格式体积仅17KB便于快速下载与阅读源代码主要涉及java.security与java.security.cert包中的Signature、KeyPairGenerator、CertificateFactory等核心类可用于理解RSA/DSA算法下的签名和验签流程。已有134人学习适合正在学习Java安全机制或需要在项目中落地证书与签名功能的开发者参考。示例覆盖从密钥对生成、数字签名签发与验证到X.509证书解析和自签名证书生成的完整链路帮助读者把安全概念转化为可运行的实际代码是深入掌握Java安全编程的实用素材。1. 拿到这份源码先别急着跑数字签名和数字证书是两套东西拿到一份“Java 数字签名、数字证书生成源码”时别急着找入口类先想清楚签名、证书、密钥库这三样东西各自负责哪一段。最常见的业务场景是两个后端服务做接口联调A 服务给 B 服务回传数据时对参数算一遍数字签名B 服务拿 A 服务提供的数字证书里的公钥做验签。数字证书解决“这把公钥是谁的、可不可信”数字签名解决“这段数据有没有被改过、是不是对方发的”。这套源码要是只给了你 keytool 命令行你还得自己补 Java 侧读证书、算签名的代码要是直接给了一个生成证书的 Java 类你得先确认它依赖了 Bouncy Castle 而不是纯 JDK。也有人是被系统弹窗里“数字签名”四个字带进来的这里先划个界本文只讲 Java 应用层的证书与签名源码不涉及操作系统驱动签名。适合正在写接口鉴权、支付回调验签、内部系统互信或者做课程设计需要把证书生成写进代码的 Java 开发者。2. 先分清签名和证书Java 端要用的 API、密钥库与算法选型2.1 数字签名是“私钥签、公钥验”不是“加密的逆过程”数字签名解决三个问题来源可靠、内容完整、行为不可抵赖。发送方持私钥对一个数据块做签名运算接收方持对应公钥验签。很多人第一次看 RSA 时觉得“签名就是私钥加密、验签就是公钥解密”这个理解在数学形式上有那么点像但在 Java 的 API 设计里根本不是一回事签名走Signature类处理的是数据的摘要输出的是签名值加密走Cipher类处理的是整段明文输出的是密文。把Signature的结果丢给Cipher去“解密”大概率得到一堆乱码这是最典型的使用错误后文避坑章会专门展开。在源码里找签名逻辑时先看 import 里有没有java.security.Signature再确认getInstance里的算法串比如SHA256withRSA或SHA256withECDSA。这个算法串不是随便取的格式固定为“摘要算法 with 非对称算法”。签名长度由非对称算法决定2048 位 RSA 的签名固定 256 字节基于 P-256 曲线的 ECDSA 签名是 DER 编码的 r/s 两个大整数通常 70 到 72 字节。同样是差不多的安全强度签名值长度差了三倍多接口报文设计、数据库字段长度都要跟着这个数走这也是源码里能直接看到的关键参数之一。再补一个容易忽略的点数字签名不提供机密性。签名值可以从数据本身和公钥推出它只证明“这串字节是持私钥的人签的、且没有被改过”。如果业务要求报文内容不能泄露签名只能跟加密搭配用。常见做法是先对报文做签名再把“报文 签名值”整体做对称加密或者直接放到 HTTPS 通道里签名负责应用层防篡改TLS 负责传输层机密性。2.2 数字证书解决“公钥是谁的”自签名和 CA 签发适用不同场景数字证书解决公钥归属问题。一个 X.509 证书里主要装着主体 DNCN、O、OU 等、公钥、签发者 DN、有效期、序列号、扩展字段以及签发者对以上内容的签名。证书本身是一段自洽的数据它不被谁“加密”而是被签发者的私钥签名过谁拿到签发者的公钥谁就能验证这张证书内容有没有被动手脚。自签名证书就是签发者和主体是同一个实体私钥自己签自己。这类证书适合内部联调、测试环境、内网服务之间互认缺点是没有第三方背书目标系统默认不信任必须手动把证书导入信任库。对外提供服务或跟第三方系统对接时一般要用 CA 签发的证书否则对方的安全策略不一定放行。源码里如果只生成了自签名证书那它八成面向的是内部工具链或课程设计这直接决定后续怎么复用。Java 侧真正要做的是证书链校验而不是简单地PublicKey对上就完事。源码里要做完整校验需要拿到签发者证书一路向上追到根再调CertPathValidator确认整条链有效如果只拿叶子证书做验签一旦对方轮换证书而你的信任库没更新线上就会间歇性验签失败。2.3 Java 端要用到的 API 与密钥库选型JCA/JCE、JKS/PKCS12、RSA/ECDSAJava 安全体系是 JCA/JCE 架构核心是 Provider 机制。常见 Provider 有 SUNJDK 自带、SunRsaSign、SunEC以及第三方 Bouncy Castle。写代码时只需要对着标准接口调KeyPairGenerator生成密钥对KeyStore读写密钥库Signature做签名验签CertificateFactory解析证书文件。真正干活的实现在 Provider 里这也是源码能同时兼容 JDK 自带算法和 BC 扩展算法的原因。密钥库格式选型这张表很实用拿到源码先看它落在哪一列格式扩展名谁在用特点JKS.jks仅 JavaJDK 8 及以前默认私密格式跨语言不友好PKCS12.p12 / .pfxJava、OpenSSL、Go、Node.js标准格式JDK 9 默认含密钥与证书PEM.cer / .crt / .pemOpenSSL、各类服务Base64 文本通常只装证书或私钥算法选型上Java 数字签名现在的主流通用配置是 RSA-2048 SHA256withRSA或者 EC P-256 SHA256withECDSA。密钥长度低于 2048 的 RSA 不建议再用SHA1withRSA也已经被主流安全策略标记为弱算法有些 JDK 版本默认禁用。ECDSA 的优点是签名短、性能不错缺点是互操作时对曲线名称敏感P-256secp256r1是跨语言支持最稳的曲线别一上来就选 P-521部分语言库实现不全。面试八股文里经常追着问的“为什么 JDK 9 之后默认密钥库变成 PKCS12”答案就是 JKS 是 Java 私有格式跨语言协作是刚需PKCS12 是标准。KeyPairGenerator kpg KeyPairGenerator.getInstance(RSA); kpg.initialize(2048); // 密钥长度低于 2048 不建议 KeyPair kp kpg.generateKeyPair();这行代码是后面所有签名、证书生成的起点。initialize(2048)只传了长度没有传SecureRandom走系统默认随机源一般够用源码里如果看到有人用固定种子初始化SecureRandom那一定是测试代码不能上线。翻 jdk 源码会看到sun.security.x509包里有一套不公开的内部证书实现但工程上不要直接引用Bouncy Castle 才是标准做法。3. 生成数字证书的源码keytool 命令与 Bouncy Castle 两条落地路径3.1 先用 keytool 跑通一条最小链路一条命令生成密钥库加证书最常见的源码形态之一就是一个写好的 keytool 命令行脚本。先用一行命令在本地跑通最小链路再决定要不要改成 Java 代码。下面这条命令生成一个 PKCS12 密钥库alias 叫 server包含一对 RSA 2048 密钥和一张自签名证书。keytool -genkeypair \ -alias server \ -keyalg RSA \ -keysize 2048 \ -validity 3650 \ -keystore server.p12 \ -storetype PKCS12 \ -storepass 123456 \ -dname CNapi.example.com, OUDev, OExample, LShanghai, STShanghai, CCN参数说明-keyalg RSA指定非对称算法-keysize 2048是密钥长度-validity 3650是有效期天数对内部服务可以按年来算但要保证后面有监控-dname里 CN 是证书主体通用名对 HTTPS 服务而言必须跟域名一致对内部接口服务可以写服务标识-storetype PKCS12一定要显式写否则不同 JDK 版本默认值不同换机器行为就变了。命令执行完当前目录出现一个 server.p12里面是一对密钥加一张自签名证书。这张证书同时担任“根证书”和“叶子证书”两个角色能满足内部联调不能满足外部严格校验。-storepass示例用的是 123456源码落地时换成配置中心里的强口令别图省事。3.2 用 Java 代码直接生成 X.509 证书Bouncy Castle 是工程标准如果源码是用 Java 直接生成证书十有八九走了 Bouncy Castle。JDK 自带 API 不提供“从零生成 X.509 证书”的公开入口keytool 是内部工具工程上要程序化签发证书只能用 BC 的X509v3CertificateBuilder。下面是最小可运行版本。import org.bouncycastle.asn1.x500.X500Name; import org.bouncycastle.asn1.x509.BasicConstraints; import org.bouncycastle.asn1.x509.Extension; import org.bouncycastle.asn1.x509.KeyUsage; import org.bouncycastle.cert.X509CertificateHolder; import org.bouncycastle.cert.jcajce.JcaX509CertificateConverter; import org.bouncycastle.cert.jcajce.JcaX509v3CertificateBuilder; import org.bouncycastle.operator.jcajce.JcaContentSignerBuilder; import java.math.BigInteger; import java.security.KeyPair; import java.security.KeyPairGenerator; import java.security.SecureRandom; import java.security.Security; import java.security.cert.X509Certificate; import java.util.Date; public class CertGenerator { public static void main(String[] args) throws Exception { Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider()); KeyPairGenerator kpg KeyPairGenerator.getInstance(RSA); kpg.initialize(2048); KeyPair kp kpg.generateKeyPair(); X500Name issuer new X500Name(CNExample Root CA, OExample, CCN); X500Name subject new X500Name(CNapi.example.com, OExample, CCN); BigInteger serial new BigInteger(64, new SecureRandom()); Date notBefore new Date(); Date notAfter new Date(notBefore.getTime() 3650L * 24 * 60 * 60 * 1000); JcaX509v3CertificateBuilder builder new JcaX509v3CertificateBuilder( issuer, serial, notBefore, notAfter, subject, kp.getPublic()); builder.addExtension(Extension.basicConstraints, true, new BasicConstraints(0)); builder.addExtension(Extension.keyUsage, true, new KeyUsage(KeyUsage.digitalSignature | KeyUsage.keyEncipherment)); JcaContentSignerBuilder signerBuilder new JcaContentSignerBuilder(SHA256withRSA); X509CertificateHolder holder builder.build(signerBuilder.build(kp.getPrivate())); X509Certificate cert new JcaX509CertificateConverter() .setProvider(BC) .getCertificate(holder); System.out.println(证书序列号: cert.getSerialNumber()); System.out.println(签名算法: cert.getSigAlgName()); System.out.println(有效期至: cert.getNotAfter()); } }这段代码做了四件事生成 RSA 密钥对构造证书构建器填入签发者、主体、序列号、有效期和公钥加上基本约束和用途扩展用私钥对证书内容签名。BasicConstraints(0)表示这是一张叶子证书不是 CA 证书KeyUsage通过位或组合了数字签名和密钥协商两个用途。serial 用 64 位随机数生成避免固定从 1 开始被利用做序列号猜测。JcaContentSignerBuilder的算法串要和密钥类型匹配RSA 密钥就用SHA256withRSA换成 EC 密钥就改成SHA256withECDSA。运行前需要引入 bcprov-jdk18on 和 bcpkix-jdk18on 两个依赖版本以项目当前用的 Bouncy Castle release 为准尽量选 jdk18on 系列而不是老的 jdk15on。如果签名方和证书主体是同一个上面生成的就是自签名证书如果 issuer 和 subject 不同issuer 的私钥就必须换成上级 CA 的私钥这就是后面第 6 章讲的证书链签发。3.3 导出证书并导入对方信任库PEM/DER 格式差异要分清证书生成只是前半段源码真正容易被忽略的是导出和导入。keytool 生成的密钥库包含私钥绝不能直接发给对端对端只需要你的公钥证书。导出命令这样写keytool -exportcert \ -alias server \ -keystore server.p12 \ -storetype PKCS12 \ -storepass 123456 \ -file server.cer导出得到的是 X.509 证书文件本质是 DER 二进制格式把后缀改成 .crt、.cer 都不影响内容但代码里解析时别把 PEM 的文本头当成证书内容。如果对端需要 PEM 文本用 OpenSSL 转换openssl x509 -inform DER -in server.cer -out server.pem。对端收到证书后要导入自己的信任库才算真正放行keytool -importcert \ -alias server \ -file server.cer \ -keystore truststore.p12 \ -storetype PKCS12 \ -storepass 123456 \ -noprompt-noprompt避免交互式确认适合写进脚本。信任库和密钥库可以共用同一个文件但工程上建议分开信任库只放别人家的证书密钥库只放自己的私钥和证书。源代码里如果出现“把私钥库直接发给对方”的注释或说明文档那基本可以断定这份源码只覆盖了演示场景上线前必须拆开。3.4 源码拿到手先看目录判断它属于三层结构里的哪一层拿到这份 rar 源码后先按目录判断它属于哪一层有 pom.xml 或 build.gradle 的看依赖里有没有 bcpkix只有 bin/ 和.bat、.sh 的说明主体是 keytool 脚本有 java 类但一屏不到五十行的多半是用 JDK 自带 API 做 KeyStore 读写的工具类。这类源码在 java 课程设计案例源码里出现频率很高常见结构是 CertUtil 提供生成和导出SignatureUtil 提供签名验签Main 演示一次完整流程。评估它值不值得复用就看你要改三个地方时顺不顺密钥库路径、storepass、算法串。如果这三个改动都要动到多处代码说明参数没有集中配置接手后第一件事是抽一个 Config 类把 storeType、storePass、alias、keyPass、algorithm 全部收拢。不要把这部分当黑匣子证书相关的坑几乎都藏在“路径写死在代码里”和“口令散落各处”这两件事上。4. 数字签名源码实现签名方与验签方的完整 Java 代码4.1 签名方源码从密钥库读私钥三步完成签名源码里签名模块的通用结构是读密钥库、取私钥、初始化和签名。下面这段可以直接复制到工具类。import java.nio.charset.StandardCharsets; import java.security.KeyStore; import java.security.PrivateKey; import java.security.Signature; import java.util.Base64; import java.io.FileInputStream; public class Signer { public static String sign(String data, String ksPath, String ksPass, String alias, String keyPass) throws Exception { KeyStore ks KeyStore.getInstance(PKCS12); try (FileInputStream in new FileInputStream(ksPath)) { ks.load(in, ksPass.toCharArray()); } PrivateKey privateKey (PrivateKey) ks.getKey(alias, keyPass.toCharArray()); Signature sig Signature.getInstance(SHA256withRSA); sig.initSign(privateKey); sig.update(data.getBytes(StandardCharsets.UTF_8)); byte[] signBytes sig.sign(); return Base64.getEncoder().encodeToString(signBytes); } }逻辑上分四步KeyStore.getInstance(PKCS12)要和生成密钥库时的-storetype保持一致否则 load 直接抛异常ks.getKey(alias, keyPass)拿到私钥alias 大小写敏感写错会抛 UnrecoverableKeyExceptionsig.update把待签名数据喂进去这里强制用 UTF-8Windows 上默认字符集是 GBK不写StandardCharsets.UTF_8就会踩第 5 章的坑最后sign()返回字节数组转 Base64 方便在 HTTP 报文里传输。注意Signature实例不是线程安全的同一个实例在多线程里 initSign、update、sign 会互相污染。正确做法是每次签名都在方法内部 new 一个或者放 ThreadLocal。很多源码里的线上问题就是这个实例被设计成了单例。4.2 验签方源码从 .cer 文件读公钥验证签名import java.nio.charset.StandardCharsets; import java.security.Signature; import java.security.cert.CertificateFactory; import java.security.cert.X509Certificate; import java.util.Base64; import java.io.FileInputStream; public class Verifier { public static boolean verify(String data, String signBase64, String cerPath) throws Exception { CertificateFactory cf CertificateFactory.getInstance(X.509); X509Certificate cert; try (FileInputStream in new FileInputStream(cerPath)) { cert (X509Certificate) cf.generateCertificate(in); } Signature sig Signature.getInstance(SHA256withRSA); sig.initVerify(cert.getPublicKey()); sig.update(data.getBytes(StandardCharsets.UTF_8)); return sig.verify(Base64.getDecoder().decode(signBase64)); } }验签方与签名方有三个对称点算法串必须一致data必须和签名方喂给update的是同一串字节signBase64要先 Base64 解码成原始字节再传给verify。CertificateFactory.getInstance(X.509)是固定写法传.cer、.crt、.der文件都能解析但前提是文件内容是 DER 或 PEM 纯证书不能把完整密钥库文件丢进来。验签失败时不要只看 boolean日志里把算法串、证书 DN、证书有效期一并打出来。很多情况不是签名问题而是对端拿到的证书已经过期或者引错了 truststore 里的旧证书。4.3 签名参数与跨端互操作字符集、Base64、算法串一个都不能错签名跨语言联调时参数表是排查的第一张表参数推荐值说明签名算法SHA256withRSA跨语言兼容最好OID 是 1.2.840.113549.1.1.11摘要算法SHA-256SHA-1 已被禁用不要用字符集UTF-8Java 里显式写StandardCharsets.UTF_8签名值编码标准 Base64Go 用 StdEncodingJava 用Base64.getEncoder()待签名数据排序后的规范字符串常见做法是按参数名 ASCII 排序空值不参与签名其中“待签名数据”是最容易翻车的如果双方约定把整个 JSON 报文原样签名那任何一方的 JSON 库调整了键顺序验签都会失败。工程上常见做法是定义一份规范串参数名按 ASCII 排序拼接成k1v1k2v2空值跳过。这个规范串就是签名和验签的唯一输入和报文的物理格式解耦。注意Base64 有标准版和 URL 安全版两种Java 的Base64.getEncoder()输出带/URL 安全版会换成-_。两端用混了验签结果永远是 false。5. 数字签名与证书避坑指南五个必踩的问题与对症解法5.1 验签结果永远是 false先查字符集和后端拼串方式现象A、B 两端接口联调签名方自己的自测用例能过B 端验签一直 false两边的日志都显示数据“看起来一样”。原因待签名数据在两端落地时字节不一致。最常见有两个来源一端用getBytes()不带字符集走系统默认编码Windows 常见 GBKLinux 是 UTF-8另一端在验签前把 JSON 重新序列化了一次键的顺序都变了字节自然不一样。Signature 是对签名前的字节串做摘要字节串不同摘要就不同验签必然失败。解决代码里所有getBytes()和new String()一律显式指定StandardCharsets.UTF_8约定验签方直接用接收到的原始报文字节验签不要反序列化再序列化。如果报文里有空值或排序规则把规则写进接口文档按 4.3 的规范串方式统一输入。5.2 自签名证书被目标系统判定“不受信任”现象把导出的 server.cer 发给对端对端导入信任库后仍然报“证书不受信任”TLS 握手或证书链校验直接被拒。原因两个方向都有。一是自签名证书没有任何第三方背书对端安全策略要求叶子证书必须能追溯到它们预置的根 CA二是证书扩展里没声明 BasicConstraints对端无法判断它是 CA 还是叶子。解决自签名证书只适合内部、测试、课程设计。对端有严格策略时改用内部 CA 签发后再导出证书链。keytool 生成自签名证书时显式加-ext BasicConstraintsca:true或ca:false不要让默认行为决定扩展对接时提供完整链根证书 叶子证书而不是只丢一张裸叶子证书。5.3 JDK 9 读老 JKS 密钥库报错现象运维换了 JDK 11老应用启动时KeyStore.load()直接抛 IOException报 “Invalid keystore format” 或 “keystore password was incorrect”用 keytool -list 打开 .jks 也报错。原因JDK 9 开始默认密钥库类型从 JKS 改成 PKCS12。keytool 没有显式指定-storetype JKS时会尝试按 PKCS12 解析老库格式不匹配就报错。代码里KeyStore.getInstance(JKS)如果没写默认同样按新默认值走。解决如果只维护一个库转成 PKCS12keytool -importkeystore \ -srckeystore old.jks -srcstoretype JKS -srcstorepass 旧口令 \ -destkeystore new.p12 -deststoretype PKCS12 -deststorepass 新口令如果暂时不能换库代码里显式写KeyStore.getInstance(JKS)keytool 命令加-storetype JKS。注意 alias 大小写敏感转库后先keytool -list核对一遍。5.4 把 Signature 当“私钥加密”用换来一脑袋问号现象开发者拿Signature对一段很长的明文做运算然后要求对方“用公钥解密还原原文”结果不是乱码就是报 “Data must not be longer than 245 bytes”RSA 2048 的加密上限。原因概念错位。Signature内部是摘要 非对称签名输出是签名值不是加密后的密文RSA 加密有明文长度上限签名则和明文长度无关只和摘要长度有关。把签名当加密用既不保密也解不出原文。解决需要防篡改和来源认证用Signature需要机密性用Cipher.getInstance(RSA/ECB/OAEPWithSHA-256AndMGF1Padding)填充不要用 PKCS1v15或者干脆把报文交给 HTTPS。这个点在 java 基础面试里经常被当概念题考代码里最容易踩的是把签名结果当 token 塞进 URL 而不做 Base64。5.5 证书过期没人管半夜收到对端告警现象线上验签服务某天开始报 “Certificate has expired”业务全部失败查日志才发现密钥库里的证书过期时间是凌晨三点。原因证书生成时-validity设了 365没有人监控剩余有效期很多源码把有效期写死在命令行或常量里证书轮换全靠手工。证书到期没有后悔药只有监控和提前续签。解决在源码里加一个证书有效期检查工具读 KeyStore 所有 alias取X509Certificate.getNotAfter()剩余小于 30 天打 WARN小于 7 天告警X509Certificate cert (X509Certificate) ks.getCertificate(alias); long remain cert.getNotAfter().getTime() - System.currentTimeMillis(); long days remain / (24 * 60 * 60 * 1000L); if (days 30) { System.out.println(证书即将过期, alias: alias , 剩余天数: days); }有效期要写成配置项配合自动续签脚本否则迟早栽在到期上。6. 把自签名升级成 CA 签发证书链验证与测试兜底内部服务之间长期互信自签名证书也能用但一旦涉及多环境、多团队最好的做法是自己搭一套内部 CA根证书只负责签发叶子证书给具体服务。好处是根证书只在信任库里维护一份叶子证书过期只需要重签不用登录每台机器改信任库。命令序列如下# 1. 生成根 CA有效期 20 年 keytool -genkeypair -alias root -keyalg RSA -keysize 2048 -validity 7300 \ -keystore root.p12 -storetype PKCS12 -storepass 123456 \ -dname CNInternal Root CA, OExample, CCN \ -ext BasicConstraintsca:true # 2. 导出根证书后续导入各服务密钥库 keytool -exportcert -alias root -keystore root.p12 -storetype PKCS12 \ -storepass 123456 -file root.cer # 3. 生成服务密钥对和证书请求 keytool -genkeypair -alias server -keyalg RSA -keysize 2048 -validity 3650 \ -keystore server.p12 -storetype PKCS12 -storepass 123456 \ -dname CNapi.example.com, OExample, CCN keytool -certreq -alias server -keystore server.p12 -storetype PKCS12 \ -storepass 123456 -file server.csr # 4. 根 CA 签发叶子证书 keytool -gencert -alias root -keystore root.p12 -storetype PKCS12 \ -storepass 123456 -infile server.csr -outfile server_signed.cer \ -validity 3650 \ -ext BasicConstraintsca:false \ -ext KeyUsagedigitalSignature,keyEncipherment # 5. 把根证书和叶子证书一起导入服务密钥库 keytool -importcert -alias root -keystore server.p12 -storetype PKCS12 \ -storepass 123456 -file root.cer -noprompt keytool -importcert -alias server -keystore server.p12 -storetype PKCS12 \ -storepass 123456 -file server_signed.cer -noprompt跑完这五步server.p12 里就是一条完整证书链。验证用 OpenSSLopenssl verify -CAfile root.cer server_signed.cer如果 server_signed.cer 是 DER 二进制先转 PEM 再验证输出server_signed.cer: OK才算链完整。Java 端用CertPathValidator也能做同样校验但 OpenSSL 更适合先排掉“链没拼对”这类基础问题。我的习惯是每次改签名算法或密钥参数都在源码里留一条最小测试签名、验签、断言通过同时把证书剩余有效期打印出来。这个习惯已经帮我把两次线上证书过期问题挡在发布前。这套源码值不值得投入就看它有没有把密钥库、口令、算法串抽成配置没有的话按上面的方案改一版再上线。希望帮到你。本文还有配套的精品资源点击获取