StartSSL.com Web SSL 憑證代購

StartSSL.com 有提供我們這些 已作過 Personal Identity Validation 的人 去幫別人購買憑證的方案 ，如果有需要我可以協助購買。收費分五個等級，並有三個但書：

閱讀更多…

Ho600’s SSL Certification

雖然 StartSSL.com 有免費一年的憑證( Class 1 )可以申請，但如果是商業運作的網站，它們是會拒絕你的申請，所以我的 Ho600.com 就被拒絕申請免費的 Class 1 憑證。不過，沒關係，人家開公司總要賺錢的嘛~ 況且他們的憑證服務真的很方便，也很便宜，所以我沒什麼好抱怨，甚至我很欣賞它們，因為它們提供的服務是以加解密技術為基礎向上發展的，或許之後我還會跟它們買硬體憑證以研發電子公文系統，或是幫它們代銷 SSL 憑證。那這樣本文就算廣告文，事實上也是，請詳見本文末 。

閱讀更多…

StartSSL Extended Validation Certificate has sec_error_unknown_issuer error with Firefox

A few days ago, i bought a Extended Validation Certificate from www.startssl.com for my client( in strictly speaking, cooperate with someone's help ).

The price of two years EV certificate is more cheaper than other competitors's in Taiwan.  StartSSL EV quotes USD$199( closing to TWD 6,000 ), and the same level competitors in Taiwan quote TWD 55,000 ~ 90,000.  Yes, you did not lost, the ten times expensiveness.

But it costs something else, because the www.startssl.com is a Israel company, we must verify the personal and  company authorization with law notarization first.  This law jobs spend our half month.  Anyway, we done, and obtain a real green bar certificate now.

After i install and configure certificate in Nginx Server, Chrome and IE can pop up rightly, but Firefox alerts a "sec_error_unknown_issuer" message to me.

The solution is catching "sub.class4.server.ca.pem"( Exclusive only for Extended Validation Cert ) and "ca.pem" into your_example_domain.crt file, and the order must be "your_domain_crt", "sub.class4.server.ca.pem" and "ca.pem".  You can find the two files in the www.startssl.com/certs/.

Below is my Nginx conf:

listen                  443;
ssl                     on;
ssl_certificate         /etc/ssl/your_example_domain.crt;
ssl_certificate_key     /etc/ssl/your_example_domain.key;

This solution wasted me about one hour, because i did not known the sub.classX.server.ca.pem is different to free-class and Extended Validation Cert.  Free-class cert uses class1 and EV cert uses class4.

Finally, i got a green internet address bar.  So happy~

不應該在資料庫中紀錄使用者的明碼密碼

看到這個有趣的 Blog ：「我的密碼沒加密」。我才知道這世上不懂『不應該在資料庫中紀錄使用者的明碼密碼』的程式設計師是如此之多。

這本應是菜鳥程式設計師才應該犯下的錯，沒想到連存在好幾年的「綠界」都有。我真的不願相信這是事實。話說回來，對一個合格的 Linux/Unix 管理員，不能有明碼密碼根本就是常識。

過去，我還想用 PGP 驗證來取代『在伺服器資料庫紀錄使用者密碼』，這法子絕對能確保「使用者密碼」不會外洩。只是，我沒遇到那個使用者能接受自己產生一對公私錀，利用它們來作登入的。

雖然我沒作出個 PGP 驗證的實際上線系統，但 StartSSL.com 作到了，它不是用 PGP 加解密，是另一種公私錀原理。所以外國月亮比較圓是真的。

在我所撰寫過的系統中，只要有帳號認證的，一定會在伺服器端用 md5/sha1 作 hash ，另外也會在瀏覽器端用 javascript 作 md5 hash 。

伺服器端 hash 是防自己人及入侵者，防入侵者不用講了，這是一定要的，但「自己人」為什麼要防呢? 想想看，一個系統內幾千甚至上萬個會員的帳號/密碼都可以給自己人看，那這些自己人難道不會換工作，難道不會對老闆不爽，難道不會被「社交」，將密碼變暗碼，除了保護使用者外，也是為自己人免責，至少使用者自己被社交了，他也不能栽髒我們。

而瀏覽器端的 md5 hash 又是為了什麼? 因為我寫的網頁系統少能跑在 https 上，無法為使用者輸入的密碼作加密以防止中間人攻擊。所以我只好用 md5 函式 hash 過使用者明碼密碼，這雖無法完全避免使用者帳戶被盜用(在明碼傳輸中，它就是有可能遭受中間人攻擊)，但至少讓它們難以反推用戶的原始密碼。

另外也曾在一個「歷史系統」中，在瀏覽器端部份是使用 rsa 加密的。因為它之前只有使用「伺服器端 hash」作保護，而當我要再加上「瀏覽器端 hash 」功能時，會面臨「無法使用它的明碼密碼來作自我 hash 」。

是的， hash 也是有技巧的，不要用同一個 salt key 作，要不然入侵者破了一個使用者密碼後，其他的也都猜出來了。所以瀏覽器端，我都是用使用者原始密碼內的某個字去當 salt 來作 hash 的。

於是在「歷史系統」中，要把它一次轉成「有瀏覽器端 hash 」功能的話，勢必要每個使用者回來登入一次，我才有機會將系統轉移。這不是件容易的事。退而求其次，使用 rsa 加密就是不錯的方法。這方法是某個學弟找到的，原本我還不知道有原生的 js 函式庫能作 rsa 加密呢!

提了這些方法說明保護使用者明碼密碼不是作不到，只是有點麻煩而已。

然而那些程式設計師真的只是怕麻煩才不想使用 hash 密碼嗎? 根本不懂的程式設計師，就不要講了，剩下沒用 hash 的，除了怕麻煩外，我猜還怕另一樣東西： debug 。

紀錄「使用者明碼」密碼的惟一好處就是能操作「使用者」所能看到的頁面。

試想一個場景，某天使用者打客服電話，詢問歷史訂單事宜，他一直抱怨看不到之前的一筆 Ubuntu NB 訂單，可是客服用後台管理系統查詢，卻明確地說明使用者真的有這筆訂單。那這問題要如何解決?

如果客服有使用者的帳密，他是不是自己登入系統，來到相同頁面觀看，就能了解到底是系統有 bug ，還是使用者不會操作。有可能問題只是出在「訂單分頁」不夠明確，使用者不知道要點到第二頁去觀看訂單。

讓客服知道明碼密碼以便可以看到與使用者相同介面的網頁是不得以的方法嗎? 不。我們有更安全的作法。

我們的作法是在客服後台，有一個轉移帳戶的頁面，讓他填入帳號(且不用輸入密碼)後可轉換成任一個使用者，我們再紀錄那一個客服曾轉換成誰，又作了什麼，這樣客服不用知道使用者的明碼密碼，也可以變成那一個使用者，而且我們也知道客服幹了什麼好事，所以客服可以在面臨無法排除的困難時才會丟 ticket 給我們，這不是三方皆喜：使用者安全、客服好作事、程式設計師省事。

那這架構怎麼作? 因為程式語言、框架百百種。我只說明觀念，請程式設計師們自行發揮，當然有問題歡迎發問，或覺得我的方法可以改進的，也歡迎指教。

認證系統多半是使用 Session 架構來確認連線的使用者身份為何? 其他用 cookie 或是 GET 連結的也差不多，都是把使用者識別 ID (可能是使用者帳號，也可能是臨時編號)藏在某個變數之中，讓程式在執行時，能找到一個 key 值去對應資料庫中的使用者。

所以我們只要在那個對應資料庫使用者的程式中，多加上一個判斷式，如果有另一個轉換識別 ID 時，就把原使用者識別 ID 換成這個轉換識別 ID 。

例如： 何阿蒙客服登入系統後，連線 request 的使用者識別 ID 為 hoamon ，當他設定好轉換帳號為 grace 後，連線的 request 物件多了一個 grace 的轉換識別 ID 。這樣「對應資料庫使用者的程式」在運行時，就會知道使用者得用 grace 去代換，而不是 hoamon 。而我們的 log 函式在發現 request 物件多了轉換識別 ID 後，也會把『 hoamon => grace 』及所作的事一起紀錄到資料庫中。

這樣就能完全排除「明碼密碼」的使用了。

使用「公認機構簽核公錀」所發生的不知名問題

在 How to get a free HTTPS web certification authority by StartSSL.com 一文中，我申請了 A.hoamon.info 的公錀簽核，也正確地跑在 https 上，在使用瀏覽器觀看時，完全沒有問題。然而在 hg 軟體上，卻會發生 SSL: Server certificate verify failed. 的錯誤訊息，從 Mercurial on Windows vs Linux, spot the problem 一文中，作者解釋是 Windows 的 ssl 版本太舊的原因，但照他的解決方案處理，我的 hg 軟體卻是報 URLError. 錯誤。

後來在檢查 apache.conf 時發現，這台機器有三個 https 站台，一個是用 A.hoamn.info 的公錀，另外兩個 B, C 站台卻都是用 whatever.hoamon.info 的公錀。而 B, C 站台的設定檔寫得比 A.hoamon.info 站台還前面。所以試著調動 A.hoamon.info 到 B, C 站台設定的前面，結果 hg 軟體就正常了。

問題是解決了，但我反而混亂了。印象中， https 協定中，公錀是在 IP 層(或表現層，我不確定)就發送至使用者的瀏覽器，既然沒到應用層，則網頁伺服器就不知道該拿那一個虛擬站台的公錀給使用者，於是它總是拿第一個看到的公錀(也就是寫在最前面的)，所以這篇教學文章，才會寫到：「…一個 Apache ，也只能架一個 SSL 站，用一個站名。除非妳跑很多份 Apache ，各自跑在不 同的 IP 或不同的 TCP 埠上，才能在同一臺伺服 器上，跑好幾個 SSL 站。」

實際上，在 Windows XP 的 IE, Safari 上觀看 A, B, C 三個站台，也的確都是拿到 A.hoamon.info 的公錀。但在 Chrome, Firefox 上，卻是看到 A 用 A.hoamon.info ，但 B, C 用的是 whatever.hoamon.info 的公錀。

這我頭大了，為什麼跟基本原理不一樣??? 還是因為某些瀏覽器有「重拿公錀的機制」存在???

How to get a free HTTPS web certification authority by StartSSL.com

一般在上網時，所用的 Http 協定是明碼的，使用者與網站伺服器之間的任何網路結點(閘道器)都有方法可以看到網路連線所傳遞的訊息，所以如果網站所提供的服務關係到機密(隱私)資料時，我都會讓網站用 Https 加密協定服務。

使用 Https 服務時，有一個重要觀念： 如何拒絕「中間人攻擊」。

假想一個以 Https 加密協定服務的 A 網站，在它與使用者傳遞公錀(加密憑證)時，是被一個中間人接走，而中間人再把它自己的公錀傳遞給使用者，結果使用者傻傻地使用中間人的公錀加密，再把加密資訊傳到中間人，而中間人用自己的私錀解密後，再用 A 網站公錀加密傳回 A 網站，在這個模式，雖然使用的是 Https 協定，但資料還是被中間人看光光了。

所以要防止此類攻擊，就必須讓使用者能「確認」公錀真的是 A 網站的。方法是使用者自己手頭上要有一些公認機構所發行的公錀憑證(一般的瀏覽器都已經包入)，然後在拿到 A 網站的公錀憑證時，用手頭上已有的公認機構公錀憑證去驗證這個 A 網站的公錀憑證是否被這些公認機構簽核過，如果有，則表示公錀的確就是 A 網站的，當使用者用這把公錀加密時，就只能被 A 網站解密。

本篇文章的目的是站在 A 網站的立場上，如何將 A 網站的公錀交給公認機構作簽核，這樣使用者在瀏覽 A 網站時，才不會跳出一個警示視窗告知使用者：「 A 網站有安全疑慮」。

一般將公錀交給公認機構去作簽核是要花錢的，像是國內最大的簽證公司(我猜的)網際威信最便宜的簽核年費是 18000 元。這筆費用不是每個人願意負擔的，像是我的 https 網站，主要是提供我們團隊作專案管理之用，也就不到 10 位的使用者，要我花 18000 元，去買一個「讓使用者在一年之內不會看到該網站有安全疑慮」的警告訊息，這我可花不下手。

所幸，有公認機構了解這種需求，它以「給非商業網站一年免費」作廣告宣傳，如果有更高級的簽核需求，它才額外收費。那麼以我上述所要的，其實就拿那個「一年免費」用用即可。

首先請使用 Firefox (它們目前不支援 Chrome)去瀏覽 http://www.startssl.com/ ，並點選右上角的錀匙圖示，如下圖：

就能看到 Sign-up 按鈕，如下圖：

按下 Sign-up 按鈕就開始註冊帳戶的流程，整個公錀簽核的程序分成三個階段：

1. 註冊帳戶
2. 驗證網址
3. 公錀簽核

1. 註冊帳戶時， startssl 會給你的瀏覽器一個全新的公私錀檔，這個公私錀檔是專供你的帳戶使用的，這個公私錀檔要好好保管，搞丟了，你就不能再用這個帳戶申請簽核的動作，因為它的登入不是用帳號密碼作登入機制，而是用公私錀作登入機制。

2. 驗證網址，你必須證明要作簽核的網址是你所管理的。而這個驗證動作完成後，你也只有 30 天的期限去作簽核它的公錀，過期後，就必須再次驗證網址。

3. 針對已驗證過的網址，你可以申請簽核公錀的動作，主要分兩種作法，一是 startssl 完全生出一把全新的公私錀憑證; 二是我們自己生出私錀及公錀請求檔，再把公錀請求檔交給 startssl 去作出已簽核的公錀。本文是介紹第二種方法，因為私錀應該是自己處理會比較妥當，不要懶惰到連解密錀匙也委託他人製造，我個人認為這種人不只懶還不負責任。

原則上，公錀不過是一個文字檔，所以它在 Linux, Window$, Mac 作業系統下，都能處理，但我個人還是喜歡用 Linux 來作這件事。

1. 註冊帳戶：

請填寫你的詳細資料，原則上，他們只採 web 審核，所以只要你的資料不要「太假」，他們都會通過。但如果你要為商業網站申請憑證的話，這就不能開玩笑了，因為你買憑證時，它會要你給護照及身份證、駕照的文件作審核。

請到註冊信箱接受具驗證碼的信。並注意「目前的這個視窗」是不允許關閉的，如果你關閉當下這個網頁，再用相同連結回來，這樣你填寫的驗證碼就算是對的，它也不會通過你的申請。

產生「帳戶」專用的公私錀檔，可選擇 Hign Grade 。

將公私錀檔安裝至瀏覽器上，這裡的公私錀檔是指你的帳戶與 startssl 網站溝通時，所用的公私錀檔，而不是你的網站要用的公錀。

建議你備份這份公私錀檔。

完成後，可見到帳戶頁面。

2. 驗證網址：

我是選擇 Domain Name Validation 方式。

填入網址。

startssl 會從 whois 資料中抓出管理員信箱，所以你必須確認該網址的 whois 內容是正確的。

請到信箱收取驗證碼。並填入上面的 Verification Code 中。

成功後，你只有 30 天的時間，去簽核該網站的公錀檔。

3. 簽核公錀：

公錀可以有很多種用途( Email/XMPP/Object Code )，但目前我只需要 Web 的，所以選擇 Web Server SSL/TLS certificate 。

要使用自己獨立生成的私錀來作簽核公錀的動作，請選擇 Skip 。

欲生成長度為 4096 bits 的私錀檔並使用 des3 格式作私錀加密(密碼長度要大於 4 個字元)，請使用如下指令：

# openssl genrsa -des3 -out exmple.com.key 4096
Generating RSA private key, 4096 bit long modulus
................................................................................................................................................................++
...............................................++
e is 65537 (0x10001)
Enter pass phrase for exmple.com.key:
Verifying - Enter pass phrase for exmple.com.key:

從新增的私錀中，產生一個憑證請求檔，並在請求檔中，寫入「目標網址」(也就是你剛驗證過的那個網址)的所屬資料，如：所在地、單位名稱、負責人信箱等：

# openssl req -new -key exmple.com.key -out exmple.com.csr
Enter pass phrase for exmple.com.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:{{TW}}
State or Province Name (full name) [Some-State]:{{Taichung}}
Locality Name (eg, city) []:{{Taichung}}
Organization Name (eg, company) [Internet Widgits Pty Ltd]:{{EXAMPLE-Company}}
Organizational Unit Name (eg, section) []:{{EXAMPLE-Company}}
Common Name (eg, YOUR name) []:{{EXAMPLE Company}}
Email Address []:{{master@exmple.com}}

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

兩個 {{ }} 所包住的部份，請自己修改成正確資料。

在 Linux 完成 CSR 檔的製作後，你會得到 example.com.csr 檔案，請將檔案內容貼入上圖的文字框中。

CSR檔如無誤，它會出現上圖的訊息。

它要你選擇要生成簽核公錀的頂層網域。

請填入你所提供 https 服務的網址名稱。

確認要簽核公錀的網址。 startssl 簽核的公錀，預設會給你的目標網域及它的頂層網址兩個。如果你要簽核公錀的網址希望是 *.example.com ，也就是除頂層網域外，把它的下層網域一網打盡，也是可以，只要二年付 USD 49.9 即可，大約 1500 元的新台幣，而且這是 wild cards 網址，網際威信可沒這麼好康，一個就要 18000 元、二個就是要 36000 元。這時，我又感到「全球化」的愉悅。

接下來，請把文字框中的文字貼到 example.com.crt 中，這個內容即已被簽核過的公錀檔。另外，請順便下載上圖中的 intermediate 及 root 兩個 CA 檔案。

整個工作完成了。

然後在 Apache 設定檔中設定如下：

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
SSLCertificateFile /etc/apache2/example.com.crt
SSLCertificateKeyFile /etc/apache2/example.com.key
SSLCertificateChainFile /etc/apache2/sub.class1.server.ca.pem
SSLCACertificateFile /etc/apache2/ca.pem
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

重新啟動 Apache 時，它會問你私錀密碼為何? 這個動作在管理員面前發生是沒有問題的，但在系統自動重開機時，會造成困惱，所以我們可移除私錀的加密，指令如下：

# openssl rsa -in exmple.com.key -out exmple.com.key.no_password

exmple.com.key.no_password 這個私錀檔就是沒加密的，將它寫入 apache 設定檔即可。