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