证书这东西平时用不着真到要用的时候能卡掉人半条命。尤其是自己搭的测试环境、内部服务、或者做HTTPS双向认证OpenSSL的命令来来回回就那几个但每次都能遇到点幺蛾子。要么SAN没带要么私钥权限问题要么签名算法太老直接被拒。这篇就把我从CSR申请到CA签名的完整流程掰开揉碎讲一遍重点放在踩过的坑上希望对正在折腾证书的你有点帮助。1. 项目概述与核心需求解析1.1 证书体系是什么能解决什么问题先明确一个概念数字证书本质上是“身份证明 加密钥匙包”。它解决两个问题一是证明“我是谁”二是让通信双方能安全地交换密钥。以典型的HTTPS站点为例浏览器访问一个网站时网站会亮出自己的证书。浏览器检查证书是否由可信机构CA签发、是否过期、域名是否匹配确认无误后再用证书里的公钥协商加密通道。这就是一次完整的信任链验证。具体到内部系统场景更丰富。比如公司内部搭建的Git服务器、Docker仓库、Kubernetes集群、Kafka或RabbitMQ之间的TLS加密通信这些统统离不开证书。用公开CA签吧费钱费事内网域名还可能被拒绝自己动手用OpenSSL搭一套内部CA然后签发证书就成了最务实的方案。适合读这篇的我猜主要是这几类人运维工程师要自建CA统一管理内部组件证书后端开发在调试HTTPS接口或者配置Nginx反向代理时需要一张本地证书安全测试的同学做中间人代理测试时需要伪造证书。无论哪类掌握了OpenSSL这套东西走到哪里都不会慌。1.2 为什么选OpenSSL以及你可能正在犯的认知错误市面上有CFSSL、Easy-RSA、mkcert等工具但OpenSSL到底还是绕不开的底层依赖。原因很简单几乎所有框架、服务器、语言库底层用的就是OpenSSL其他工具生成的证书最终也得以OpenSSL能解析的格式存在。很多人以为用OpenSSL只是“敲几下命令”其实不然。最容易踩坑的是对证书“格式”的三个误区。第一PEM和CRT不是两回事。PEM是Base64编码文本用记事本打开能看到-----BEGIN CERTIFICATE-----的CRT只是一种扩展名内容完全可能是PEM。很多人把.crt文件当成二进制读结果变乱码急得直跺脚其实用文本编辑器打开就对了。第二私钥绝对不要带密码生成或至少封存时再加密。内网证书尤其如此Nginx、Tomcat、Java应用加载私钥时都需要密钥库密码但很多程序不提供输入密码的参数。一旦设了密码启动服务时就会卡在密码输入阶段头大得很。生产环境如需加密保存私钥文件用单独的工具做信封加密别直接写在证书生成流程里。第三证书有效期尽量别太短。默认自签CA证书通常以365天为周期具体取决于OpenSSL配置。测试没所谓但如果是内部长期使用的根证书建议签个10年以上否则每年一续期光通知各业务方更新信任链就能烦死你。2. 环境准备与关键文件管理2.1 检查OpenSSL版本优先3.x环境这块第一个动作不是急着敲openssl req而是先看版本。openssl version实测中CentOS 7自带的通常是OpenSSL 1.0.2系列Debian 10带的是1.1.1系列而这两者的默认签名算法和加密强度都有区别。如果你用的是OpenSSL 3.xMD5、SHA1这类弱算法默认直接禁止配置不当会报错。我个人的建议统一用OpenSSL 3.x版本进行后续操作。这里有两点客观优势。一是支持现代加密套件比如TLS 1.3二是内部CA签发的证书若交给客户端验证各语言库对老版本OpenSSL生成的证书校验策略更严格容易出兼容问题新版本反而更干净。安装新版本没什么难度各平台包管理器都有注意编译安装时带上enable-fips与否看自己需求别手贱加一堆额外编译参数默认安装就够日常使用。2.2 搭建好干净的证书目录结构很多人把证书文件随便丢会带来两个直接问题权限不好控搞不清哪个私钥对应哪张证书。我的习惯是单独建一个目录专门管理内部PKI。废话不多说直接给一套我一直在用的目录骨架mkdir -p ~/pki/ca mkdir -p ~/pki/certs mkdir -p ~/pki/private mkdir -p ~/pki/crl touch ~/pki/index.txt echo 1000 ~/pki/serial这样设计的目的是把CA相关的材料根证书的私钥、自签证书、撤销列表和业务证书各服务使用的证书分开存放。后面所有证书都从certs/目录输出扫描的时候一目了然。还有一个常被忽略的点index.txt和serial是OpenSSL维护证书签发记录的数据库。没有这两个文件后续执行证书撤销、查看已签发列表等功能时会直接报错所以即便你现在不需要撤销功能也先建好放着。注意私钥目录我习惯直接设700权限。之前见过有人把私钥放在家目录下默认644权限相当于所有本地用户都能读这等于把大门钥匙放在蹭脚垫下面。chmod 700 ~/pki/private是底线操作。3. 私钥生成与CSR申请的完整实操3.1 私钥生成算法、位数与格式选择生成私钥第一个决策是用RSA还是ECC。RSA的兼容性是最好的几乎所有服务端和客户端都支持排障时不用怀疑是算法问题。推荐用RSA 2048位起步4096更安全但也更慢。如果是测试环境2048完全够用生产环境追求效率与安全的平衡一般也是2048。ECC椭圆曲线证书的优势是密钥短、握手快目前主流选择是prime256v1也就是常说的P-256。它的性能在移动端和IoT设备上有明显优势。不过前提是你的业务系统、所依赖的库必须都支持ECC否则生成出来后没有服务端能加载白忙一场。实操命令如下# RSA 2048 openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out ~/pki/private/example.key # 或者用传统参数格式 openssl genrsa -out ~/pki/private/example.key 2048 # ECC P-256 openssl ecparam -genkey -name prime256v1 -out ~/pki/private/example.key两条RSA命令的区别在于输出格式。genpkey是PKCS#8格式头部是BEGIN PRIVATE KEYgenrsa生成的头部是BEGIN RSA PRIVATE KEY。两者都能被主流服务加载但如果交给Java的KeyStore或者某些严格校验的库PKCS#8更省事推荐直接用genpkey。命令执行后建议立刻检查私钥权限chmod 600 ~/pki/private/example.key。这一步别省绝大多数后续问题都从权限太松开始。3.2 生成CSR字段填写与细节私钥就绪后就该做CSR申请了。加密理论绕得人头发麻但你只需要记住CSR就是一张“申请表”里面填着你的身份信息、公钥和你期望的证书属性由CA审核后签名。生成CSR的命令openssl req -new \ -key ~/pki/private/example.key \ -out ~/pki/certs/example.csr \ -subj /CCN/STBeijing/LBeijing/OExampleOrg/CNexample.internal这些字段的含义C是国籍、ST是省份、L是城市、O是组织名CN是最关键的字段——通用名。对服务器证书来说CN通常填域名或主机名。有几个细节容易被忽视。第一-subj参数如果不加OpenSSL会进入交互模式一个个问你国家、省份、城市、组织名称不填完不干活。但交互模式下很容易填错一层又懒得撤销重来既然都用脚本批处理了直接以-subj方式填好干净利落。第二CN字段值如果和最终访问域名不一致浏览器会报域名不匹配。比如你申请证书时CN是example.internal但实际访问地址是example.local浏览器照样打红叉。规避方法是后面用SAN扩展确保写上全部相关域名。第三邮件地址、组织单位这类属性可填可不填但千万别在CN里塞邮箱地址很多人图省事把CNadminexample.com这种写法当默认这会造成“证书是身份证书还是服务器证书”的语义混乱一部分客户端会直接拒绝。3.3 CSR审核与关键信息检查写完CSR别急着拿去签名先自己审一遍。openssl req -text -noout -verify -in ~/pki/certs/example.csr这个命令能解析CSR内容看看公钥信息、DN字段是否符合预期。里面有个很容易被忽略的细节CSR里显示的公钥长度。如果你生成私钥时手滑用了1024位这里就能直接看出来免得签完才发现。另外要检查CSR和私钥是否匹配# 检查私钥的公共部分和CSR的公共部分是否一致 openssl pkey -pubout -in ~/pki/private/example.key | sha256sum openssl req -pubkey -noout -in ~/pki/certs/example.csr | sha256sum两个哈希一致说明这把私钥对应的公钥确实在CSR里。不匹配的话签名出来的证书即使在CA那端成功了你部署时服务端加载也会报错因为私钥属于另一家人。4. CA证书创建与自签名4.1 初始化CA私钥与根证书现在进入最核心的一步自己当一回CA签出自己的根证书。这个根证书将被用来签发后续所有业务证书。首先为CA生成私钥操作逻辑跟生成业务私钥完全一样openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out ~/pki/ca/ca.key chmod 600 ~/pki/ca/ca.keyCA私钥比普通业务私钥要更长我固定用4096位毕竟它的泄露意味着整个信任链崩塌所有依赖它签发的证书都不可信。然后生成自签根证书。自签的意思是“自己给自己签”没有上级CA。命令里需要加的-x509参数表示直接输出证书而不是CSR-days指定有效期openssl req -x509 -new \ -key ~/pki/ca/ca.key \ -out ~/pki/ca/ca.crt \ -days 3650 \ -subj /CCN/STBeijing/LBeijing/OExampleOrg Root CA/CNExampleOrg Root CA这里有几处容易翻车的地方都是血泪。第一根证书的CN千万不要和业务证书的CN重复。根证书是“签发机构”的身份业务证书是“网站/服务”的身份混在一起后部分客户端在构造信任链时会把根证书当成业务证书去匹配域名导致紊乱。第二CA证书的Basic Constraints必须包含CA:TRUE。自签时OpenSSL默认会写进去但这要验证。openssl x509 -text -noout -in ~/pki/ca/ca.crt | grep -A 1 Basic Constraints输出里必须出现CA:TRUE。没有这行意味着这张证书不具备“签发下级证书”的资格用它在后面签名会失败或者说签出来的证书客户端不认。第三根证书的有效期建议10年起。内部CA一年一换信任链成本极高——每个服务、每台机器、每个客户端都要重新信任新根证书。更合理的策略是根证书设10年用它签发2~3年有效期的业务证书到期只换业务证书根证书在原地坐着不动。提示root CA证书生成后马上做一遍自检openssl x509 -in ~/pki/ca/ca.crt -text -noout。重点看Signature Algorithm是不是sha256WithRSAEncryptionOpenSSL 3.x默认Version是不是v3也就是序列号是2而不是v1。v1证书不支持扩展区没法带SAN属于老古董必须重签。4.2 用配置文件降低繁琐程度直接在命令行里写一长串参数容易出错还不好复现。我现在的做法是提前备一份OpenSSL配置文件把CA要用到的扩展项固化进去。这里给出一份我常用的CA签发配置模板路径假设为~/pki/ca/openssl.cnf[ ca ] default_ca my_internal_ca [ my_internal_ca ] dir /home/you/pki database $dir/index.txt serial $dir/serial new_certs_dir $dir/certs certificate $dir/ca/ca.crt private_key $dir/ca/ca.key default_md sha256 policy policy_loose [ policy_loose ] countryName optional stateOrProvinceName optional organizationName optional organizationalUnitName optional commonName supplied [ v3_ca ] basicConstraints critical, CA:TRUE keyUsage critical, keyCertSign, cRLSign subjectKeyIdentifier hash authorityKeyIdentifier keyid:always, issuer这份配置里刻意做了几件事policy_loose放宽了对CSR中字段的要求这样签发的证书不需要每个字段都填得满满当当basicConstraints明确了这是CA证书keyUsage限制这把私钥只能用来签证书和CRL不能拿去加密数据。注意实际生产部署请根据你自己的路径调整dir那一行。配置就位后后续所有证书签发都可以用一条命令搞定后面会提到。5. 使用CA签名从CSR到正式证书5.1 签名前配置准备业务CSR已经生成、CA根证书和私钥都在接下来就是最解气的时刻——把CSR变成正式证书。但先别急签名前还有个关键准备SANSubject Alternative Name扩展。SAN的作用是告诉客户端“本证书同时适用于以下多个域名/IP”。这是现代浏览器和服务器的硬性要求只靠CN字段已经远远不够。生成业务证书时我通常会为每个应用单独准备一个扩展文件像这样cat ~/pki/certs/example.ext EOF subjectAltName DNS:example.internal, DNS:git.example.internal, IP:192.168.1.100 keyUsage critical, digitalSignature, keyEncipherment extendedKeyUsage serverAuth EOFDNS:后面支持填多个域名IP:后面填具体IP地址。两者可混搭但注意写法不能错。如果只填了域名没填IP那么用IP地址访问服务时即使证书已安装浏览器里照样报不安全因为IP不在证书允许范围内。5.2 执行签发操作执行签发命令格式如下openssl ca \ -config ~/pki/ca/openssl.cnf \ -in ~/pki/certs/example.csr \ -out ~/pki/certs/example.crt \ -extfile ~/pki/certs/example.ext \ -days 825 \ -batch拆解一下每个参数-config指定CA配置-in输入CSR-out输出正式证书-extfile把SAN扩展文件带进去-days设有效期-batch跳过所有交互确认免得脚本中途卡住。825天是我常用的业务证书有效期比一年稍长又不足三年兼顾了轮换频率和运维压力。签发成功后立刻做两个验证动作。第一查看证书基本信息openssl x509 -in ~/pki/certs/example.crt -text -noout检查Signature Algorithm、Subject、Issuer、Validity、SAN、Basic Constraints这些关键项。发现Issuer字段不是你的CA名字说明命令串了配置签错了源排查方向要从配置文件开始。第二验证证书与私钥是否匹配openssl x509 -in ~/pki/certs/example.crt -pubkey -noout | sha256sum openssl pkey -pubout -in ~/pki/private/example.key | sha256sum这种做法在实操中比OpenSSL自带的-modulus更通用尤其针对ECC密钥对场景更可靠输出不一致就直接重来不要带病部署。5.3 证书链拼装与部署格式签发后的证书是“业务证书”它要跟CA根证书一起提供给别人验证。这个过程叫“证书链拼接”也有人叫“全链证书”。大部分服务器的做法是在TLS握手时把服务端证书和CA证书依次下发客户端自下而上校验直到信任的根为止。拼接命令非常简单cat ~/pki/certs/example.crt ~/pki/ca/ca.crt ~/pki/certs/example-fullchain.crt顺序千万别反。先自己的证书再CA证书。如果你把顺序搞反部分客户端会直接报错另一些会尝试自动重排但总会有一堆兼容性问题没必要赌这个。Nginx里的常见配置是server { listen 443 ssl; server_name example.internal; ssl_certificate /etc/pki/certs/example-fullchain.crt; ssl_certificate_key /etc/pki/private/example.key; }Tomcat或Java系组件用的则是PKCS12格式需要把证书和私钥放进一个带密码的容器openssl pkcs12 -export \ -in ~/pki/certs/example.crt \ -inkey ~/pki/private/example.key \ -certfile ~/pki/ca/ca.crt \ -out ~/pki/certs/example.p12 \ -passout pass:changeit转换前注意-certfile参数它会附带CA证书Java应用才能构建完整信任链。这个也常被漏掉导致报PKIX path building failed。6. 常见问题与排查技巧实录6.1 我踩过且大概率你也会踩的坑把实操中碰到的坑集中列一遍。签名时提示数据库锁定或找不到文件。通常是因为没有先把index.txt和serial准备好。前面提起过这两个文件没有它们openssl ca会直接罢工。临时补的话千万别用echo index.txt文件里已经有历史记录的会被冲掉。正确做法是用有内容校验的文本编辑方式增量添加记录。私钥带密码导致Nginx启动失败。Nginx在启动时需要读取私钥如果私钥有密码保护要么报Permission denied要么直接拒绝启动还不给明确原因。全局解决方案就是OpenSSL生成私钥时根本别设-aes256这类加密参数。KeyUsage和ExtendedKeyUsage打架。证书既做服务端认证又做客户端认证时extendedKeyUsage需要同时声明serverAuth和clientAuth。如果你写的扩展文件里只有一个serverAuth那么用它做客户端双向认证时服务端一验就挂。更隐蔽的是某些场景下keyUsage里没有digitalSignature但在ECDSA证书中这是必需的不然TLS握手时签名验证直接失败。SAN缺失导致的浏览器不信任。这是所有坑里最坑的一个。Chrome从某个版本起不再关心CN是否匹配只看SAN。CSR里不带SAN没关系关键是签名时-extfile必须指定。漏了这一步证书装上后浏览器依然警告NET::ERR_CERT_COMMON_NAME_INVALID。系统时间不一致导致证书立即失效。证书的notBefore字段取自生成时刻的系统时间如果CA服务器系统时间慢了10分钟签出来的证书生效时间可能晚于客户端当前时间客户端会觉得证书“还没生效”直接拒绝。排查方式是在生成机器上先同步时间。6.2 一张表搞定大部分疑难杂症现象大概率原因解决动作浏览器报NET::ERR_CERT_COMMON_NAME_INVALIDSAN缺失或不含当前域名签名时携带-extfileSAN里加对应DNS/IP部署后服务启动报权限错误私钥或证书目录权限太宽私钥600证书目录700属主改成运行用户证书链验证报unable to get issuer业务证书没有附上CA证书拼接时业务证书在前、CA证书在后Java报PKIX path building failedPKCS12缺失CA证书转换时加-certfile ca.crt客户端报证书未生效签发系统时间偏移同步NTP时间后重新签发签名时报CA certificate is invalid根证书Basic Constraints缺CA:TRUE重建根证书确认v3且含critical CA:TRUEOpenSSL 3.x报弱签名算法MD5/SHA1被禁显式指定-sha256并检查配置文件默认算法生成CSR后忘记保存私钥使用了临时目录或系统环境变量指定的路径固定工作目录每次先用pwd确认位置Nginx报SSL_ERROR_SYSCALL客户端不支持服务端所选加密套件查看OpenSSL版本和服务端支持的CipherSuite列表证书能用但浏览器显示“不是安全连接”客户端不信任内部CA需要将CA根证书导入系统/浏览器信任库6.3 两个实用的小工具操作如果涉及DNS和HTTP的验证动作日常排障我会用两个顺手的小命令。# 查看远程服务的证书链用openssl自带s_client即可 openssl s_client -connect example.internal:443 -servername example.internal -showcerts /dev/null # 验证本地证书链是否完整 openssl verify -CAfile ~/pki/ca/ca.crt ~/pki/certs/example-fullchain.crtverify输出OK才叫干净。如果报unable to get local issuer certificate那明显是CA没被信任或链没拼全。我个人在实际操作中的体会是证书报错大部分不是加密算法有多难而是管理不善和细节遗漏。把事情分解成“生成私钥→提交CSR→CA签名→部署证书”四步每一步校验一次基本能把出错的概率压到最低。这篇列出的每一个坑都是我用一次次加班换来的教训你照着走一遍流程再结合自己的场景做调整能少走不少弯路。以后不管是自签测试证书还是搭内部CA统一管理组件证书主动权都能握在自己手里。 
长河君 · 2026/10/20 14:52:08 · 阅读 1.2k OpenSSL证书签发全流程：从CSR到CA签名避坑指南
证书这东西平时用不着真到要用的时候能卡掉人半条命。尤其是自己搭的测试环境、内部服务、或者做HTTPS双向认证OpenSSL的命令来来回回就那几个但每次都能遇到点幺蛾子。要么SAN没带要么私钥权限问题要么签名算法太老直接被拒。这篇就把我从CSR申请到CA签名的完整流程掰开揉碎讲一遍重点放在踩过的坑上希望对正在折腾证书的你有点帮助。1. 项目概述与核心需求解析1.1 证书体系是什么能解决什么问题先明确一个概念数字证书本质上是“身份证明 加密钥匙包”。它解决两个问题一是证明“我是谁”二是让通信双方能安全地交换密钥。以典型的HTTPS站点为例浏览器访问一个网站时网站会亮出自己的证书。浏览器检查证书是否由可信机构CA签发、是否过期、域名是否匹配确认无误后再用证书里的公钥协商加密通道。这就是一次完整的信任链验证。具体到内部系统场景更丰富。比如公司内部搭建的Git服务器、Docker仓库、Kubernetes集群、Kafka或RabbitMQ之间的TLS加密通信这些统统离不开证书。用公开CA签吧费钱费事内网域名还可能被拒绝自己动手用OpenSSL搭一套内部CA然后签发证书就成了最务实的方案。适合读这篇的我猜主要是这几类人运维工程师要自建CA统一管理内部组件证书后端开发在调试HTTPS接口或者配置Nginx反向代理时需要一张本地证书安全测试的同学做中间人代理测试时需要伪造证书。无论哪类掌握了OpenSSL这套东西走到哪里都不会慌。1.2 为什么选OpenSSL以及你可能正在犯的认知错误市面上有CFSSL、Easy-RSA、mkcert等工具但OpenSSL到底还是绕不开的底层依赖。原因很简单几乎所有框架、服务器、语言库底层用的就是OpenSSL其他工具生成的证书最终也得以OpenSSL能解析的格式存在。很多人以为用OpenSSL只是“敲几下命令”其实不然。最容易踩坑的是对证书“格式”的三个误区。第一PEM和CRT不是两回事。PEM是Base64编码文本用记事本打开能看到-----BEGIN CERTIFICATE-----的CRT只是一种扩展名内容完全可能是PEM。很多人把.crt文件当成二进制读结果变乱码急得直跺脚其实用文本编辑器打开就对了。第二私钥绝对不要带密码生成或至少封存时再加密。内网证书尤其如此Nginx、Tomcat、Java应用加载私钥时都需要密钥库密码但很多程序不提供输入密码的参数。一旦设了密码启动服务时就会卡在密码输入阶段头大得很。生产环境如需加密保存私钥文件用单独的工具做信封加密别直接写在证书生成流程里。第三证书有效期尽量别太短。默认自签CA证书通常以365天为周期具体取决于OpenSSL配置。测试没所谓但如果是内部长期使用的根证书建议签个10年以上否则每年一续期光通知各业务方更新信任链就能烦死你。2. 环境准备与关键文件管理2.1 检查OpenSSL版本优先3.x环境这块第一个动作不是急着敲openssl req而是先看版本。openssl version实测中CentOS 7自带的通常是OpenSSL 1.0.2系列Debian 10带的是1.1.1系列而这两者的默认签名算法和加密强度都有区别。如果你用的是OpenSSL 3.xMD5、SHA1这类弱算法默认直接禁止配置不当会报错。我个人的建议统一用OpenSSL 3.x版本进行后续操作。这里有两点客观优势。一是支持现代加密套件比如TLS 1.3二是内部CA签发的证书若交给客户端验证各语言库对老版本OpenSSL生成的证书校验策略更严格容易出兼容问题新版本反而更干净。安装新版本没什么难度各平台包管理器都有注意编译安装时带上enable-fips与否看自己需求别手贱加一堆额外编译参数默认安装就够日常使用。2.2 搭建好干净的证书目录结构很多人把证书文件随便丢会带来两个直接问题权限不好控搞不清哪个私钥对应哪张证书。我的习惯是单独建一个目录专门管理内部PKI。废话不多说直接给一套我一直在用的目录骨架mkdir -p ~/pki/ca mkdir -p ~/pki/certs mkdir -p ~/pki/private mkdir -p ~/pki/crl touch ~/pki/index.txt echo 1000 ~/pki/serial这样设计的目的是把CA相关的材料根证书的私钥、自签证书、撤销列表和业务证书各服务使用的证书分开存放。后面所有证书都从certs/目录输出扫描的时候一目了然。还有一个常被忽略的点index.txt和serial是OpenSSL维护证书签发记录的数据库。没有这两个文件后续执行证书撤销、查看已签发列表等功能时会直接报错所以即便你现在不需要撤销功能也先建好放着。注意私钥目录我习惯直接设700权限。之前见过有人把私钥放在家目录下默认644权限相当于所有本地用户都能读这等于把大门钥匙放在蹭脚垫下面。chmod 700 ~/pki/private是底线操作。3. 私钥生成与CSR申请的完整实操3.1 私钥生成算法、位数与格式选择生成私钥第一个决策是用RSA还是ECC。RSA的兼容性是最好的几乎所有服务端和客户端都支持排障时不用怀疑是算法问题。推荐用RSA 2048位起步4096更安全但也更慢。如果是测试环境2048完全够用生产环境追求效率与安全的平衡一般也是2048。ECC椭圆曲线证书的优势是密钥短、握手快目前主流选择是prime256v1也就是常说的P-256。它的性能在移动端和IoT设备上有明显优势。不过前提是你的业务系统、所依赖的库必须都支持ECC否则生成出来后没有服务端能加载白忙一场。实操命令如下# RSA 2048 openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out ~/pki/private/example.key # 或者用传统参数格式 openssl genrsa -out ~/pki/private/example.key 2048 # ECC P-256 openssl ecparam -genkey -name prime256v1 -out ~/pki/private/example.key两条RSA命令的区别在于输出格式。genpkey是PKCS#8格式头部是BEGIN PRIVATE KEYgenrsa生成的头部是BEGIN RSA PRIVATE KEY。两者都能被主流服务加载但如果交给Java的KeyStore或者某些严格校验的库PKCS#8更省事推荐直接用genpkey。命令执行后建议立刻检查私钥权限chmod 600 ~/pki/private/example.key。这一步别省绝大多数后续问题都从权限太松开始。3.2 生成CSR字段填写与细节私钥就绪后就该做CSR申请了。加密理论绕得人头发麻但你只需要记住CSR就是一张“申请表”里面填着你的身份信息、公钥和你期望的证书属性由CA审核后签名。生成CSR的命令openssl req -new \ -key ~/pki/private/example.key \ -out ~/pki/certs/example.csr \ -subj /CCN/STBeijing/LBeijing/OExampleOrg/CNexample.internal这些字段的含义C是国籍、ST是省份、L是城市、O是组织名CN是最关键的字段——通用名。对服务器证书来说CN通常填域名或主机名。有几个细节容易被忽视。第一-subj参数如果不加OpenSSL会进入交互模式一个个问你国家、省份、城市、组织名称不填完不干活。但交互模式下很容易填错一层又懒得撤销重来既然都用脚本批处理了直接以-subj方式填好干净利落。第二CN字段值如果和最终访问域名不一致浏览器会报域名不匹配。比如你申请证书时CN是example.internal但实际访问地址是example.local浏览器照样打红叉。规避方法是后面用SAN扩展确保写上全部相关域名。第三邮件地址、组织单位这类属性可填可不填但千万别在CN里塞邮箱地址很多人图省事把CNadminexample.com这种写法当默认这会造成“证书是身份证书还是服务器证书”的语义混乱一部分客户端会直接拒绝。3.3 CSR审核与关键信息检查写完CSR别急着拿去签名先自己审一遍。openssl req -text -noout -verify -in ~/pki/certs/example.csr这个命令能解析CSR内容看看公钥信息、DN字段是否符合预期。里面有个很容易被忽略的细节CSR里显示的公钥长度。如果你生成私钥时手滑用了1024位这里就能直接看出来免得签完才发现。另外要检查CSR和私钥是否匹配# 检查私钥的公共部分和CSR的公共部分是否一致 openssl pkey -pubout -in ~/pki/private/example.key | sha256sum openssl req -pubkey -noout -in ~/pki/certs/example.csr | sha256sum两个哈希一致说明这把私钥对应的公钥确实在CSR里。不匹配的话签名出来的证书即使在CA那端成功了你部署时服务端加载也会报错因为私钥属于另一家人。4. CA证书创建与自签名4.1 初始化CA私钥与根证书现在进入最核心的一步自己当一回CA签出自己的根证书。这个根证书将被用来签发后续所有业务证书。首先为CA生成私钥操作逻辑跟生成业务私钥完全一样openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out ~/pki/ca/ca.key chmod 600 ~/pki/ca/ca.keyCA私钥比普通业务私钥要更长我固定用4096位毕竟它的泄露意味着整个信任链崩塌所有依赖它签发的证书都不可信。然后生成自签根证书。自签的意思是“自己给自己签”没有上级CA。命令里需要加的-x509参数表示直接输出证书而不是CSR-days指定有效期openssl req -x509 -new \ -key ~/pki/ca/ca.key \ -out ~/pki/ca/ca.crt \ -days 3650 \ -subj /CCN/STBeijing/LBeijing/OExampleOrg Root CA/CNExampleOrg Root CA这里有几处容易翻车的地方都是血泪。第一根证书的CN千万不要和业务证书的CN重复。根证书是“签发机构”的身份业务证书是“网站/服务”的身份混在一起后部分客户端在构造信任链时会把根证书当成业务证书去匹配域名导致紊乱。第二CA证书的Basic Constraints必须包含CA:TRUE。自签时OpenSSL默认会写进去但这要验证。openssl x509 -text -noout -in ~/pki/ca/ca.crt | grep -A 1 Basic Constraints输出里必须出现CA:TRUE。没有这行意味着这张证书不具备“签发下级证书”的资格用它在后面签名会失败或者说签出来的证书客户端不认。第三根证书的有效期建议10年起。内部CA一年一换信任链成本极高——每个服务、每台机器、每个客户端都要重新信任新根证书。更合理的策略是根证书设10年用它签发2~3年有效期的业务证书到期只换业务证书根证书在原地坐着不动。提示root CA证书生成后马上做一遍自检openssl x509 -in ~/pki/ca/ca.crt -text -noout。重点看Signature Algorithm是不是sha256WithRSAEncryptionOpenSSL 3.x默认Version是不是v3也就是序列号是2而不是v1。v1证书不支持扩展区没法带SAN属于老古董必须重签。4.2 用配置文件降低繁琐程度直接在命令行里写一长串参数容易出错还不好复现。我现在的做法是提前备一份OpenSSL配置文件把CA要用到的扩展项固化进去。这里给出一份我常用的CA签发配置模板路径假设为~/pki/ca/openssl.cnf[ ca ] default_ca my_internal_ca [ my_internal_ca ] dir /home/you/pki database $dir/index.txt serial $dir/serial new_certs_dir $dir/certs certificate $dir/ca/ca.crt private_key $dir/ca/ca.key default_md sha256 policy policy_loose [ policy_loose ] countryName optional stateOrProvinceName optional organizationName optional organizationalUnitName optional commonName supplied [ v3_ca ] basicConstraints critical, CA:TRUE keyUsage critical, keyCertSign, cRLSign subjectKeyIdentifier hash authorityKeyIdentifier keyid:always, issuer这份配置里刻意做了几件事policy_loose放宽了对CSR中字段的要求这样签发的证书不需要每个字段都填得满满当当basicConstraints明确了这是CA证书keyUsage限制这把私钥只能用来签证书和CRL不能拿去加密数据。注意实际生产部署请根据你自己的路径调整dir那一行。配置就位后后续所有证书签发都可以用一条命令搞定后面会提到。5. 使用CA签名从CSR到正式证书5.1 签名前配置准备业务CSR已经生成、CA根证书和私钥都在接下来就是最解气的时刻——把CSR变成正式证书。但先别急签名前还有个关键准备SANSubject Alternative Name扩展。SAN的作用是告诉客户端“本证书同时适用于以下多个域名/IP”。这是现代浏览器和服务器的硬性要求只靠CN字段已经远远不够。生成业务证书时我通常会为每个应用单独准备一个扩展文件像这样cat ~/pki/certs/example.ext EOF subjectAltName DNS:example.internal, DNS:git.example.internal, IP:192.168.1.100 keyUsage critical, digitalSignature, keyEncipherment extendedKeyUsage serverAuth EOFDNS:后面支持填多个域名IP:后面填具体IP地址。两者可混搭但注意写法不能错。如果只填了域名没填IP那么用IP地址访问服务时即使证书已安装浏览器里照样报不安全因为IP不在证书允许范围内。5.2 执行签发操作执行签发命令格式如下openssl ca \ -config ~/pki/ca/openssl.cnf \ -in ~/pki/certs/example.csr \ -out ~/pki/certs/example.crt \ -extfile ~/pki/certs/example.ext \ -days 825 \ -batch拆解一下每个参数-config指定CA配置-in输入CSR-out输出正式证书-extfile把SAN扩展文件带进去-days设有效期-batch跳过所有交互确认免得脚本中途卡住。825天是我常用的业务证书有效期比一年稍长又不足三年兼顾了轮换频率和运维压力。签发成功后立刻做两个验证动作。第一查看证书基本信息openssl x509 -in ~/pki/certs/example.crt -text -noout检查Signature Algorithm、Subject、Issuer、Validity、SAN、Basic Constraints这些关键项。发现Issuer字段不是你的CA名字说明命令串了配置签错了源排查方向要从配置文件开始。第二验证证书与私钥是否匹配openssl x509 -in ~/pki/certs/example.crt -pubkey -noout | sha256sum openssl pkey -pubout -in ~/pki/private/example.key | sha256sum这种做法在实操中比OpenSSL自带的-modulus更通用尤其针对ECC密钥对场景更可靠输出不一致就直接重来不要带病部署。5.3 证书链拼装与部署格式签发后的证书是“业务证书”它要跟CA根证书一起提供给别人验证。这个过程叫“证书链拼接”也有人叫“全链证书”。大部分服务器的做法是在TLS握手时把服务端证书和CA证书依次下发客户端自下而上校验直到信任的根为止。拼接命令非常简单cat ~/pki/certs/example.crt ~/pki/ca/ca.crt ~/pki/certs/example-fullchain.crt顺序千万别反。先自己的证书再CA证书。如果你把顺序搞反部分客户端会直接报错另一些会尝试自动重排但总会有一堆兼容性问题没必要赌这个。Nginx里的常见配置是server { listen 443 ssl; server_name example.internal; ssl_certificate /etc/pki/certs/example-fullchain.crt; ssl_certificate_key /etc/pki/private/example.key; }Tomcat或Java系组件用的则是PKCS12格式需要把证书和私钥放进一个带密码的容器openssl pkcs12 -export \ -in ~/pki/certs/example.crt \ -inkey ~/pki/private/example.key \ -certfile ~/pki/ca/ca.crt \ -out ~/pki/certs/example.p12 \ -passout pass:changeit转换前注意-certfile参数它会附带CA证书Java应用才能构建完整信任链。这个也常被漏掉导致报PKIX path building failed。6. 常见问题与排查技巧实录6.1 我踩过且大概率你也会踩的坑把实操中碰到的坑集中列一遍。签名时提示数据库锁定或找不到文件。通常是因为没有先把index.txt和serial准备好。前面提起过这两个文件没有它们openssl ca会直接罢工。临时补的话千万别用echo index.txt文件里已经有历史记录的会被冲掉。正确做法是用有内容校验的文本编辑方式增量添加记录。私钥带密码导致Nginx启动失败。Nginx在启动时需要读取私钥如果私钥有密码保护要么报Permission denied要么直接拒绝启动还不给明确原因。全局解决方案就是OpenSSL生成私钥时根本别设-aes256这类加密参数。KeyUsage和ExtendedKeyUsage打架。证书既做服务端认证又做客户端认证时extendedKeyUsage需要同时声明serverAuth和clientAuth。如果你写的扩展文件里只有一个serverAuth那么用它做客户端双向认证时服务端一验就挂。更隐蔽的是某些场景下keyUsage里没有digitalSignature但在ECDSA证书中这是必需的不然TLS握手时签名验证直接失败。SAN缺失导致的浏览器不信任。这是所有坑里最坑的一个。Chrome从某个版本起不再关心CN是否匹配只看SAN。CSR里不带SAN没关系关键是签名时-extfile必须指定。漏了这一步证书装上后浏览器依然警告NET::ERR_CERT_COMMON_NAME_INVALID。系统时间不一致导致证书立即失效。证书的notBefore字段取自生成时刻的系统时间如果CA服务器系统时间慢了10分钟签出来的证书生效时间可能晚于客户端当前时间客户端会觉得证书“还没生效”直接拒绝。排查方式是在生成机器上先同步时间。6.2 一张表搞定大部分疑难杂症现象大概率原因解决动作浏览器报NET::ERR_CERT_COMMON_NAME_INVALIDSAN缺失或不含当前域名签名时携带-extfileSAN里加对应DNS/IP部署后服务启动报权限错误私钥或证书目录权限太宽私钥600证书目录700属主改成运行用户证书链验证报unable to get issuer业务证书没有附上CA证书拼接时业务证书在前、CA证书在后Java报PKIX path building failedPKCS12缺失CA证书转换时加-certfile ca.crt客户端报证书未生效签发系统时间偏移同步NTP时间后重新签发签名时报CA certificate is invalid根证书Basic Constraints缺CA:TRUE重建根证书确认v3且含critical CA:TRUEOpenSSL 3.x报弱签名算法MD5/SHA1被禁显式指定-sha256并检查配置文件默认算法生成CSR后忘记保存私钥使用了临时目录或系统环境变量指定的路径固定工作目录每次先用pwd确认位置Nginx报SSL_ERROR_SYSCALL客户端不支持服务端所选加密套件查看OpenSSL版本和服务端支持的CipherSuite列表证书能用但浏览器显示“不是安全连接”客户端不信任内部CA需要将CA根证书导入系统/浏览器信任库6.3 两个实用的小工具操作如果涉及DNS和HTTP的验证动作日常排障我会用两个顺手的小命令。# 查看远程服务的证书链用openssl自带s_client即可 openssl s_client -connect example.internal:443 -servername example.internal -showcerts /dev/null # 验证本地证书链是否完整 openssl verify -CAfile ~/pki/ca/ca.crt ~/pki/certs/example-fullchain.crtverify输出OK才叫干净。如果报unable to get local issuer certificate那明显是CA没被信任或链没拼全。我个人在实际操作中的体会是证书报错大部分不是加密算法有多难而是管理不善和细节遗漏。把事情分解成“生成私钥→提交CSR→CA签名→部署证书”四步每一步校验一次基本能把出错的概率压到最低。这篇列出的每一个坑都是我用一次次加班换来的教训你照着走一遍流程再结合自己的场景做调整能少走不少弯路。以后不管是自签测试证书还是搭内部CA统一管理组件证书主动权都能握在自己手里。