PEM格式證書在線生成：badcert.com

用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的目標用戶原本就有能力知道使用它的潛在危險，從而能夠正確地使用它。