數字證書簽發,授權等相關以及https建立通訊過程

2021-09-07 07:56:01 字數 2960 閱讀 2445

一直以來都對數字證書的簽發,以及信任等事情一知半解。總算有個閒適的週末來總結和深入一下相關的知識。

ca:ca(certificate authority)是證書的簽發機構,它是負責管理和簽發證書的第三方機構,是受到廣泛信任的機構。一般在我們的電腦中,瀏覽器裡,或者手機裡都會內建一批這樣的受信機構的根證書。

證書信任鏈:

比如我是ca機構我簽發了一封證書 我這份證書是信任b證書的另外b證書又信任了其他的c證書......那麼這條鏈條下去的都可以信任。所以一旦ca機構的根證書不可信了,那麼所有由他簽發出來的證書將全部變得不可信,後果很嚴重。

公鑰密碼體制:

公鑰密碼體制分為三個部分,公鑰、私鑰、加密解密演算法,它的加密解密過程如下:

公鑰密碼體制的公鑰和演算法都是公開的(這是為什麼叫公鑰密碼體制的原因),私鑰是保密的。大家都以使用公鑰進行加密,但是只有私鑰的持有者才能解密。在實際的使用中,有需要的人會生成一對公鑰和私鑰,把公鑰發布出去給別人使用,自己保留私鑰。

ca證書:

顧名思義ca證書就是由ca機構簽發的證書。其實證書誰都可以籤,你也可以自己給自己簽發證書,但是由於你自己並不是被廣泛信任的機構,所以你自己簽發的證書並沒有什麼用。公網也不會信任你的證書。伺服器證書包括以下幾種資訊:

◆issuer (證書的發布機構)

指出是什麼機構發布的這個證書,也就是指明這個證書是哪個公司建立的(只是建立證書,不是指證書的使用者)。對於上面的這個證書來說,就是指"securetrust ca"這個機構。

◆valid from , valid to (證書的有效期)

也就是證書的有效時間,或者說證書的使用期限。 過了有效期限,證書就會作廢,不能使用了。

◆public key (公鑰)

這個我們在前面介紹公鑰密碼體制時介紹過,公鑰是用來對訊息進行加密的,第2章的例子中經常用到的。這個數字證書的公鑰是2048位的,它的值可以在圖的中間的那個對話方塊中看得到,是很長的一串數字。

◆subject (主題)

◆signature algorithm (簽名所使用的演算法)

就是指的這個數字證書的數字簽名所使用的加密演算法,這樣就可以使用證書發布機構的證書裡面的公鑰,根據這個演算法對指紋進行解密。指紋的加密結果就是數字簽名。

◆thumbprint, thumbprint algorithm (指紋以及指紋演算法)

這個是用來保證證書的完整性的,也就是說確保證書沒有被修改過。 其原理就是在發布證書時,發布者根據指紋演算法(乙個hash演算法)計算整個證書的hash值(指紋)並和證書放在一起,使用者在開啟證書時,自己也根據指紋演算法計算一下證書的hash值(指紋),如果和剛開始的值對得上,就說明證書沒有被修改過,因為證書的內容被修改後,根據證書的內容計算的出的hash值(指紋)是會變化的。 注意,這個指紋會使用"ca"證書機構的私鑰用簽名演算法(signature algorithm)加密後和證書放在一起。

ca如何給我們簽發乙個有效證書:

舉個例子方便大家理解,假設我們公司"abc company"花了1000塊錢,向乙個證書發布機構"securetrust ca"為我們自己的公司"abc company"申請了一張證書,注意,這個證書發布機構"securetrust ca"是乙個大家公認並被一些權威機構接受的證書發布機構,我們的作業系統裡面已經安裝了"securetrust ca"的證書。"securetrust ca"在給我們發布證書時,把issuer,public key,subject,valid from,valid to等資訊以明文的形式寫到證書裡面,然後用乙個指紋演算法計算出這些數字證書內容的乙個指紋,並把指紋和指紋演算法用自己的私鑰進行加密,然後和證書的內容一起發布,同時"securetrust ca"還會給乙個我們公司"abc company"的私鑰給到我們。我們花了1000塊錢買的這個證書的內容如下:

×××××××××××××××證書內容開始×××××××××××××××××

issuer : securetrust ca

subject : abc company

valid from : 某個日期

valid to: 某個日期

public key : 一串很長的數字

…… 其它的一些證書內容……

[securetrust ca的私鑰|rsa]      //這個就是"securetrust ca"對這個證書的乙個數字簽名,表示這個證書確實是他發布的,有什麼問題他會負責(收了我們1000塊,出了問題肯定要負責任的)

所以最後在我們使用https的時候究竟發生了什麼:

結合上面這個圖我一步一步講解:

1. 客戶端向乙個需要https訪問的**發起請求。

2. 伺服器將證書傳送給客戶端進行校驗。證書裡面包含了其公鑰。這裡要特別說一下客戶端到底 如何來校驗對方發過來的數字證書是否有效。

首先在本地電腦尋找是否有這個伺服器證書上的ca機構的根證書。如果有繼續下一步,如果沒有彈出警告。

使用ca機構根證書的公鑰對伺服器證書的指紋和指紋演算法進行解密。

得到指紋演算法之後,拿著這個指紋演算法對伺服器證書的摘要進行計算得到指紋。

將計算出的指紋和從伺服器證書中解密出的指紋對比看是否一樣如果一樣則通過認證。

3. 校驗成功之後,客戶端會生成乙個隨機串然後使用伺服器證書的公鑰進行加密之後傳送給伺服器。

4. 伺服器通過使用自己的私鑰解密得到這個隨機值。

5. 伺服器從此開始使用這個隨機值進行對稱加密開始和客戶端進行通訊。

6. 客戶端拿到值用對稱加密方式 使用隨機值進行解密。

為什麼不一直使用非對稱進行加密,而是在類似握手之後開始使用對稱加密演算法進行https通訊:

非對稱加密的消耗和所需的計算以及時間遠比對稱加密消耗要大,所以在握手和認證之後,伺服器和客戶端就開始按照約定的隨機串,對後續的資料傳輸進行加密。

reference:

數字證書及ca的掃盲介紹

數字證書原理

數字證書理解(CA證書簽名原理)

為了防止中間人攻擊和釣魚 對稱金鑰體系 對稱加密 和非對稱金鑰體系 非對稱加密 都提供2份秘鑰。公鑰私鑰是概念上的,發布出去的為公鑰,留在手上的為私鑰,實質上不存在公私鑰區別。特殊的 在實際操作中,生成rsa 特別的 一種加密方式 金鑰時會有兩個秘鑰,其中乙份包含另乙份的完整資訊 此時預設命名為私鑰...

此證書簽發者無效

問題 這幾天一直在忙底層 優化,無心顧及上層人員反饋的問題。昨晚同事加班時給我發qq反饋,我們的ios研發證書不能用了,並且確定證書沒有過期。分析 開啟我的蘋果機上的 鑰匙串訪問 看了一下我們證書。哇靠!上面提示一行紅字 此證書簽發者無效 然後發現蘋果開發授權證書也過期了,如圖1所示。估計就這個證書...

iOS開發證書顯示 證書簽發者無效

字數276 閱讀467 喜歡10 新年第一天上班,不少ios開發的同志們驚呼 臥槽。我的開發者證書怎麼顯示證書簽發者無效?難倒過期了?我剛申請的啊?還是我過個年蘋果就倒閉了?nonono。其實原因在於,蘋果在1月18號就發了宣告,要求開發者們最晚在2月14號前更新自己電腦的安全證書。剛好2月14,1...