申请SSL证书时CSR文件怎么生成，填错信息会有什么影响？

chinaz

申请SSL证书时CSR文件怎么生成，填错信息会有什么影响？

chinaz 初级会员萌新站长

发布于 2026-10-27 12:36 ·9 浏览 ·12 回复

# SSL证书 # CSR生成 # OpenSSL # HTTPS配置 # 域名证书

内容摘要

用 OpenSSL 一条命令可生成含 SAN 的 CSR，须确保 CN 写主域名、SAN 列全所有需保护域名；CN 或 SAN 填错会导致审核退回、签发失败或浏览器域名不匹配，其余身份字段对 DV 证书基本无影响，对 OV/EV 证书可能致

CSR 文件一条 OpenSSL 命令就能生成，真正要盯死的是 CN 和 SAN 两个字段：CN（Common Name，通用名）必须写主域名，SAN（Subject Alternative Name，备用名称）要把 www 等所有需要保护的域名全部列上。这两个字段填错，最直接的后果是 CA 审核退回、证书签发失败，或者证书签下来后浏览器直接报证书域名不匹配。

CSR 文件是什么，生成时到底填了什么

结论：CSR（Certificate Signing Request，证书签名请求）是一个只包含公钥和身份信息的文本文件，不包含私钥，交给 CA 就是为了换取签名证书。

生成 CSR 时你实际填的是 7 个字段：C（国家，两字母代码如 CN）、ST（省份）、L（城市）、O（组织名）、OU（部门）、CN（通用名，写主域名）、以及 SAN 里的域名列表。CA 只从这些字段里取信息写进证书，域名匹配靠 CN + SAN，身份信息靠 O/OU/C/ST/L。私钥始终留在你自己的服务器上，CSR 丢了、泄露了都不影响私钥安全——但私钥泄露就必须吊销证书重签。

用 OpenSSL 生成 CSR 的完整命令是什么

结论：OpenSSL 1.1.1 及以上版本，一条命令同时生成私钥和带 SAN 的 CSR，不需要交互式输入。

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/C=CN/ST=Zhejiang/L=Hangzhou/O=Example Tech Co Ltd/OU=IT/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

关键参数说明：-newkey rsa:2048 表示同时生成 2048 位 RSA 私钥（CA/B 论坛基线要求最低 2048 位，也可用 ECC 的 -newkey ec -pkeyopt ec_paramgen_curve:P-256）；-nodes（等价 -noenc）表示私钥不加密，方便 Nginx/Apache 直接读取；-addext 附加 SAN 扩展，老版本 OpenSSL 不支持该参数，需要写进配置文件再配 -reqexts。

生成后务必自检两条命令：

openssl req -in example.com.csr -noout -text          # 检查 CN 和 SAN 是否完整
openssl req -in example.com.csr -noout -verify        # 校验 CSR 签名完整性

哪些字段填错影响大，哪些影响小

结论：CN 和 SAN 填错是致命的，C/ST/L/O/OU 填错对 DV 证书基本无影响，对 OV、EV 证书会导致审核退回。

按影响从大到小排：CN 写错域名 → 证书直接失效；SAN 漏写 www 或漏写子域名 → 未被覆盖的域名访问报错；O（组织名）与营业执照不一致 → OV/EV 证书在人工核验环节被拒；OU、L、ST 拼写不规范 → DV 证书照发，但信息会原样显示在证书详情里，客户点开能看到。另外注意 CN 长度上限 64 字符，C 必须填标准的两字母国家代码，写“China”会被 CA 直接打回。

还有一条容易被忽略：Chrome 58 起已不再校验 CN，只认 SAN。也就是说 CSR 里 CN 写对了但 SAN 为空，签出来的证书在现代浏览器里照样报 NET::ERR_CERT_COMMON_NAME_INVALID。所以 -addext 那一段千万不能省。

域名填错会出什么错，怎么补救

结论：证书还没签发就重新生成 CSR 重提最快；已经签发只能申请重新签发，已部署的证书必须同步替换。

具体表现：域名不匹配时浏览器报 NET::ERR_CERT_COMMON_NAME_INVALID，curl 报 SSL: no alternative certificate subject name matches target host name，Postman、App 端、支付回调全部连带失败。补救路径是登录 CA 控制台，在证书签发前重新上传 CSR 即可，多数 CA 允许免费重签；签发后发现错误，走“重新签发（Reissue）”流程，旧证书吊销或作废。另外提醒通配符：*.example.com 只覆盖一级子域名，不覆盖 example.com 本身，也不覆盖 a.b.example.com，申请时把根域名一并写进 SAN。

私钥和 CSR 的对应关系最容易出什么事故

结论：同一个私钥可以对应多张 CSR，但证书只能和生成 CSR 时用的那把私钥搭配，混用部署当天就会报错。

上线前用两条命令核对是否配对：

openssl x509 -noout -modulus -in example.com.crt | openssl md5
openssl rsa -noout -modulus -in example.com.key | openssl md5

两个 MD5 值一致才算配对成功，ECC 证书改用 openssl pkey -pubout 比对公钥。常见事故是测试环境签的证书配生产环境新生成的私钥，报 key values mismatch，排查一小时起步。

总结一句：CSR 本身只是一段可以被反复重新生成的公开信息，生成成本几乎为零，但 CN 与 SAN 必须一次写全，O/OU 字段在 OV、EV 场景下必须与营业执照逐字一致。命令记住 -subj 定身份、-addext 定域名，生成后用 -text 复核一遍，能省掉绝大多数返工。签发被退回的具体报错，可以贴到 GJ站长论坛的问答版块，把 CA 返回的原文和 CSR 的 -text 输出一起给出，定位通常几分钟就够。

本文转载自 GJ站长论坛，原文地址：https://www.gj0.com/thread-2621.html
转载请注明出处，版权归原作者所有。

上一篇SSL证书格式pem、pfx、crt之间如何互相转换… 下一篇Nginx配置SSL证书的完整步骤与常见报错排查。

全部回复 12

阿乐资深会员 1楼 2026-10-27 12:48

CN 和 SAN 确实是唯一致命的两个字段，但更该养成习惯的是“签下来先自检再上线”，比 CSR 填错更常见的事故是私钥和证书配不上，以及证书链顺序装反。

补充几个你这套流程里值得固定下来的点。一是你结尾说的 C 字段，OpenSSL 本身不做校验，但 CA/B 要求两字母国家码，填“China”大概率在 CA 审核环节被打回或强行改成 CN，DV 证书虽然形同虚设，也别给自己找麻烦。二是通配符千万别写成 *.example.com 就完事，它不覆盖裸域，SAN 里必须同时列 DNS:example.com,DNS:*.example.com，这是排名第一的翻车点。三是签发后一定做配对校验：openssl x509 -noout -modulus -in cert.pem | md5sum 和 openssl rsa -noout -modulus -in example.com.key | md5sum 两条结果必须一致；Nginx 的 ssl_certificate 指向 fullchain，顺序是站点证书在前、中间证书在后，装反了安卓和老版本浏览器会直接报错。

另外 -nodes 生成的私钥是明文的，落地后立刻 chmod 600，所属用户给 Nginx 的运行账号即可，别图省事放到家目录下还带 644。用 ECC 的话，P-256 兼容性现在没问题，握手开销还更小，新站可以直接上。

延伸一句：做 reissue 或续期时别复用旧 CSR，尤其换了 CN 或增减 SAN 之后，旧 CSR 里的扩展字段会原样带过去，务必重新生成并走一遍上面的自检。

juming 作者初级会员 #3372 2楼 2026-10-27 12:57

阿乐：CN 和 SAN 确实是唯一致命的两个字段，但更该养成习惯的是“签下来先自检再上线”，比 CSR 填错更常见的事故是私钥和证书配不上，以及证书链顺序装反。补…

@阿乐你这套思路我完全认同，配对校验和链顺序确实是上线前最容易翻车的地方，但有个细节得纠正一下：-modulus 对比只对 RSA 有效，ECC 证书照这个法子验等于没验。

EC 私钥和证书都没有 modulus 这个概念，两条命令输出都是空的，md5sum 全是 d41d8cd9...，看着"完全一致"，实际上什么都没校验到。ECC 得换成公钥比对：openssl x509 -in cert.pem -noout -pubkey | openssl md5 对 openssl pkey -in example.com.key -pubout | openssl md5，两边一致才算配对上。既然你说新站直接上 P-256，这个坑基本是必踩的。

另外配对校验其实可以提前到 CSR 阶段做，openssl req -in example.com.csr -noout -modulus | md5sum（ECC 同样换成 -pubkey），和私钥一比就能确认，不用等 CA 签发回来才发现私钥生成到别处去了——尤其是多台机器上批量签的时候。

线上链验证我习惯再补一条 openssl s_client -connect example.com:443 -servername example.com -showcerts，看末尾 Verify return code: 0 才算过；本地 openssl verify -CAfile fullchain.pem cert.pem 通过但线上仍报错的情况，多半是服务器配的还是旧 fullchain 没 reload。

再提一个你没说到的：IDN 域名（中文域名）在 SAN 里必须写 punycode 形式 DNS:xn--xxx.com，直接写中文大概率被 CA 拒或签发后匹配失败，这个出错率不比通配符低。

满月居于空萌新站长 #3373 3楼 2026-10-27 13:11

juming：@阿乐你这套思路我完全认同，配对校验和链顺序确实是上线前最容易翻车的地方，但有个细节得纠正一下：`-modulus` 对比只对 RSA 有效，ECC 证书照这…

-modulus 那条我认错，ECC 上确实是拿空结果对空结果：两边输出都是空串，md5 全是 d41d8cd9...，脚本里判“一致”然后打印个 OK，等于什么都没验，还比不验更危险——因为人看到 OK 就不查了。

所以配对校验干脆统一成一条路：openssl req -in example.com.csr -noout -pubkey | openssl md5 对 openssl pkey -in example.com.key -pubout | openssl md5。-pubkey/-pubout 输出的是 SubjectPublicKeyInfo，RSA、ECC、Ed25519 全都通吃，不用按算法分支写，也顺手把你说的“提前到 CSR 阶段”落了地，私钥生成到别的机器上这种事当场就暴露。

s_client 那条我补两点：-servername 千万别省，不带的话在老架构上很容易命中默认 server 块，验到的压根不是这张证书；想更严格可以直接加 -verify_hostname example.com -CAfile fullchain.pem，域名和链一次过。IDN 用 punycode 这条我完全同意，实操我一般 idn2 example.com 先转好再往 SAN 里贴，顺带提醒一句：IDN 的通配符 SAN 也只能写 DNS:*.xn--xxx.com，写 U-label 的通配符同样会被拒。

最后接你那句线上验证——openssl verify 过了但浏览器还报错，除了没 reload，还有种情况是 reload 了但 old worker 没退干净，nginx -s reload 之后确认下进程。文件换完记得 chmod 600 再 reload，别顺序搞反导致新 worker 起不来。

四大皆空正式会员萌新站长 #3380 4楼 2026-10-27 13:26

满月居于空：`-modulus` 那条我认错，ECC 上确实是拿空结果对空结果：两边输出都是空串，md5 全是 `d41d8cd9...`，脚本里判“一致”然后打印个 OK…

统一成 SPKI 比对这条我同意，只要再做两处小改动，它就能直接写进上线脚本：第一，把输出赋给变量后先判断非空（[ -n "$pub" ]），否则路径写错、算法不支持时又会变成空值对空值，脚本仍会打印 OK，这个坑只是换了个地方；第二，哈希改 sha256sum，虽然这里只做指纹比对、md5 不算安全用途，但没有理由留着它。更省事的做法是直接 diff <(openssl req -in x.csr -noout -pubkey) <(openssl pkey -in x.key -pubout)，靠退出码判断，连哈希都不用算。

reload 后的旧 worker 之所以还在用旧证书，是因为证书在 worker 启动时就已读进内存，加上 keep-alive 和 websocket 长连接会把旧 worker 的寿命拖得很长。配置里加一条 worker_shutdown_timeout 10s; 能强制收尾，reload 后到 error.log 里确认出现 “worker process ... exited”，再通知客户或切换流量，不要只看 nginx -t 返回 OK。

s_client 建议再加 -verify_return_error，验证失败时直接返回非零退出码，脚本靠退出码判断，而不是 grep “Verify return code”。

最后一个顺序坑：先 chmod 600、再 nginx -t、最后 reload，反过来的话新 worker 读不到私钥会启动失败，而老 worker 还活着，监控一切正常，这种最难查。

满月居于空萌新站长 #3384 5楼 2026-10-27 13:36

四大皆空：统一成 SPKI 比对这条我同意，只要再做两处小改动，它就能直接写进上线脚本：第一，把输出赋给变量后先判断非空（`[ -n "$pub" ]`），否则路径写错、…

这四点我都收，但有两处直接照抄会踩坑：一是 diff <(...) 依赖 bash 的进程替换，脚本头写成 #!/bin/sh（dash）会直接报语法错误；二是 worker_shutdown_timeout 生效后，你到 error.log 里根本看不到 worker process ... exited，因为它是 notice 级别，而 error_log 默认只记 error，得临时把级别调到 notice，或者更干脆直接 ps -ef | grep "nginx: worker"，看旧 PID 有没有消失。

脚本那段的真正前提是 set -euo pipefail。少了 pipefail，openssl ... | sha256sum 里 openssl 失败、管道整体仍返回 0，你那个 [ -n "$pub" ] 就判断不到；所以要么先单独赋值再判空，要么用 diff 时写成 if ! diff -q <(...) <(...) >/dev/null; then exit 1; fi——set -e 下裸 diff 返回 1 会把脚本直接中断，报错信息还很难看懂。

私钥权限这点再补一句：Nginx 是 master 以 root 读私钥、worker 降权跑，所以 chmod 600 配 root:root 才是对的，别顺手 chown 给 www-data，那是把权限放大而不是收紧。-verify_return_error 建议和无条件加上的 -CAfile fullchain.pem 一起用，不带显式 CA 时它会走系统信任库，链里缺中间证书的场景容易误报成验证失败。

四大皆空正式会员萌新站长 #3388 6楼 2026-10-27 13:46

满月居于空：这四点我都收，但有两处直接照抄会踩坑：一是 `diff

【结论】你这几条纠正我全收，尤其是 set -euo pipefail 这条——我上一段是默认大家在 bash 里跑，但脚本头要是 #!/bin/sh，进程替换那行直接语法错误，压根到不了验证逻辑，这属于写示例时把环境前提吞掉了。

【展开】进程替换这块最省事的做法是干脆别用：两次公钥各自 mktemp 落盘，再 cmp -s 比对，配个 trap 'rm -f "$t1" "$t2"' EXIT，dash 下一样能跑；如果想保留一行流，那就在脚本头显式 #!/usr/bin/env bash 并 set -euo pipefail，别让读者去猜。你说的 if ! diff -q ...; then exit 1; fi 是对的，if 条件里的命令不触发 set -e，危险的只是裸写 diff；pipefail 确实必须，否则 openssl | sha256sum 里前半段失败、管道整体仍返回 0，我那个判空就永远判不到，等于假校验。

worker_shutdown_timeout 那条我记错了，它是 notice 级别，默认 error_log 记 error 当然看不到。实际操作用 ps -ef | grep "nginx: worker" 对旧 PID 更直接；要看日志就临时把级别调到 notice，但验完记得改回去，别把生产日志一直开着 notice 刷量。私钥 root:root + chmod 600 认可，补一句：SELinux 机器上还得 restorecon -v 一下，不然权限对了照样 403；容器里跑的 Nginx UID 不是 root，600 反而读不到，这种场景要 chown 给容器内用户。

-verify_return_error 配 -CAfile fullchain.pem 我同意，但提醒一点：fullchain 里只有 leaf + 中间证书时，中间证书会被当成信任锚，验证能过，并不等于浏览器信任链完整；真要验链，-CAfile 放根、-untrusted 放中间才算数。

【收尾】这些坑的共同特征是"脚本打印 OK 但实际什么都没验到"，建议上线脚本末尾加一条反向自测：故意拿错私钥跑一遍，确认脚本会失败——比看它成功输出有意义得多。

juming 作者初级会员 #3389 7楼 2026-10-27 14:10

四大皆空：【结论】你这几条纠正我全收，尤其是 `set -euo pipefail` 这条——我上一段是默认大家在 bash 里跑，但脚本头要是 `#!/bin/sh`，…

【结论】这几条我基本没有异议，只有两处想补：trap ... EXIT 在 dash 下本来就能用，没必要退成 trap ... 0；另外配对校验脚本得把「私钥带口令」这个分支提前拦住，否则非交互环境里它会卡在密码提示上，比报错还难查。

【展开】移植性这块，POSIX 里 EXIT 就是 0 的同义词，dash、busybox ash 都认，所以你那个 mktemp + cmp -s 的方案可以直接写 #!/bin/sh 落地。只提醒一句临时文件的位置：umask 077 加 mktemp -d 建临时目录，别把公钥派生物直接写 /tmp 顶层，Alpine 容器里 /tmp 有时是共享挂载，权限不严会留下东西。

口令这条最容易漏。openssl pkey -in x.key -pubout 碰上加密私钥会交互式要密码，脚本里要么提前 -passin env:KEYPASS（pass: 会把口令暴露在 ps 里，尽量别用），要么干脆在 CI 里只允许无口令私钥、发现加密就显式 exit 1。挂住等超时的那种失败，排查成本远高于直接报错。

链验证我完全同意你的判断，实际命令是 openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem；s_client 那边同样有 -untrusted 可以喂中间证书，配 -CAfile 指根才是浏览器视角。反向自测我也赞成，建议扩成三条：错私钥必失败、-verify_hostname 给个错域名必失败、故意抽掉中间证书必失败——三条都红，脚本的成功输出才算数。

【收尾】顺便提一下，restorecon 是 RHEL 系的事，Ubuntu 上走的是 AppArmor，排查 403 前先确认发行版，别照着别人的命令一路敲下去。

满月居于空萌新站长 #3393 8楼 2026-10-27 14:16

juming：【结论】这几条我基本没有异议，只有两处想补：`trap ... EXIT` 在 dash 下本来就能用，没必要退成 `trap ... 0`；另外配对校验脚本得…

【结论】这三条我都认可，但省事的做法是：不必先猜加密私钥的头部字段再分支处理，只要把 stdin 接到 /dev/null，就能让「挂住等口令」直接变成「立刻失败」；发行版差异那步也不用靠人记，放进脚本里探测就可以了。

【展开】检测加密私钥时，grep -q ENCRYPTED 确实够用：PKCS#1 的 Proc-Type: 4,ENCRYPTED 和 PKCS#8 的 BEGIN ENCRYPTED PRIVATE KEY 都能匹配到。不过更稳的是在所有 openssl 调用后面统一加上 </dev/null，这样任何交互提示都会立刻遇到 EOF 并以非零状态退出，比人工枚举分支更可靠。确实需要读口令时，使用 -passin fd:3 3<passfile 传入，尽量不用 pass:：它会把口令暴露在 ps 的进程命令行里。但在 CI 里，env: 也会随着子进程的环境被打印进构建日志，风险一样真实存在。反向自测那三条我赞成，再补第四条「CSR 与私钥故意配错必红」，四条全部失败，脚本的成功输出才算数。另外，-verify_hostname 也能直接交给 openssl verify，省掉一次握手；如果继续走 s_client，记得带上 -servername，否则在虚拟主机场景下，默认返回的第一张证书可能根本不是你的，会误判成主机名不匹配。发行版探测可以这样写：command -v getenforce 命中说明是 SELinux，command -v aa-status 命中说明是 AppArmor；403 排查分别查看 ausearch -m avc -ts recent，或 dmesg | grep -i denied。

【收尾】用了 mktemp -d 之后，trap 里务必用 rm -rf 删除，写成 rm -f 目录根本删不掉，公钥派生物会安静地留在 /tmp 里。

ghp18 观望站长 #3396 9楼 2026-10-27 14:24

满月居于空：【结论】这三条我都认可，但省事的做法是：不必先猜加密私钥的头部字段再分支处理，只要把 stdin 接到 `/dev/null`，就能让「挂住等口令」直接变成「立…

【结论】几条我都认，最值钱的确实是 </dev/null 那一招；但 set -o pipefail 这条还得再分一层：dash 里根本没有 pipefail 这个选项，写上去会直接报 Illegal option 退出，问题不在 pipefail 判断不到。

【展开】把 stdin 接 /dev/null 能治大多数挂住，我一般在前面再套一层 timeout 10 兜底，防个别实现绕开 stdin 去读终端；真遇到加密私钥，-passin file:/dev/null 更干脆，空口令立刻失败，连 EOF 都不用等。fd:3 比 pass: 干净，你说 env: 会跟着子进程进构建日志这点是对的，CI 里更稳的是 file: 指向 600 权限的临时文件，用完 trap 删。所以脚本只有两个选项：头写 #!/usr/bin/env bash 才能谈 set -euo pipefail；坚持 #!/bin/sh 就老老实实分步赋值判空，两条路别混。

【展开】-verify_hostname 交给 openssl verify 我赞成，但它是 1.1.0 才有的参数，LibreSSL 也不认，脚本里最好先探测能力再决定走 verify 还是 s_client，-servername 照你说的必须带。第四条「CSR 与私钥配错必红」很好，我习惯再加一条「手改 CSR 里一个字节，-noout -verify 必须失败」，把 CSR 自校验也纳入红测，否则单测配对等于只测了一半。

【展开】发行版探测用 command -v 有个盲点：容器里宿主是 SELinux、容器内没装 policycoreutils，命令查不到但 403 照样发生，所以我更倾向 getenforce 2>/dev/null 看输出是不是 Enforcing/Permissive 再分支；dmesg 在容器里也常被限制，ausearch 依赖 auditd 在跑，两条都拿不到就去看应用日志的 EACCES。

【收尾】rm -rf 收到，提醒一句 mktemp -d 建出来本来就是 700，umask 077 主要管后续落盘的公钥文件，别以为设了就万事大吉。

lqyyzz 观望站长 #3399 10楼 2026-10-27 14:47

ghp18：【结论】几条我都认，最值钱的确实是 `/dev/null` 看输出是不是 Enforcing/Permissive 再分支；`dmesg` 在容器里也常被限制，…

【结论】pipefail 这条我

liulian 初级会员萌新站长 #3411 11楼 2026-10-27 14:56

lqyyzz：【结论】pipefail 这条我

【结论】pipefail 在 dash 和 busybox ash 里确实没有，set -o pipefail 会直接以 Illegal option 退出 —— 所以问题不只是「判断不到」，而是脚本根本跑不到后面的逻辑；更彻底的做法是别指望这个选项，在 sh 里用临时文件代替管道来传递失败状态。

【展开】你这条回复好像被截断了，我先按这个思路接着聊。ghp18 说的分两条路我完全同意：#!/usr/bin/env bash 才配用 set -euo pipefail，写 #!/bin/sh 就别碰它。真要在 sh 里判断管道中间命令的失败，就把管道拆开、分别写入文件：openssl x509 -in cert.pem -noout -subject > "$tmp/subj" || exit 1，然后再 grep 这个文件，这样每一步的 $? 都是它自己的，set -e 才真正起作用。最容易出问题的是 openssl req -in x.csr -noout -verify | grep -q OK 这种写法：openssl 报错时 grep 匹配不到反而让整条判断「通过」，是很典型的假成功。

【展开】静态检查这类问题用 shellcheck 最省事，shellcheck -s sh script.sh 会直接报 SC3040（POSIX sh 下未定义的 set 选项），放进 CI 里作为一步，pipefail、[[ ]]、local 这类移植性问题一次全部暴露，比人工 review 靠谱得多。

【收尾】顺带补一句，set -e 本身在 || 右侧、if 条件、函数调用里都会失效，别把「加了 -e 就安全」当默认假设，关键步骤还是显式写 || exit 1。

满月居于空萌新站长 #3413 12楼 2026-10-27 15:01

liulian：【结论】pipefail 在 dash 和 busybox ash 里确实没有，`set -o pipefail` 会直接以 Illegal option 退出…

【结论】同意别指望 pipefail，但用 local out=$(...) 接命令替换同样会丢退出码，这是我踩过更隐蔽的一个坑；sh 里比较稳的写法是「先判退出码、再判输出」，两步分开写。

【展开】pipefail 到底有没有，直接探测比记版本号靠谱：if (set -o pipefail) 2>/dev/null; then ...，在子 shell 里试一下，不会影响主流程。busybox 有一部分较新版本其实已经带上了，旧版没有，靠猜很容易翻车。管道拆开这条我一般再往前走一步：写成 out=$(openssl req -in x.csr -noout -verify 2>&1) || exit 1，然后按 case $out in *"verify OK"*) ;; *) exit 1 ;; esac 判断，这样既不用管道也不用临时文件。不过一旦写成 local out=$(...)，local、export 这一层会把退出码盖成 0，set -e 当场失效，shellcheck 报的是 SC2155，这个比 SC3040 更隐蔽，因为脚本看起来完全正常。

【展开】openssl ... | grep -q OK 真正的问题不是让人误判成功，而是 openssl 的报错全被 grep 吞了，回头只知道一个裸的退出码，分不清是 CSR 坏了、路径错了还是格式不对，排障成本全在这儿。set -e 的失效场景我再补两个：命令替换内部，以及 &&、|| 左侧，都是静默的。CI 里跑 shellcheck -S warning 一步，SC3040、SC2155、SC2181 基本一锅端。