★ FEATURED ARTICLE 1. 从需求说起什么时候需要自己生成SSL证书今天这篇东西我想了很久才决定动笔。原因很简单关于SSL证书的教程一搜一大把但绝大多数都停留在复制粘贴跑通的层面真正把每一步的来龙去脉、参数含义、坑在哪里讲明白的确实不多。先说清楚这篇文章聊的是什么。标题叫SSL证书生成明细文档它并不是某一家云厂商的专属操作手册而是面向开发者和运维人员的一整套证书生成与落地方案。从最初的密钥生成、CSR创建到证书签发、格式转换再到部署校验和排错整个过程我都会带着实际命令和真实业务场景走一遍。我最早接触SSL证书是在一个对外接口服务的联调现场。当时对方要求必须启用HTTPS我临时搜了一个教程生成了自签名证书结果接口是通了但对方的客户端程序直接抛异常——证书链不完整。那一次排查花了大半天后来发现是证书只配了叶子证书缺少根证书链。现在回想很多基础概念其实一开始就没吃透。聊几个最常见的使用场景看看你是不是也踩在同样的位置上开发环境联调本地服务需要启HTTPS又不想麻烦CA机构签发真实证书这时候自签名证书或者本地信任证书是首选。麻烦的地方在于每个环境都要重新生成一版而且要确保所有客户端都信任这个证书。内网系统加密一些内部管理系统、监控平台、API网关部署在内网流量经过中间代理时容易被明文截获。给这些系统配上SSL证书即使不对外也能显著提高安全性。测试与自动化环境CI/CD流水线里经常需要模拟HTTPS环境自动化测试脚本要能正常走完TLS握手这时候就需要能快速生成、快速销毁的证书方案。申请正式证书前的演练向CA机构提交CSR之前最好先自己走一遍完整的生成流程避免因为字段格式、密钥算法或SAN配置不对导致审核失败。这篇文章适合谁如果你是刚入门的新手想搞清楚OpenSSL命令到底在做什么每个参数为什么这么写你能从这里找到答案。如果你已经写过几个证书了但遇到了证书不信任钥匙串打不开格式总转不对这类问题那直接跳到常见问题那一章大概率能省你半天时间。2. 生成前的规划环境准备与参数设计2.1 工具链选择以OpenSSL为主力生成SSL证书的工具其实不算少但我个人强烈建议把OpenSSL作为默认选择尤其当你需要批量操作或者写脚本自动化时OpenSSL的命令行能力几乎是不可替代的。另外两个常见工具也提一嘴如果你使用的是某编程语言官方运行时比如某些企业级运行时环境那么可以用自带工具生成密钥对和证书请求如果你想要一条命令搞定本地开发证书有一些社区工具可以自动生成并加入系统信任区。但对于生产环境或者需要自定义证书扩展的场景这些工具往往不如OpenSSL直观参数也不够灵活。以最常见的操作环境为例——一台安装了通用Linux发行版的服务器基本都自带OpenSSL或者可以通过包管理器轻松安装。macOS虽然默认版本可能在更新上滞后但日常使用足够。Windows下我建议把OpenSSL装好并加入PATH这样脚本跨平台时不需要为每个系统单独适配。我提一个很多教程不会说的细节执行openssl version时注意看一下版本号。OpenSSL 3.0 和 1.1.x 在命令行为上有些细微差别最典型的是默认摘要算法从SHA-1迁移到了SHA-256部分旧教程里的参数已经不再推荐。而且有些发行版默认配置文件路径不一致会对生成的证书扩展项产生影响。2.2 密钥算法与长度怎么选SSL证书的核心逻辑很好理解用一个配对的密钥——私钥和公钥——来实现加密与签名。私钥保存在服务器上绝不能泄露公钥放进证书里随证书一起发给客户端。这个原理和现实生活中锁和钥匙的模型类似只不过在SSL里锁是公开的钥匙是私密的。当前主流算法有两个选择时主要看你的实际场景RSA兼容性最好几乎所有客户端和环境都支持。密钥长度建议2048起步4096安全性更高但握手性能会有轻微损耗。如果处理的连接量很大且客户端老旧用2048是比较平衡的选择。ECC椭圆曲线密钥短、性能好同样安全强度下密钥长度远小于RSA。例如prime256v1跟RSA-3072的安全等级大致相当。但如果你的客户端环境非常老旧可能存在兼容性问题。以实际部署为例我建议对外服务的Web服务优先使用ECC握手速度快、省CPU对老系统做兼容时再用RSA 2048或3072。很多CA机构目前签发的证书也已经支持ECC密钥。密钥文件生成后立刻检查一下权限chmod 600 key.pem是底线。私钥等于你服务器的身份证钥匙泄露的后果比证书被吊销严重得多。2.3 证书字段的命名学问生成证书之前需要规划证书里要填哪些字段。这些字段在CSR中体现最终会写入正式证书。常见的字段如下C国家/地区填写两位国家代码。要注意不是所有用户都填写权威代码有些内网环境可以填CN真实场景遵循对应规则即可。ST州/省填省份或州名。L城市地级市。O组织公司或组织名称。OU组织单位具体部门比如技术部。对个人开发者可以不填。CN通用名这是老版本客户端最看重的字段历史上用于表示证书绑定的域名。但现代浏览器和操作系统早已不依赖CN来校验域名而是看SAN扩展项。所以你在填CN时写主域名就好别指望它替代SAN。我会额外强调一下SANSubject Alternative Name。这里很多新手吃亏。SAN是X.509证书里的一个扩展项用来明确定义证书到底对哪些域名和IP生效。现代TLS客户端包括Chrome、Firefox、Safari以及主流编程语言的安全库在校验证书域名时只认SAN不认CN。你可以在同一个证书里放多个域名比如DNS:www.example.com DNS:example.com DNS:api.example.com IP:192.168.1.10这样一份证书就能覆盖多个站点和服务。配置OpenSSL时可以直接在命令行用-addext参数来指定SAN避免为每条命令写独立的配置文件。这个方法比较省事但记住选项中每添加一个域名都要用逗号连接。3. 实操手把手生成一套完整SSL证书3.1 第一步生成服务端私钥现在开始实际操作。我假设你已经安装好了OpenSSL并且在一个独立的目录里做实验比如/opt/certs/demo。先生成私钥。如果决定用RSA可以执行openssl genrsa -out server.key 2048这条命令的关键是一个随机数文件和密钥长度。密钥生成会短暂占用CPU资源在大规模批量生成时可以分批次执行避免服务器负载飙升。这里我想多说一句如果你使用的是需要密码短语保护的私钥通常会在生成时加上-aes256参数。这样做的好处是就算私钥文件被复制走了拿不到密码的人也无法加载它。坏处是Web服务器在重启时你需要手动输入密码或者在启动脚本里以不安全的方式存储密码——这反而会带来更多的安全隐患。所以生产环境Web服务器所使用的私钥大多数情况下不设置密码短语而是靠文件系统权限来控制访问。这是我实际摸爬滚打后觉得最稳妥的方案。做密码保护只适用于线下存档或一对一的密钥分发场景。如果要用ECC则执行openssl ecparam -genkey -name prime256v1 -out server.key生成后可以用openssl rsa -text -in server.key或openssl ec -text -in server.key检查一下。确认私钥没被加密也不需要密码后直接修改权限。chmod 600 server.key这一步不能省。某次我查看某同事的服务器配置发现私钥文件的权限是644整个项目组的人都能读等于把大门钥匙贴在门上。3.2 第二步生成CSR证书签名请求有了私钥下一步是生成CSR。这个文件可以理解为证书申请书它向CA机构说明你想要一张什么样的证书。如果只是做自签名你完全可以跳过CSR直接生成自签名证书。但我们先把标准流程走完因为正式申请CA证书时CSR是必须提交的。使用交互方式的完整命令是openssl req -new -key server.key -out server.csr然后按提示填写各个字段。如果你不想交互一次性参数写清楚更高效openssl req -new -key server.key -out server.csr \ -subj /CCN/STBeijing/LBeijing/OExample Inc/OUIT/CNwww.example.com这里-subj的格式是斜杠分隔的键值对顺序无所谓但CN必须准确。万一填写错误不需要重新生成私钥只需要重新生成CSR即可——这是很多人没走通的弯。同时强烈建议在生成CSR时直接加上SAN扩展参数。虽然部分CA会在后台帮你补但自己写清楚审核会更顺畅openssl req -new -key server.key -out server.csr \ -subj /CCN/STBeijing/LBeijing/OExample Inc/CNwww.example.com \ -addext subjectAltNameDNS:www.example.com,DNS:example.com,DNS:api.example.com执行完可以用下面的命令检查CSR里的内容特别要注意SAN是否正确拼写、域名大小写是否统一openssl req -in server.csr -text -noout证书域名的大小写其实不敏感但真实使用时需要注意统一成小写能避免很多奇怪的匹配问题。如果你有多个域名尽量把主域名放在SAN列表的第一个。3.3 第三步自签名证书的两种生成方式如果仅在测试或内网环境使用不需要找外部CA自签名就够了。但自签名证书有一个天然短板它没有上级CA的担保。客户端除非显式信任这份证书否则会直接拒绝握手。自签名证书的生成方式我分两种讲各有适用场景。第一种一条命令直接生成适合快速测试openssl req -x509 -newkey rsa:2048 -sha256 -days 365 \ -keyout server.key -out server.crt \ -subj /CNwww.example.com \ -addext subjectAltNameDNS:www.example.com,DNS:example.com注意这里的-x509表示直接输出自签名证书。-days 365指定有效期为一年。-sha256明确摘要算法。如果省略某些旧版本会默认使用SHA-1现在已经被主流系统标记为不安全。第二种先用CSR再做签署适合你在实验完整的CA流程openssl x509 -req -in server.csr -signkey server.key \ -days 365 -sha256 -out server.crt \ -copy_extensions copy-copy_extensions copy这个参数是说把CSR里带的SAN扩展复制到最终证书里。如果你漏写这个参数生成的证书里不会包含SAN到时候域名校验一定会失败。生成后用下面的命令检查证书openssl x509 -in server.crt -text -noout重点关注两处Subject字段里的CN是否对X509v3 Subject Alternative Name是否包含了所有需要保护的域名。这两处错了证书到浏览器就是不信任或域名不匹配的直接原因。3.4 第四步自建CA并签发证书自签名证书在实际部署中会频繁遇到信任问题每台客户端机器都得手动导入证书在移动端设备上操作尤其麻烦。如果想要一个更接近正式环境的体系可以自己搭一个小型CA让团队所有机器都信任这唯一的根证书然后动态签发服务器证书。这一步的操作我先给出根CA证书生成命令openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 \ -keyout ca.key -out ca.crt \ -subj /CNMy Test CA/OExample Inc根CA的私钥建议用4096位有效期可以放长到十年但实际管理时每年轮换一次更安全。根CA私钥的存放位置一定要独立最好离线保存。某次实践中我处理的测试环境因为根CA私钥被误删导致所有已签发证书全部面临失效只能批量重新签发这个教训让我后来把根CA私钥的备份提到了最高优先级。然后创建一份服务器证书的扩展配置文件文件名我用server_ext.cnf内容如下[ v3_req ] basicConstraints CA:FALSE keyUsage digitalSignature, keyEncipherment extendedKeyUsage serverAuth subjectAltName alt_names [ alt_names ] DNS.1 www.example.com DNS.2 example.com DNS.3 api.example.com这个配置文件体系比较完整地定义了证书的用途和域名列表。接下来用根CA签发服务器证书openssl x509 -req -in server.csr \ -CA ca.crt -CAkey ca.key \ -CAcreateserial -days 825 \ -sha256 -out server.crt \ -extfile server_ext.cnf -extensions v3_req这里-CAcreateserial会生成一个序列号文件用于追踪CA签发了哪些证书。以后每次签发新证书时它会自动递增序列号防止同一序列号被重复使用。最终你会得到一组文件ca.crt根证书分发给所有客户端加入受信任的根证书存储。server.key服务器私钥只保留在服务器上。server.crt服务器证书包含公钥和身份信息。实际的Web服务器配置里往往还需要将服务器证书和CA证书合并成一个证书链文件。合并命令也很简单cat server.crt ca.crt server-chain.crt顺序不能反服务器证书在前CA证书在后。如果你有中间CA就依次拼接叶子节点在最上面。3.5 第五步证书格式转换实战OpenSSL默认输出的是PEM格式——纯文本Base64编码阅读性好。但很多应用场景需要其他格式。最典型的是PKCS#12PFX格式它把服务器证书和私钥打包进同一个加密容器常用于Windows生态、某些商业中间件和移动App。生成命令openssl pkcs12 -export \ -in server-chain.crt -inkey server.key \ -out server.p12 \ -name myserver \ -password pass:YourPassword-name设置容器内条目的友好名称-password指定导出密码在实际项目里不要用弱密码。另一种常见需求是转换为DER格式一种二进制ASN.1编码openssl x509 -in server.crt -outform DER -out server.cerJava技术栈一般使用JKS格式但Java 9之后推荐直接用PKCS#12所以不再建议把PEM转成JKS。我见过太多因为JKS密码过期导致应用启动失败的案例改用PKCS#12后这种问题绕开了。关于格式转换我一直强调每个团队应该提前约定一套统一的后缀和格式规范不要今天发PEM明天发PFX。否则在交接时很可能出现拿到的PFX里根本没带私钥这种低级的错误——不是转换命令不对而是操作时不小心导出了不带私钥的证书。4. 部署与校验让证书真正生效4.1 服务器配置与私钥的关联生成证书只是完成了第一步。证书文件只有在正确部署到Web服务器后才能提供加密通信能力。在典型的Web服务器配置里需要指明两个文件的路径证书链文件和私钥文件。这里我以常见的开源Web服务器为例子server { listen 443 ssl; server_name www.example.com; ssl_certificate /etc/ssl/server-chain.crt; ssl_certificate_key /etc/ssl/server.key; }如果你是其他服务器软件核心思路都差不多。要点是把证书链文件放到位并把私钥路径配置正确权限保持600。有些服务器配置需要你把证书和密钥写进一个带密码的文件这类场景直接对应前面说的PKCS#12密码放置方式需要额外注意。部署完成后重启服务并检查日志。注意证书文件更新后部分服务需要重新加载配置才能生效。有的服务器在服务启动时读取证书也有的在每次新建连接时读取如果你发现修改证书后仍然在用旧证书多半是进程没重载或者证书路径被系统缓存了。4.2 用openssl命令做自检部署完后在服务器本机先用openssl s_client做一个快速自检openssl s_client -connect 127.0.0.1:443 -servername www.example.com如果返回结果里有Verify return code: 0 (ok)说明证书链验证通过。如果返回的是自签名证书特有的错误在测试环境可以接受但如果线上出现就要认真排查证书链或信任库配置。想要看双方协商出的加密协议和密码套件可以使用openssl s_client -connect 127.0.0.1:443 \ -tls1_3 -brief这行命令会简洁列出TLS版本、密码套件和证书基本信息。生成环境里TLS 1.2和1.3是主流尽量不要再开TLS 1.0和1.1。完全模拟浏览器域名校验过程需要同时指定域名参数openssl s_client -connect www.example.com:443 \ -verify_hostname www.example.com \ -verify_ip 127.0.0.1 2/dev/null这样可以看到证书和域名、IP是否匹配。在很多多域名证书的场景这个命令能找准到底是哪个域名没写进SAN。外部站点校验就交给在线检测工具或者使用其他命令行工具发起请求来判断。如果你搭建的HTTPS服务需要同时支持HTTP/2证书要求也基本一致无非是SAN要写全。4.3 信任链的完整判断方法判断证书是否被信任本质上是看签发它的根证书是否在客户端信任库里。如果搭建了自建CA你需要把根证书分发到每个客户端。桌面浏览器把根证书导入系统受信任根证书存储。移动设备无论如何要安装到CA证书区域而不是用户证书区域。编程环境设置环境变量或信任库路径让语言运行时找到根证书。分发之前用下面的命令验证证书链拼接是否正确openssl verify -CAfile ca.crt server-chain.crt如果出现server-chain.crt: OK说明链是完整的。一旦这条命令报错直接聚焦检查拼接顺序或CA证书是否存在。我自己遇到过最费解的场景证书链文件没有问题本地浏览器也信任但某编程语言客户端始终报unable to get local issuer certificate。后来发现是那个客户端运行时根本不去读操作系统默认信任库而是自己维护了一份CA列表。这种环境不在少数所以排查一定要顺着客户端的信任体系走不能只看服务端。5. 常见问题与排查实录5.1 报错速查表我把这些年遇到的典型报错整理成一张速查表每个场景都对应一个最常见的元凶。报错信息常见原因处理办法self-signed certificate服务端用了自签名证书客户端不信任使用自建CA签发的证书或把根证书安装到客户端信任库Hostname mismatch证书SAN里没有包含访问的域名重新生成证书把完整域名列表写入SANunable to get local issuer certificate证书链不完整或缺少根证书拼接完整证书链cat server.crt ca.crt chain.crtcertificate has expired证书有效期过了或系统时间不对检查服务器时间重新签发证书key values mismatch私钥与证书里的公钥不对应找到同一批生成的私钥文件或重新生成密钥对和证书PEM_read_bio:bad base64 decode文件格式错误有可能被换行符或文本编辑破坏用openssl x509 -text检查文件完整性重新生成特别强调一下key values mismatch这个问题。它不像其他报错那样常见但一旦出现会让人特别困惑。原因通常是你替换了私钥文件但证书还是旧证书。用下面的命令分别计算公钥指纹再比对openssl x509 -in server.crt -pubkey -noout | openssl md5 openssl pkey -in server.key -pubout | openssl md5两行结果一致说明私钥和证书匹配。不一致就说明你们不是一对。5.2 私钥密码导致的启动失败一个非常容易忽视的坑生成私钥时用了密码短语然后Web服务器在启动时因为无法读取私钥而报错。几乎所有现代Web服务器都不支持在配置文件中明文写私钥密码启动时也不会交互式提示输入密码所以会造成配置看起来没问题但服务就是起不来的现象。我建议Web服务器专用私钥一律不加密文件权限锁死到600。如果真要保护文件考虑在操作系统层面做目录加密或者放到安全存储里。线下备份的私钥副本再考虑加密码保护两者都不是一回事。5.3 多域名证书的SAN遗漏有些朋友明明照着文档写了SAN但实际访问副域名时还是报证书不匹配。多数情况是生成证书时没有成功把扩展项复制进去。尤其是使用openssl x509 -req签署CSR时-copy_extensions copy没加或者自建CA的扩展配置文件里没有写全alt_names证书签发出来之后就成了只有CN没有SAN的残缺证书。检查证书里的SAN是否完整一条命令就够openssl x509 -in server.crt -noout -ext subjectAltName输出里应该有DNS:www.example.com这样的条目。如果输出为空那就说明扩展丢了返工重新签。有一种情况更隐晦你在SAN里写了两个完全相同的域名或像*.example.com和example.com混用时有些客户端对通配符的匹配规则执行得比预期严格。尽量避免把通配符和具体域名混在同一个证书里能用精确域名就写精确域名。5.4 环境隔离开发、测试与生产使用不同证书我推荐在所有团队里坚持一条纪律开发、测试、生产使用完全独立的三套证书体系。开发环境本地随便自签或者每个开发者在机器上安装同一个团队的测试根证书。测试环境使用自建CA体系所有测试机统一信任同一个根CA方便批量签发和轮换。生产环境从合法CA机构申请证书根证书天然被所有客户端信任。不要图省事把生产证书复制到开发环境使用。一旦有人不小心把生产环境私钥dump到日志或网盘等于把生产证书的私钥交出去了。而把开发用的自签名证书放到生产环境又会导致用户端出现不信任警告。环境隔离这件事做得越早后面省事越多。5.5 证书轮换的平滑操作证书到期是必然事件。等到浏览器出现红色报错再去更换已经晚了。我也犯过类似的错误——一个内部系统证书到期因为没有加监控导致早上八点开始运维部电话被打爆。我的建议是从生成证书那一刻就养成为每条证书设置日历提醒的习惯。如果是自建CA签发的在证书到期前一个月重新生成一份如果是CA机构购买的证书提前两周提交续期。更换时注意先备份旧证书和旧私钥。新证书先放到临时目录用openssl verify验证。修改服务器配置指向新文件。平滑重载服务观察日志。用外部检测工具确认生效。如果同时要更换私钥还需要检查代码里是否存在硬编码的证书指纹或者固定公钥校验逻辑否则即使服务端换了新证书客户端仍然会因为指纹不匹配拒绝连接。6. 从生成到维护养成一套自己的习惯SSL证书生成这件事单个步骤都不难麻烦的是整个生命周期里很多细节容易被忽略。我个人这些年养成的一套习惯也许可以给大家做参考。一切文件都有固定目录。我习惯把每个域名或服务的证书放在一个独立目录目录内统一命名为server.key、server.crt、ca.crt、server-chain.crt有历史版本再指导出快照存档。这样无论自己看还是后来接手的人看一眼就能定位。私钥绝不进版本库。就算私钥文件加了密码也不要提交进代码仓库。团队里一旦有人把私钥误提交后不管有没有泄露迹象最稳的做法是立刻重新生成证书并报废旧私钥。数据是否泄露是一回事信任体系不能留下隐患。给证书建立清单。我维护了一个简单的表格记录每个证书的作用、签发对象、绑定域名、有效期、部署位置、到期日。每个月定时巡检一遍。没有太花哨的工具电子表格已经足够。掌握好批量签发的脚本。当你要签发一批证书时不要再手动一条条执行。写个简单的循环脚本把域名列表作为输入自动生成key、CSR和证书。初始搭建的时间成本很低但后续每次维护都会节省数倍时间。最后还是要强调无论你生成的是自签名证书还是CA签发的正式证书动手前想清楚这个证书要给谁用、有效期多久、绑定哪些域名、部署在哪台机器。这四个问题想清楚后面的命令只是顺着输出的过程。证书这行没什么玄学多踩几次坑把这些判断和经验写进自己的文档里后面就不会再慌。
阅读完成 · 觉得有帮助？
