自签名证书生成器
为内部服务生成一张证书及其私钥，无需背诵 openssl 命令：输入通用名称，列出证书必须覆盖的每个名称和 IP，选择有效期和密钥长度，然后下载两个 PEM 文件。密钥在你的浏览器中本地生成，从不上传——本页面不发出任何网络请求，密钥在你保存之前只存在于这个标签页中。
密钥越长生成越慢：4096 位在一台普通机器上可能需要一些时间。计算在你的机器上、这个标签页里完成——让它开着，等它结束。
自签名证书是用来做什么的
自签名证书的颁发者和主题是同一个：它为自己作证。这听起来像缺陷，对公共网络来说确实是——访客的浏览器没有理由相信一个陌生人的自说自话。但大量 TLS 从不面向公众：内部仪表盘、预发布环境、家庭实验室服务、网络设备的管理界面，以及一个组织内部服务之间的通信。对这些场景，受众是你控制的机器，信任问题有不同的答案：你把证书（或你自己的小型 CA）一次性、慎重地装进你管理的信任库。换来的是在自家围墙内实现加密和身份确认，而公共 CA 永远不会知道你的内部主机名——那些名字本身就是一份你的基础设施地图。
从前生成证书的仪式是一条没人记得住、人人复制粘贴的 openssl 命令，SAN 还要通过配置文件外挂，因为旧版本根本没有对应的参数。这个页面存在的意义，是让证书的形状直接可见：名称是一份你能读的列表，有效期是你明知会到期而选择的天数，密钥长度是一个决定，而不是一个你从未注意过的默认值。它刻意不做的，是假装自己是一个 CA：没有链，没有中间证书，也没有可吊销的东西。一个服务，一张证书，一个需要记住的到期日。
让客户端接受它
生成证书是容易的一半；信任才是部署。在你自己的少数几台机器上，把证书加进操作系统（或浏览器）的信任库就能一劳永逸地消除警告；curl 和 git 这类工具接受按命令指定的 --cacert 指针，而不是禁用验证这个危险习惯——-k 参数会训练所有人去忽略那个本该抓住真实攻击的警告。当受众超过少数几台机器，就从单张自签名证书升级到一个小型私有 CA：用它签发服务证书，只分发 CA 证书，轮换就不再是逐台客户端的巡回。当某个服务最终还是要面向公众时，把证书换成公共受信的——SSL 检查器会核实服务器上线后实际出示的是什么，而那正是自签名不再是一个选项的时刻。
相关工具：用 SSL 证书解析器把任何证书读回来，或用 SSL 检查器检查线上服务器实际出示的证书。
延伸阅读：一套可靠性例行工作——为什么内部证书及其到期日应该和轮换、备份放在同一张规划表上。
证书生成使用 node-forge，依 BSD-3-Clause 许可使用，仅在你按下“生成”时加载。本工具的任何部分都不发出网络请求。
常见问题
自签名证书应该用在哪里？
用在只有你和你自己的系统会访问的东西上：内部仪表盘、实验室和预发布环境、家庭实验室服务、设备管理页面，以及让服务器在真实证书签发之前先能启动起来的占位符。规则看触达范围：如果陌生人的浏览器将来会看到它，它就需要一张公共受信证书——那种证书可以从 Let's Encrypt 免费获得。
为什么浏览器会对自签名证书发出警告？
因为“自签名”意味着唯一为证书作证的就是它自己。加密本身是有效的——连接是私密的——但没有任何东西证明服务器就是它声称的那个身份，而这正是证书颁发机构通常提供的那一半 TLS。因此浏览器会一直警告，直到证书（或你控制的 CA）被加入使用它的机器的信任库。
为什么通用名称也出现在 SAN 列表里？
现代浏览器完全忽略通用名称字段，转而检查主题备用名称列表。一张主名称不在自己 SAN 列表里的证书，会在它为之生成的那个名称上验证失败——这是最常见的自签名错误——所以本页面总是把通用名称加入 SAN。
2048 位 RSA 够用吗，还是应该选 4096？
2048 位 RSA 是当前的基线，对内部服务足够；大多数公共证书仍在使用它。4096 位以更慢的生成速度和略慢的握手为代价，换取应对未来密码分析的余量。它适合长期的内部 CA，或一个不容易重新签发的服务。无论哪种，生成都发生在你自己的机器上——4096 位可能需要一些时间，标签页是在工作，不是卡住了。
在网页里生成私钥安全吗？
在这个页面上安全，原因在于它的构建方式：密钥对用 node-forge 库在你的浏览器中本地生成，页面不发出任何网络请求，你生成的任何东西都不会被上传、记录或存储。不过这个习惯仍值得保留：只在你信任的页面（和机器）上生成密钥，并从私钥文件存在的那一刻起就把它当作秘密。