從 Clean Architecture 一書中,
習得以下幾張架構設計上的觀念。
google-code-prettify
2020年1月20日 星期一
關於 SSL 憑證的一些事
在網際網路的世界,
一般為了資料傳輸的安全會使用SSL協定進行加密傳輸,
因此需要使用憑證進行加密,
再加上 Google、Apple 等網路資訊巨擘對資料傳輸安全重視與鼓勵倡導而更加普及與重要。
如 Google 的搜尋演算法在某些類型情境下,
會針對搜尋結果中的網站(例如:電商)是否使用 HTTPS 協定,
用來作為搜尋結果排序的其中一個影響因子。
又如Apple iOS App 要求所有連結後台與網頁都必須採用 HTTPS 傳輸協定。
而憑證本身是不含、也與使用何種傳輸層安全性協定(如:SSL、TLS各版)無關的。
憑證是層層組織單位簽發授權,
他是一個階層式結構。
在所有作業系統如Windows、Mac、Android等等,
都會內建全球的各家根憑證,
這些根憑證組織單位會簽發其下的中繼憑證,
中繼憑證又可以簽發自己下層的中繼憑證,
但只有根憑證會預設就含在作業系統之中。
末端網站使用的憑證檔案,
其內容必須含有簽發給你憑證的組織單位資訊,
也必須含有這個簽發給你憑證的組織單位其憑證的簽發組織單位資訊,
如此一路往上層直到其所屬的根憑證簽發單位。
而作業系統就可以依照憑證檔案裡的根憑證資訊來對照到作業系統內建的根憑證組織單位,
進而可以一路解開你傳輸的資料內容。
以 Google 網站為例,
當我們連結這個網址: https://www.google.com/ ,
可以看到網址列左邊有一個鎖,
點擊鎖頭圖示之後可以查看憑證資訊,
如下圖:再點擊「憑證(有效)」
下圖我們可以看到 Google 的憑證階層,
他們的憑證是被簽發給 *.google.com 網址使用,
也就是鎖有 google.com 下的站台網址都可以使用這張憑證,
例如: https://translate.google.com/
而簽發出這張憑證的簽發單位寫在畫面中的「簽發人名稱 > 一般名稱」
這畫面是 Max 系統的畫面,在其他作業系統可能會有不同的畫面,
但仍然會有相同意思的欄位資訊。
在畫面上方的憑證階層區塊中點擊 GTS CA 101 ,
可以看到其資訊如下圖,
畫面中顯示他是一個「中繼憑證授權」,
也就表示他並不在作業系統中預設含有的憑證列表中,
因為他不是根憑證。
在點擊最上層的 GlobalSign,
出現這張憑證的資訊如下圖,
畫面顯示出他是「根憑證授權」,
也就是在作業系統預設含有的根憑證裡,
這樣 Google 網站綁定的憑證檔案其內容資訊就足夠供 Client 端憑證管理機制對應識別 Server 端( Google )綁定的憑證是否正確可處理。
當某個站台綁定憑證後,
藉由HTTPS連線時,
出現憑證不安全的錯誤訊息,
大致上都是憑證本身有問題
如:Chrome 出現「NET :: ERR_CERT_AUTHORITY_INVALID」、
Firefox 出現「無法辨認節點的憑證簽發者。」,
這表示憑證本身沒有含有足夠憑證簽發者資訊,
憑證簽發者資訊是需要含有層層向上一路到根憑證。
從瀏覽器的設定功能,
可以搜尋到「憑證」的設定功能頁面,
裡面應該可以看到目前 Client 端憑證管理裡面已經含有的根憑證有哪些,
甚至有的可以看到已經含有的中繼憑證有哪些,
中繼憑證並不是作業系統一開始預設就含有的,
而是後來被下載到 Client 端留存的。
如果某個站台使用的憑證僅含有中繼憑證資訊,
這樣並不能確保 Client 端可以安全正確的使用 SSL 連線到該站台。
如果 Client 端瀏覽過其他站台是使用跟該站台同樣的中繼憑證簽發單位,
但其含有完整到根憑證的資訊,
這樣會自動下載中繼憑證資訊留存到 Client 端的憑證管理內,
而後瀏覽前述所提僅含有中繼憑證資訊的站台就可以正常運作 SSL 連線。
但如果 Client 不曾瀏覽到和問題憑證相同簽發單位的完整憑證站台,
憑證管理裡面沒有該中繼憑證所隸屬的根憑證資訊,
則瀏覽憑證僅含有中繼憑證資訊的站台就會出現問題,
無法確保建立安全的連線。
例如:
某A站台使用的憑證為「TWCA Secure SSL Certification Authority」簽發,
並且其憑證檔內容僅到標註簽發者為 TWCA Secure SSL Certification Authority,
則瀏覽其站台會出現「NET :: ERR_CERT_AUTHORITY_INVALID」、「無法辨認節點的憑證簽發者。」錯誤訊息。
若是瀏覽另一個站台B,其憑證為「TWCA Secure SSL Certification Authority」簽發,
並且憑證檔案裡也含有顯示「TWCA Secure SSL Certification Authority」的憑證為「TWCA Global Root CA」簽發的所需使用資訊,
因為「TWCA Global Root CA」為根憑證,
作業系統會自動下載補上「TWCA Secure SSL Certification Authority」的憑證資訊到憑證管理裡。
下次瀏覽A站台就不會遇到「NET :: ERR_CERT_AUTHORITY_INVALID」、「無法辨認節點的憑證簽發者。」的錯誤訊息了。
各家作業系統都會有自己的憑證管理,
Chrome、Edge、Safari 等瀏覽器使用作業系統的憑證管理,
但是 Firefox 是自己內建憑證管理機制。
所以,若是上面的所述的憑證問題例子,
你使用 Chrome 瀏覽而補充了作業系統憑證管理中的中繼憑證所屬資訊,
往後你不再遇到上述問題,
你換用 Firefox 瀏覽時,
而你之前沒有機會用過 Firefox 補充到該中繼憑證資訊,
還是會遇到如「無法辨認節點的憑證簽發者。」這樣的錯誤。
一般開發時,
你可能會因為沒有買或申請公認的 CA 憑證(上述所討論的憑證),
而需要自簽憑證,
若不想遇到瀏覽時憑證檢核無法通過的問題,
則需要將自簽憑證匯入 Client 的憑證管理之中,
但最好還是使用個公認的 CA 憑證來開發會比較方便。
一般為了資料傳輸的安全會使用SSL協定進行加密傳輸,
因此需要使用憑證進行加密,
再加上 Google、Apple 等網路資訊巨擘對資料傳輸安全重視與鼓勵倡導而更加普及與重要。
如 Google 的搜尋演算法在某些類型情境下,
會針對搜尋結果中的網站(例如:電商)是否使用 HTTPS 協定,
用來作為搜尋結果排序的其中一個影響因子。
又如Apple iOS App 要求所有連結後台與網頁都必須採用 HTTPS 傳輸協定。
而憑證本身是不含、也與使用何種傳輸層安全性協定(如:SSL、TLS各版)無關的。
憑證是層層組織單位簽發授權,
他是一個階層式結構。
在所有作業系統如Windows、Mac、Android等等,
都會內建全球的各家根憑證,
這些根憑證組織單位會簽發其下的中繼憑證,
中繼憑證又可以簽發自己下層的中繼憑證,
但只有根憑證會預設就含在作業系統之中。
末端網站使用的憑證檔案,
其內容必須含有簽發給你憑證的組織單位資訊,
也必須含有這個簽發給你憑證的組織單位其憑證的簽發組織單位資訊,
如此一路往上層直到其所屬的根憑證簽發單位。
而作業系統就可以依照憑證檔案裡的根憑證資訊來對照到作業系統內建的根憑證組織單位,
進而可以一路解開你傳輸的資料內容。
以 Google 網站為例,
當我們連結這個網址: https://www.google.com/ ,
可以看到網址列左邊有一個鎖,
點擊鎖頭圖示之後可以查看憑證資訊,
如下圖:再點擊「憑證(有效)」
下圖我們可以看到 Google 的憑證階層,
他們的憑證是被簽發給 *.google.com 網址使用,
也就是鎖有 google.com 下的站台網址都可以使用這張憑證,
例如: https://translate.google.com/
而簽發出這張憑證的簽發單位寫在畫面中的「簽發人名稱 > 一般名稱」
這畫面是 Max 系統的畫面,在其他作業系統可能會有不同的畫面,
但仍然會有相同意思的欄位資訊。
在畫面上方的憑證階層區塊中點擊 GTS CA 101 ,
可以看到其資訊如下圖,
畫面中顯示他是一個「中繼憑證授權」,
也就表示他並不在作業系統中預設含有的憑證列表中,
因為他不是根憑證。
在點擊最上層的 GlobalSign,
出現這張憑證的資訊如下圖,
畫面顯示出他是「根憑證授權」,
也就是在作業系統預設含有的根憑證裡,
這樣 Google 網站綁定的憑證檔案其內容資訊就足夠供 Client 端憑證管理機制對應識別 Server 端( Google )綁定的憑證是否正確可處理。
當某個站台綁定憑證後,
藉由HTTPS連線時,
出現憑證不安全的錯誤訊息,
大致上都是憑證本身有問題
如:Chrome 出現「NET :: ERR_CERT_AUTHORITY_INVALID」、
Firefox 出現「無法辨認節點的憑證簽發者。」,
這表示憑證本身沒有含有足夠憑證簽發者資訊,
憑證簽發者資訊是需要含有層層向上一路到根憑證。
從瀏覽器的設定功能,
可以搜尋到「憑證」的設定功能頁面,
裡面應該可以看到目前 Client 端憑證管理裡面已經含有的根憑證有哪些,
甚至有的可以看到已經含有的中繼憑證有哪些,
中繼憑證並不是作業系統一開始預設就含有的,
而是後來被下載到 Client 端留存的。
如果某個站台使用的憑證僅含有中繼憑證資訊,
這樣並不能確保 Client 端可以安全正確的使用 SSL 連線到該站台。
如果 Client 端瀏覽過其他站台是使用跟該站台同樣的中繼憑證簽發單位,
但其含有完整到根憑證的資訊,
這樣會自動下載中繼憑證資訊留存到 Client 端的憑證管理內,
而後瀏覽前述所提僅含有中繼憑證資訊的站台就可以正常運作 SSL 連線。
但如果 Client 不曾瀏覽到和問題憑證相同簽發單位的完整憑證站台,
憑證管理裡面沒有該中繼憑證所隸屬的根憑證資訊,
則瀏覽憑證僅含有中繼憑證資訊的站台就會出現問題,
無法確保建立安全的連線。
例如:
某A站台使用的憑證為「TWCA Secure SSL Certification Authority」簽發,
並且其憑證檔內容僅到標註簽發者為 TWCA Secure SSL Certification Authority,
則瀏覽其站台會出現「NET :: ERR_CERT_AUTHORITY_INVALID」、「無法辨認節點的憑證簽發者。」錯誤訊息。
若是瀏覽另一個站台B,其憑證為「TWCA Secure SSL Certification Authority」簽發,
並且憑證檔案裡也含有顯示「TWCA Secure SSL Certification Authority」的憑證為「TWCA Global Root CA」簽發的所需使用資訊,
因為「TWCA Global Root CA」為根憑證,
作業系統會自動下載補上「TWCA Secure SSL Certification Authority」的憑證資訊到憑證管理裡。
下次瀏覽A站台就不會遇到「NET :: ERR_CERT_AUTHORITY_INVALID」、「無法辨認節點的憑證簽發者。」的錯誤訊息了。
各家作業系統都會有自己的憑證管理,
Chrome、Edge、Safari 等瀏覽器使用作業系統的憑證管理,
但是 Firefox 是自己內建憑證管理機制。
所以,若是上面的所述的憑證問題例子,
你使用 Chrome 瀏覽而補充了作業系統憑證管理中的中繼憑證所屬資訊,
往後你不再遇到上述問題,
你換用 Firefox 瀏覽時,
而你之前沒有機會用過 Firefox 補充到該中繼憑證資訊,
還是會遇到如「無法辨認節點的憑證簽發者。」這樣的錯誤。
一般開發時,
你可能會因為沒有買或申請公認的 CA 憑證(上述所討論的憑證),
而需要自簽憑證,
若不想遇到瀏覽時憑證檢核無法通過的問題,
則需要將自簽憑證匯入 Client 的憑證管理之中,
但最好還是使用個公認的 CA 憑證來開發會比較方便。
訂閱:
文章 (Atom)