一、CSR 里到底装了什么

一份 CSR 的结构并不复杂，包含四部分：申请者的公钥、主体信息（单位名称、部门、所在地、要保护的主域名等）、附加请求（比如希望包含哪些其他名字）、以及用对应私钥对整个内容做的一次签名。签名的作用是证明“提交这份请求的人确实持有私钥”，签发方验过签名才会往下走。这里有个常被误解的点：CSR 里不含私钥，也不含私钥的任何可复原信息。所以传输 CSR 本身是安全的，把 CSR 发给签发方、贴进表单、走邮件，都不会泄露私钥。真正不能外流的是生成 CSR 时那把私钥。另有两点也值得记住：CSR 是绑定密钥对的，同一份 CSR 只能配同一把私钥，证书签发后若私钥丢了，只能重新生成一对密钥、重新提交请求；CSR 里的名字清单会直接影响证书覆盖哪些域名，填少了签出来就覆盖不到。

二、本地生成的三种入口

最省事的是服务端软件自带的图形入口：在管理界面里填写域名与单位信息，点一下生成，工具会同时产出一个请求文件与一把私钥，并把私钥存进本地密钥库。整个过程不用记参数，适合单站点、新手第一次申请。第二种是密钥库管理工具：这类工具管的是整台机器上的密钥与证书，生成请求时会要求指定别名与密钥库口令，产出物同样是请求文件加密钥库。它的好处是私钥从一开始就被口令保护，适合一台机器上跑多个站点的情形。第三种是命令行工具：灵活度最高，可以指定密钥算法、长度、附加名字、摘要算法，也能一次生成多份请求。代价是全靠参数与交互提示，填错一项就要重来。三种入口产出的请求文件在格式上一致，走哪一条都能提交给签发方，区别只在操作难度与私钥的存放方式。

三、本地生成的好处与代价

好处集中在一句话：私钥从生成到落盘，全程在你的机器上，没有经过任何第三方。这一点在单位内部有明确安全要求时几乎是硬条件。附带的好处是可控：算法、长度、名字清单都由自己定，不会被工具替你决定；生成记录留在本机日志里，出了问题能回溯。代价也很实在。第一，备份责任在自己身上：机器重装、磁盘损坏、误删目录，私钥就没了，而私钥丢了没有补救办法，只能重签。第二，权限要自己收：默认权限往往偏宽，需要主动收窄到只有服务进程可读。第三，新手容易在交互提示上出错，比如把通配符写进主域名一栏、把单位名称写成简称、附加名字漏填，这些错误要等签发后看出来，一来一回浪费时间。第四，多台机器分散生成时，请求文件与私钥的对应关系容易乱，必须靠命名规范与台账来管。第五，环境不统一会带来隐性麻烦：同一份操作在开发机上跑得通，换到生产机上因为工具版本或系统差异跑不通，而生产机往往又不允许随意装东西。真要长期做这件事，建议固定一台专门用于生成请求的机器，把工具版本记下来，让这套动作变成可重复的例行操作，而不是每次临时找台机器凑。还有一个细节常被忽略：生成请求时的系统时间若明显偏移，签名环节可能出现异常，动手前顺手对一下时间，能省掉一段摸不着头脑的排查。

四、在线生成的两种形态要分开看

“在线生成”这个说法底下其实是两件不同的事，风险差别很大，务必分清。第一种是浏览器端生成：工具在你的浏览器里完成密钥对生成，私钥不出本机，页面只把请求文件提交出去，签好的证书再取回。这种形态在安全上与本地生成基本等价，好处是省去装工具、记参数的麻烦，适合临时在一台没装工具的机器上办这件事。第二种是服务方代为生成：你把域名与单位信息交给对方，对方在他的环境里生成密钥对并签发，再把证书连同私钥一起给你。这种做法的便利程度高，但性质上等于把站点身份凭据交给第三方保管过一段时间，后续一旦出现异常访问，责任很难界定。要区分这两种形态，看一眼流程里有没有“私钥在哪生成”的说明就够了；含糊其辞、只说“自动生成、直接可用”的，多半是后者。选择时按这条线划：私钥可以不离开本机的，放心用；需要交给对方的，除非你清楚风险并接受，否则不必走。

五、填写环节最容易出错的地方

无论走哪条路，填写内容都直接决定证书能不能用。第一处是主域名一栏：这一栏通常填一个具体名字，不要填通配符，通配符应放进附加名字里；填错会得到一个覆盖范围与预期不同的证书。第二处是附加名字：要覆盖的名字必须逐项列全，主域名本身若需要单独覆盖，也要列进去，因为通配符不覆盖它所在的那一层根域。第三处是单位信息：需要核验单位身份的产品，这一栏要与登记信息一致，写简称、写品牌名、漏写地域，都会在核验环节被打回。第四处是密钥算法与长度：通用场景下按通行做法选择即可，长度不要低于通行下限，也不要为了追求更长而牺牲兼容性，老客户端对新算法的支持往往滞后。第五处是附加名字的数量与形态要与实际清单对齐，签完才发现少一个名字，只能重新签发。填写前把域名清单摆在手边，逐项对照，比事后返工省事得多。还有一处常见的返工来源：同一批要签的名字里混着不同层级的域名，有的在主域下、有的在另一层，填写时容易按同一套规则处理。遇到这种清单，先按层级分组，同级的放一张请求，跨级的分开处理，后续部署时也不容易记混。请求文件提交后如果被退回，先看退回原因属于哪一类：名字不符的改清单、身份信息不符的改单位信息、密钥参数不符的重做密钥。三类原因的处置方式不同，改错方向会白等一轮审核。

六、私钥的去向与保管

私钥是整个环节里真正敏感的东西，值得单独说清。第一，生成后先备份，备份放在与主机分离的位置，加密保存，并记录备份的时间与位置，否则半年后没人说得清备份在哪。第二，权限收紧，只给服务进程读，目录不要让其他账号可遍历。第三，不要进代码仓库、不要进聊天工具、不要贴在工单里，这几处是最常见的外流渠道，一旦进了历史记录，清理很麻烦。第四，需要多人协作时用口令保护密钥库，把口令与文件分开保管，而不是把未加密的私钥传来传去。第五，建立替换流程：私钥泄露、人员变动、服务器下线，都要触发换证，而不是等证书自然到期。第六，把私钥与证书的对应关系记进台账，哪张证书配哪把私钥、装在哪台机器上、由谁维护，写清楚，交接时才不至于靠猜。

七、按场景选方式

给一份可照做的对照。单站点、第一次申请、机器上装着服务端管理界面：用图形入口生成，最省事，出错概率低。一台机器上跑多个站点、需要统一管密钥：用密钥库工具，口令保护是天然优势。需要一次生成多份请求、或对算法参数有明确要求：用命令行工具，接受前期学习成本。临时在一台没装工具的机器上办、又要保证私钥不出本机：用浏览器端生成的那类入口。单位内部有明确要求、私钥不能出内网：只在本地生成，任何代生成的方式都不必考虑。还有一种情形值得提醒：更换签发方时不必重新生成密钥对，沿用原来的私钥提交新请求即可，证书换了、私钥不变，服务端只需替换证书文件。但若怀疑旧私钥已经外流，就该重新生成一对，把这当作一次清理机会，而不是图省事沿用。

结语

CSR 只是一个装着公钥与名字清单的请求，传它没有风险；私钥才是不该离开本机的东西。本地生成的三种入口各有适用面，图形界面省事、密钥库工具便于统一管、命令行灵活；在线方式要分清是浏览器端生成还是对方代生成，前者与本地等价，后者等于交出凭据。填写时把域名清单摆在手边，主域名与附加名字分清，单位信息与登记一致。私钥做到有备份、权限收紧、不进仓库、有替换流程。把这些理清，生成 CSR 就不再是一道需要凭运气通过的关卡。