简介ZXCA自信数字证书制作工具面向个人用户与小型组织聚焦数字证书的自主制作与管理帮助使用者在数据加密、身份验证、代码签名等场景中降低对外部CA服务的依赖适合希望理解并实践证书技术的入门到中级用户。压缩包共8个文件以4个txt说明文档、2个exe可执行程序、1个chm帮助手册和1个html页面为主整体约4.84MB体积轻便便于在本地快速部署与查阅。资源包含ZXCA专业版与文件小保镖两部分前者覆盖公私钥对生成、证书申请签发与撤销、PEM/DER等格式导入导出、文件加密及代码签名后者侧重文件加密存储、安全分享、权限控制与备份恢复。已有628人学习可帮助读者搭建小型CA环境、理解证书生命周期管理并借助随附文档与帮助手册完成从理论到操作的衔接。1. 数字证书自制工具从“证书焦虑”到一条命令签发做内网联调、本地 HTTPS 调试、私有服务双向认证时最烦的不是写业务代码而是证书。要么去公共 CA 申请流程长、域名还得是真的要么用 openssl 手敲一长串命令参数记不住SAN 漏配一个浏览器照样红锁。ZXCA 这类自信数字证书制作工具解决的就是这个场景它把根证书生成、服务端证书签发、SAN 扩展配置、格式导出这些动作收进一个工具里让“自己给自己签一张能用的证书”变成可复现的流程。适合谁做内网服务、私有化部署、IoT 设备调试、测试环境搭 HTTPS 的从业者。如果你只是给公网域名配证书那用公共 CA 更省事但只要涉及自签、内网、离线环境这套东西就值得拆开看。2. 自签证书的信任链为什么根证书决定一切自签证书能不能用不取决于服务端那张证书写得多漂亮而取决于客户端是否信任签发它的根。ZXCA 的核心逻辑就是先建一个“自己的 CA”再用这个 CA 去签服务端证书。理解这条链后面所有参数才有意义。2.1 根证书、中间证书与服务端证书的分工常见做法是三层根证书Root CA只用来签中间证书或直接签服务端证书私钥必须离线保存服务端证书Server Cert绑定域名或 IP带 SAN 扩展部署在服务上客户端信任的是根证书。很多人翻车是因为把根证书直接当服务端证书用浏览器虽然能弹“继续访问”但严格校验的客户端比如 Java、Go 的 HTTP client会直接拒绝。ZXCA 把根证书和服务端证书分开生成就是为了避免这种混用。根证书的关键参数是有效期和密钥用途。根证书有效期一般设长一些比如 10 年避免频繁更换导致所有客户端要重新导入密钥用途要带keyCertSign和cRLSign否则它签出来的证书链校验会失败。服务端证书有效期可以短90 天到 1 年都行内网环境图省事设 1 年也常见。2.2 SAN 扩展浏览器只认这个字段现在主流浏览器和 TLS 库早就不看 CNCommon Name了只认 SANSubject Alternative Name。一张证书 CN 写对了但 SAN 没写Chrome 照样报NET::ERR_CERT_COMMON_NAME_INVALID。ZXCA 在签发服务端证书时需要把域名、IP、甚至 localhost 都塞进 SAN。常见配置是字段示例值说明DNS.1api.internal.test内网域名DNS.2localhost本地调试IP.1192.168.1.50服务实际 IPIP.2127.0.0.1回环地址少写一个 IP用 IP 直连的客户端就会校验失败。这个坑我见过太多次排查时先看证书 SAN 列表基本一抓一个准。2.3 密钥算法与长度RSA 还是 ECDSAZXCA 一般会提供 RSA 和 ECDSA 两种密钥类型。RSA 2048 兼容性最好老设备、老 JDK 都认ECDSA P-256 证书体积小、握手快但部分老旧嵌入式设备和低版本运行时不支持。内网环境如果客户端可控ECDSA 更清爽如果对接方不明RSA 2048 是稳妥选择。密钥长度别贪大RSA 4096 握手开销明显内网调试没必要。3. 用 ZXCA 走一遍签发流程从根证书到服务端证书这一章按实际操作顺序走先生成根证书再签发服务端证书最后导出并验证。不同版本的 ZXCA 界面或命令行参数可能有差异下面以常见的“配置项 生成”流程来描述参数名以工具实际显示为准逻辑是通用的。3.1 生成根证书私钥保护和有效期设置根证书生成时工具通常要求填组织名、通用名、有效期和密钥算法。组织名可以随便填一个内部标识通用名建议写清楚比如Internal Test Root CA方便以后在证书管理器里认出来。私钥密码一定要设并且记牢——根私钥泄露等于整条信任链作废。如果用命令行方式逻辑等价于下面这段 openssl 配置ZXCA 内部做的也是类似的事# 生成根私钥AES256 加密保护 openssl genrsa -aes256 -out rootCA.key 2048 # 生成根证书有效期 3650 天 openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 \ -out rootCA.crt \ -subj /CCN/OInternal Lab/CNInternal Test Root CA \ -addext basicConstraintscritical,CA:TRUE \ -addext keyUsagecritical,keyCertSign,cRLSign这里basicConstraintsCA:TRUE是根证书的身份证缺了它后面签出来的链在严格校验下会断。keyUsage限定它只能签证书和 CRL不能拿来当服务端证书用。ZXCA 图形界面里这些通常藏在“高级选项”里默认值一般是对的但如果你手动改过回头校验失败先查这两项。3.2 签发服务端证书CSR 与 SAN 的填法服务端证书的流程是生成服务端私钥 → 生成 CSR证书签名请求→ 用根证书签发。ZXCA 一般把这三步合并了你只需要填 SAN 列表和有效期。CSR 里的 CN 现在意义不大填个标识就行真正起作用的是 SAN。# 生成服务端私钥 openssl genrsa -out server.key 2048 # 生成 CSRCN 仅作标识 openssl req -new -key server.key -out server.csr \ -subj /CCN/OInternal Lab/CNapi.internal.test # 准备 SAN 扩展文件 cat san.ext EOF subjectAltNameDNS:api.internal.test,DNS:localhost,IP:192.168.1.50,IP:127.0.0.1 keyUsagecritical,digitalSignature,keyEncipherment extendedKeyUsageserverAuth EOF # 用根证书签发有效期 365 天 openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key \ -CAcreateserial -out server.crt -days 365 -sha256 -extfile san.extextendedKeyUsageserverAuth表示这张证书用于服务端认证如果还要做双向认证客户端证书则要设clientAuth。ZXCA 里如果看到“用途”选项选“服务端”即可。签发完成后服务端需要部署的是server.crt和server.key客户端需要导入的是rootCA.crt。3.3 导出格式PEM、DER、PKCS12 别拿错证书格式拿错是另一个高频翻车点。PEM 是 Base64 文本-----BEGIN CERTIFICATE-----开头Nginx、Apache、大多数 Linux 服务用这个DER 是二进制部分 Java 老系统和 Windows 导入向导用PKCS12.pfx/.p12是带私钥的打包格式Windows IIS 和 Java keystore 常用。ZXCA 导出时一般会让你选格式。给 Nginx 用就导 PEM 的证书和私钥给 Java 服务用常见做法是导 PKCS12 再用keytool转 JKS# PKCS12 转 JKS注意 storepass 和 keypass 要一致或显式指定 keytool -importkeystore \ -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass 你的密码 \ -destkeystore server.jks -deststoretype JKS -deststorepass 你的密码密码别用空也别用changeit这种默认值内网也一样。导出后建议立刻用openssl x509 -in server.crt -text -noout看一眼 SAN 和有效期确认没导错文件。4. 部署与验证让客户端真正信任这张证书证书生成完只是半成品客户端不信任等于白做。这一章说清楚服务端怎么配、客户端怎么导、怎么验证。4.1 服务端配置Nginx 与 Java 的典型写法Nginx 配自签证书关键是证书链文件。如果只有服务端证书没有根证书部分客户端会报“无法获取本地颁发者证书”。稳妥做法是把服务端证书和根证书拼成一个 fullchain 文件server { listen 443 ssl; server_name api.internal.test; ssl_certificate /etc/nginx/certs/fullchain.crt; # server.crt rootCA.crt ssl_certificate_key /etc/nginx/certs/server.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; }fullchain.crt的拼接顺序是服务端证书在前、根证书在后顺序反了某些客户端会解析失败。Java 服务端则通常把 PKCS12 配进server.ssl.key-store信任库单独配trust-store指向根证书的 JKS。4.2 客户端导入根证书各平台路径不同Windows 导入到“受信任的根证书颁发机构”macOS 导入“钥匙串访问”后要把证书设为“始终信任”Linux 一般放/usr/local/share/ca-certificates/再跑update-ca-certificatesJava 客户端要keytool -importcert进 cacerts 或自定义 truststore。浏览器和系统信任库是两套Firefox 有自己的证书管理器导了系统没导 FirefoxFirefox 照样报错。4.3 验证命令三条命令定位问题验证别靠“打开浏览器看看”用命令更准# 1. 看服务端实际下发的证书链 openssl s_client -connect api.internal.test:443 -servername api.internal.test -showcerts # 2. 用根证书校验服务端证书 openssl verify -CAfile rootCA.crt server.crt # 3. 检查证书 SAN 和有效期 openssl x509 -in server.crt -noout -text | grep -A1 Subject Alternative Name第一条看服务端有没有把 fullchain 配全第二条看链是否完整第三条看 SAN 有没有漏。三条里任何一条不过先别怀疑客户端回头查证书本身。5. 避坑与排查自签证书最常见的五个翻车点5.1 浏览器提示证书无效但 CN 明明写对了现象Chrome 报NET::ERR_CERT_COMMON_NAME_INVALID检查 CN 没问题。原因现代浏览器只认 SANCN 已废弃。解决重新签发把域名和 IP 全部写进 SAN别只改 CN。5.2 Java 客户端报 PKIX path building failed现象Java 服务调 HTTPS 接口抛PKIX path building failed。原因JVM 的 truststore 里没有这张根证书或者服务端没下发完整链。解决把根证书导入 JVM truststore同时确认服务端配置了 fullchain。注意 Java 用的是自己的 cacerts不是系统信任库。5.3 证书导入后仍提示过期或时间不对现象证书刚生成客户端却说“证书已过期或尚未生效”。原因生成证书的机器时间不对或者客户端时区/时间偏差大。解决校准生成端和客户端时间重新签发。自签证书的notBefore取的是生成时刻机器时间飘了证书就废了。5.4 用 IP 访问失败用域名正常现象域名访问正常换成 IP 直连就证书错误。原因SAN 里只写了 DNS没写 IP。解决签发时把服务实际 IP 加进 SAN 的IP.1重新签发并替换。5.5 私钥权限过宽导致服务启动被拒现象Nginx 启动报SSL_CTX_use_PrivateKey_file失败或权限错误。原因私钥文件权限是 644或者属主不对。解决chmod 600 server.key属主设为运行服务的用户。私钥可读范围越小越好内网也别大意。6. 进阶技巧用脚本把签发流程固化下来手工点工具界面签一两次还行环境一多就乱。我一般会把 ZXCA 的签发逻辑固化成脚本参数化域名和 IP每次新环境跑一遍证书命名带环境标识避免拿错。核心思路是把 SAN 列表和有效期做成变量根证书只生成一次并单独保管服务端证书按环境批量签。#!/usr/bin/env bash # sign_server_cert.sh —— 按环境签发服务端证书 set -euo pipefail ENV$1 # 例如 dev / staging DOMAIN$2 # 例如 api.internal.test IP$3 # 例如 192.168.1.50 DAYS${4:-365} openssl genrsa -out ${ENV}-server.key 2048 openssl req -new -key ${ENV}-server.key -out ${ENV}-server.csr \ -subj /CCN/OInternal Lab/CN${DOMAIN} cat ${ENV}-san.ext EOF subjectAltNameDNS:${DOMAIN},DNS:localhost,IP:${IP},IP:127.0.0.1 keyUsagecritical,digitalSignature,keyEncipherment extendedKeyUsageserverAuth EOF openssl x509 -req -in ${ENV}-server.csr -CA rootCA.crt -CAkey rootCA.key \ -CAcreateserial -out ${ENV}-server.crt -days ${DAYS} -sha256 \ -extfile ${ENV}-san.ext cat ${ENV}-server.crt rootCA.crt ${ENV}-fullchain.crt openssl verify -CAfile rootCA.crt ${ENV}-server.crt这段脚本里set -euo pipefail保证任何一步失败就停不会签出半成品DAYS给了默认值 365临时环境可以传 30最后自动拼 fullchain 并跑一次 verify签完立刻知道链对不对。根证书的rootCA.key不要放在脚本同目录单独放一个受控路径脚本里用绝对路径引用。环境多了以后证书文件名带ENV前缀部署时不容易拿错。还有一个习惯每次签发完把 SAN 列表和有效期记到一张环境对照表里谁用了哪张证书、什么时候到期一目了然。自签证书最大的风险不是技术是“忘了哪张是哪张”到期了服务突然挂掉才想起来。从那以后我每次签完证书都强制跑一遍openssl verify并把输出存档宁可多花十秒也不想到半夜被叫起来查证书。希望帮到你。本文还有配套的精品资源点击获取
