6.3.4 測的是 CRL 取不到這條測的是 CRL 取到了但它是舊的。CRL 文件本身帶有效期nextUpdate 一過就失效。設備讀到一個已經過期的 CRL該怎么辦標準給的答案是寬容報Warning: CRL expired維持連接繼續(xù)握手。邏輯和 6.3.4 一脈相承。CRL 過期說明發(fā)布方沒有按時更新這是運維流程的問題不是對端證書的問題。為了一個可能只是忘了更新的 CRL 就把連接斷掉代價太大。所以標準還是選擇警告加放行。造一份過期的 CRL正常的 CRL 用 openssl 的ca -gencrl生成默認有效期是從現(xiàn)在開始往后算。要造一份過期的把起止時間往前挪就行openssl ca-configca.cnf-gencrl-outca_expired.crl-batch-notext\-startdate20200101000000Z-enddate20200102000000Z這樣生成的 CRLnextUpdate 停在 2020 年拿到今天用必然是過期的。服務端配置關鍵是讓設備加載這份過期 CRL而不是默認那份X509_STORE*storeSSL_CTX_get_cert_store(ctx);X509_STORE_set_flags(store,X509_V_FLAG_CRL_CHECK);X509_STORE_load_locations(store,certs_keys/ca.crt,NULL);X509_load_crl_file(store,certs_keys/ca_expired.crl,X509_FILETYPE_PEM);然后客戶端正常連openssl s_client-connect127.0.0.1:19998-tls1_2\-certclient.crt-keyclient.key-CAfileca.crt判定檢查項通過標準握手結果成功安全事件Warning: CRL expired連接保持不斷開一個容易踩的坑有些 TLS 實現(xiàn)里CRL 過期默認會被當成硬錯誤處理直接拋X509_V_ERR_CRL_HAS_EXPIRED然后驗證失敗。如果設備不做特殊處理測出來就是斷鏈看起來像是不通過。這時候要先分清是設備故意這么設計的還是它只是沒為這個場景寫分支。標準既然把它列成 Warning設備的 verify 回調里就應該顯式地把這個錯誤碼攔下來、記事件、然后返回繼續(xù)。測之前最好先確認設備有沒有這段邏輯免得白跑一輪。