用forever给代码加上守护，按下回车。badcert.com终于上线了。这个花费了我一个礼拜写的小东西并没有完成我所有的预期，但算是有了一点可以用的样子了。

badcert.com是一个在线的证书生成器，可以生成私钥、公钥，还可以生成自签名证书、证书签名请求（CSR）等。它还附带了证书信息查看与私钥认证等功能，方便开发者，在开发中可以绕过OpenSSL生成证书的步骤。

甚至不需要它的域名以及主页巨大的安全性提醒，而仅通过常识即可知道，使用在线生成的证书是一件非常危险的事。每一张通过badcert.com生成的证书，都可能被这个网站记录下来，从而在某个时刻被利用，导致严重的安全性后果。

——然而我们在大多数时候真的需要“那么高”的安全性吗？我时常看到有人因为使用命令行版本的OpenSSL而焦头烂额，而可能他只是想要随便一对密钥和证书去调试他的HTTPS服务器。再比如，我在开发iOS的APNS相关功能，开发者证书只对我正在调试的iOS设备起作用。我看到有人在开发时始终使用同一私钥，放到好多台不相关的服务器里去，还有把私钥和证书通过Email抄送给所有的同事，等等等等……

我是想说，在有的时候，比如开发的时候，你根本不介意私钥与证书的安全性问题。相对的，你却在OpenSSL的使用、证书的生成上花费了太多的时间。这个时候，整个证书安全认证体系就变成了一个非常费时费力的东西，变成了阻碍。那么，为什么不让开发工作进行得轻松一点呢？

badcert.com的建立就是为此。我希望能够节约开发者在证书上浪费的时间，不要将安全性搞得过犹不及，弄得大家都很火大。

写badcert.com最初是因为在使用Node.js的pem库。因为用的比较深度，所以顺手还修了这个库的一些bug。pem的作者也是很好的人，有几个我觉得都无关紧要得Pull Request，他都顺手merge了——特别是后来我看了一下这个作者维护的项目，还发现是个蛮厉害的人。我觉得对于开源库，及时与耐心最重要了。有的时候一个Issue十几天后作者才回复，让人非常捉急。而这个项目的Pull Request，往往隔天就merge了，然后作者把小版本号+1，让支持者有一种”哦，这个版本是我写的“的自豪感。

这个库本质上底层还是基于openssl命令。因为用得多了，维护得多了，不可避免地去看底层openssl的命令格式，觉得非常头疼，而且说起来我还是科班出生。由此觉得这个库真是那些需要OpenSSL支持的nodejs开发者的福音。

那么，为什么不把这种易用性传播到网络，让更多人能够方便地生成证书呢？不用细想就知道了——还是因为安全性。如果证书是在线生成的，那么安全性本身还有什么意义呢？这种常识当然是正确的，但我并不认为所有的情况都是如此。例如我上面提到的开发的例子。

换一个角度来说，用证书安全体系保护的计算机连接就真的安全了吗？使用者真的在好好按照手册使用证书吗？我觉得有很多滥用的地方。看看一般的网站登录密码的情况就知道了。这个世界上的网站有那么多，大多数用户都在用有限的几个甚至是同一个密码去登陆不同的网站。有的地方会做得绝一点，比如有的公司会把Windows密码规则设定为每隔两周必须重新设定，且不能和之前的重复——然后用户怕记不住新密码，就把新密码写下来贴在办公桌底下了。

这种过度的安全性保护根本就没有意义，只是安全性专家把安全责任交给了更没有安全意识的公司文员。安全性完全符合木桶原理，在其他木板不够长的情况下，费时费力地增加某一块板的长度根本没有意义。

我认为badcert.com的目标用户本来就有能力知道使用它的潜在危险，从而可以正确地使用它。