下面這張圖簡單地解釋了SSL憑證如何被應用在SSL通訊中以建立client/server之間的信任關係:
我們可以在這張圖看到4個主要的角色以及其中會涉及到的7個步驟. 其中, 互相溝通的兩個角色分別為client與server. 另外兩個角色則分別為CA(certificate authority)以及瀏覽器廠商.
前兩個步驟主要是在說明SSL通訊機制背後的初始化作業, 有了這些前置作業, client與server之間的SSL通訊才可能發生.
Step 1:
CA發行其公鑰(public key)給所有的主要瀏覽器供應商. CA通常是一個組織/機構, 其負責為想要使用SSL通訊的網站簽署SSL憑證. 常見的如Symantec(賽門鐵克), Geotrust等. CA們會運用其公鑰基礎建設去透過密碼學機制替各種有需求的domain進行憑證的簽署. 每個CA都會有其自己的key pair(如非對稱式加密的公私鑰對), 其中, 公鑰是對所有人公開的.
Step 2:
對於瀏覽器廠商來說, 如Mozilla, Google, Microsoft, Apple等, 其必須確認自己做的瀏覽器(這邊僅指有在市場上公開的)有所有CA的公鑰的副本(跟瀏覽器軟體綁在一起). 這對於瀏覽器去驗證一個被特定CA簽署過的憑證來說是必要的. 這些公鑰通常是以公開憑證(public certificate)或是根憑證(root certificate)的方式供外界使用.
Step 3:
當你有了自己的網站且你想要為你的網站啟用SSL通訊, 你就會需要經過這一個步驟了. 你必須找到一個CA並且給他們送出要求協助簽署簽章請求. 這個請求通常會要你填很多必要的欄位以驗證你作為這個網站的所有人的身份. 關於要填什麼東西, 之後的筆記會談到.
Step 4:
當收到了一個新憑證的簽署請求之後, CA按照程序簽完之後, 一個憑證 (certificate) 就出現了. 數位憑證 (certificate) 包含了: 憑證序號, 網站擁有人名稱, 網站擁有人的 public key, 發證機構的數位簽章 (這個東西就是將網站擁有人的 public key 透過 CA 的 private key 加密後的結果)等資料. 在收到CA簽完的憑證之後, 網站的系統管理者就可以把這個憑證加到 server 的 config 裡面. 到這裡, 該做的事前準備就做完了.
Step 5:
從這裡開始, 就有使用者的介入了. 當某個人想要存取在server上的網站時, 這個人用的瀏覽器就會初始化一個SSL連接.
Step 6 & 7:
Server 根據 domain/website 回覆給瀏覽器 SSL 憑證. Client 收到後, 瀏覽器會從憑證中讀取CA的資訊, 並且試著從瀏覽器的 cert store 中找出該 CA 的公鑰(前面提過瀏覽器自身會跟 CA 的公鑰綁在一起, 若這邊的 CA 很冷門或是沒人知道, 那就會無法取得相應的公鑰了). 找到該 CA 的公鑰後, 就以此公鑰去解密該憑證中的數位簽章的部分, 如此便可得到該網站的 public key. 這時候就可以將解出來的 public key 拿去跟網站送來的 public key 比較看是否相同. 若比較結果是匹配的, 這個驗證過程就被認為是成功的, 然後你就會在瀏覽器上面看到綠色鎖頭了. 反之, 你會看到紅色叉叉的鎖頭, 表示有問題:
以上就是簡單的SSL流程, 那要怎麼看憑證內容呢? 以github來說, 你可以在瀏覽器(我這邊用的是Chrome)的address bar上看到綠色的鎖頭, 點下去, 會看到如下畫面:
然後點憑證下面的”有效”連結:
就可以看到該網站的憑證相關資訊了, 其中也包含此憑證支援的domain有哪些.
References
- SSL/TLS Operations
