go與證書crl實踐

2021-07-25 23:32:37 字數 2166 閱讀 7282

在證書中,crl(證書登出列表)是乙個很重要的東西,證書一旦發出,那麼就無法收回。證書的有效性的判斷就會有點麻煩。一種方法就是通過證書的有效期,但是這種方法存在問題,萬一使用者的私鑰丟失,使用者向ca提交證書的吊銷請求。ca對該使用者使用的這張證書進行了吊銷。這張證書就應該是失效的。對於這種情況有兩種方式進行檢測:

crlocsp

crl方法存在一些缺點:其一,crl不可能實時更新。其二,當登出證書的數量很大及使用者基礎很大時,每次crl分發會大量消耗網路頻寬和伺服器處理能力。

今天,先研究crl方式在go中的實現。

證書的crl內容是存放在證書的擴充套件中。證書在go語言中使用的結構是x509.certificate這個結構體。延展部分在extensions欄位中。該字段是乙個結構體陣列extensions pkix.extension。該結構體內容如下:

type extension struct
我結合chrome中證書內容的部分進行說明:

其中 id對應的是該延展在rfc規範中的id(即上圖的2.5.29.31),value對應的是內容上圖的, critical即對應的是關鍵

通過extensions中的value字段可以獲取到crl檔案的路徑。那麼就能夠使用net/http包下的方法去獲取到該crl檔案的內容。

在獲取的value中會出現一段`0&0$?」? ?這一段內容,通過抓包發現:

在獲取到id後還有很長一段資料才能獲取到crl的位址,因此我直接用strings進行切分。

crl的解析可以通過x509包下的func parsecrl(crlbytes byte) (*pkix.certificatelist, error)方法。(該方法無法解析der編碼的crl檔案。如果要解析der編碼的crl檔案需要使用parsedercrl())。通過該方法解析後的結構體內容如下:

type certificatelist struct
該結構滿足rfc 5280中的定義:

certificatelist  ::=  sequence  

tbscertlist ::= sequence optional,

crlextensions [0] explicit extensions optional

-- if present, version must be v2

}

tbscertlist中儲存的是吊銷情況。

crl的結構體定義:

crl的內容包括crl的版本號、計算本crl的數字簽名所用的演算法的識別符號、頒發crl的ca的可識別名、crl的發布/更新時間、被吊銷證書的列表以及擴充套件項

在go中所對應的結構體:

type tbscertificatelist struct
raw是原始資料,其他的和rfc中定義一樣。查詢是否呼叫需要看revokedcertificates字段,revokedcertificate的結構體內容如下:

type revokedcertificate struct
其中serialnumber代表的是被吊銷證書的序列號,revocationtime代表吊銷的時間。

通過這裡的serialnumber和證書中的serialnumber進行比較,如果相同則該證書已經被吊銷。

證書吊銷列表 CRL 介紹

一 證書吊銷列表 crl 證書吊銷列表 certificate revocation list 簡稱 crl 是 pki 系統中的乙個結構化資料檔案,該檔案包含了證書頒發機構 ca 已經吊銷的證書的序列號及其吊銷日期。crl 檔案中還包含證書頒發機構資訊 吊銷列表失效時間和下一次更新時間,以及採用的...

證書吊銷列表 CRL 介紹

一 證書吊銷列表 crl 證書吊銷列表 certificate revocation list 簡稱 crl 是 pki 系統中的乙個結構化資料檔案,該檔案包含了證書頒發機構 ca 已經吊銷的證書的序列號及其吊銷日期。crl 檔案中還包含證書頒發機構資訊 吊銷列表失效時間和下一次更新時間,以及採用的...

HTTPS 原理與證書實踐 一)

對於預設的兩台主機而言,早期傳輸資料資訊並沒有通過加密方式傳輸資料,裝置兩端傳輸的資料本身實際是明文的,只要能擷取到傳輸的資料報,就可以直接看到傳輸的資料資訊,所以根本沒有安全性可言。網路安全問題 資料機密性 在網路傳輸資料資訊時,對資料的加密是至關重要的,否則所有傳輸的資料都是可以隨時被第三方看到...