SSL(Secure Sockets Layer)和TLS(Transport Layer Security)是網絡安全領域的重要協議,它們在保護網絡通信中發揮著至關重要的作用。這些協議通過加密和身份驗證機制,確保數據在傳輸過程中的機密性和完整性,防止數據被竊取或篡改。
這些協議的關鍵組成部分之一是SSL/TLS服務器的證書,它為服務器提供了一種身份驗證和加密的方式
詳細解釋SSL/TLS的重要性
以下將詳細解釋SSL/TLS的重要性:
- 加密保護:SSL/TLS協議使用對稱密鑰和非對稱密鑰技術對數據進行加密,確保只有目標接收者能夠解密并閱讀信息。這種加密保護使得敏感信息如信用卡詳情、醫療記錄和個人身份信息在互聯網傳輸時得到保護。
- 身份驗證:SSL/TLS通過證書的使用提供了身份驗證機制。服務器必須出示由可信證書頒發機構簽發的證書,客戶端可以驗證服務器的真實性,以防止中間人攻擊。
- 數據完整性:這些協議確保數據在傳輸過程中不被篡改。任何對傳輸數據的未授權修改都會被檢測出來,從而保證了數據的完整性。
證書的基礎結構
SSL/TLS服務器的證書是基于公鑰基礎設施構建的,其中包含以下幾個關鍵部分:
- 主題:證書的主題指定了證書持有者的詳細信息,包括組織名稱、城市、國家代碼等。
- 頒發者:頒發者是簽發證書的證書頒發機構。
- 公鑰:證書包含一個公鑰,用于加密信息或驗證數字簽名。
- 簽名算法:此部分指明了CA用來簽署證書的加密算法。
- 有效期:證書的有效期起始日期和結束日期,指明了證書的有效期限。
證書鏈分析是理解SSL/TLS安全性的關鍵環節
在網絡安全中,SSL和TLS協議通過加密保障數據傳輸的安全性,而這一過程的核心是證書鏈的驗證。
-
證書鏈的基本概念
- 證書鏈定義:證書鏈是指由多個證書組成的信任鏈,從根證書(Root Certificate)開始,通過一級或多級中間證書(Intermediate Certificates),最終到達服務器證書(Server Certificate)。
- 根證書的作用:根證書是證書鏈的起點,由可信的證書頒發機構(CA)簽發。根證書的公鑰廣泛預裝在各種操作系統和瀏覽器中,因此通常被無條件信任。
- 中間證書的作用:中間證書作為根證書與用戶證書之間的中間環節,起到傳遞信任的作用。它們由根證書簽發,并依次簽發下級證書,形成完整的證書鏈。
- 服務器證書的作用:服務器證書是證書鏈的末端,直接用于SSL/TLS通信中的身份驗證和加密。服務器證書由中間或根證書簽發,證明服務器的真實身份。
-
證書鏈的驗證過程
- 證書路徑構建:客戶端接收到服務器證書后,會檢查證書中指定的頒發者信息,并嘗試構建從服務器證書到可信任根證書的完整路徑。
- 單向驗證與雙向驗證:在某些情況下,只需驗證服務器證書是否由可信CA簽發(單向驗證)。在其他情況下,還需驗證CA的合法性,即從服務器證書到根證書的每一級證書都需要進行驗證(雙向驗證)。
- 證書吊銷狀態檢查:客戶端可以通過查詢證書吊銷列表(CRL)或在線證書狀態協議(OCSP)來檢查證書是否被吊銷,確保證書的有效性。
- 簽名驗證:每個證書都包含上一級證書的簽名。客戶端會使用上一級證書的公鑰驗證該簽名的合法性,從而確保整個證書鏈的完整性和真實性。
-
證書鏈的重要性
- 防止中間人攻擊:通過完整的證書鏈驗證,客戶端可以確保自己與真正的服務器進行通信,而非被中間人冒充的假服務器。
- 增強用戶信任:當瀏覽器能夠成功驗證證書鏈并顯示安全鎖標志時,用戶對網站的信任度會提高,這在電子商務和敏感信息傳輸中尤為重要。
-
證書鏈的潛在問題與解決方案
- 路徑驗證失敗:如果客戶端無法構建有效的證書路徑或某個證書無法通過驗證,會導致路徑驗證失敗。這通常會引起瀏覽器的安全警告,提示用戶證書不可信。
- 中間證書缺失:如果服務器沒有提供完整的證書鏈,而是僅提供了服務器證書,部分客戶端可能無法自動獲取和驗證中間證書,造成驗證失敗。解決這一問題的方法是在服務器配置中包含完整的證書鏈。
- 根證書不信任:如果客戶端不信任根證書,整個證書鏈也會被認為是不可信的。因此,選擇廣泛信任的CA頒發的證書至關重要。
-
實際案例分析
- 案例一:Let’s Encrypt:Let’s Encrypt是一個廣泛使用的免費CA,其證書鏈包括一個根證書和一個中間證書。由于其根證書已被大多數現代瀏覽器預信任,因此在使用時通常不會出現驗證問題[1]。
- 案例二:自簽名證書:一些網站可能會選擇使用自簽名證書來節省成本,但由于這些證書不是由可信CA簽發,因此在公共網絡上幾乎總是會引發瀏覽器的安全警告。
- 案例三:過期中間證書:如果服務器的中間證書過期,即使根證書和服務器證書仍然有效,也會導致整個證書鏈驗證失敗。解決這個問題需要更新中間證書或重新生成完整的證書鏈。
什么是簽名算法
簽名算法是一種用于驗證數據完整性、數據來源和抗否認的技術。在密碼學中,簽名算法是利用非對稱加密的原理,通過私鑰進行簽名,而公鑰用于驗證簽名的合法性,從而確保消息的真實性和安全性。
簽名算法的核心作用在于提供一個安全的方法來驗證信息確實由特定的發送方發出,并且內容自簽名后未被篡改。這一過程通常涉及到對原始信息進行哈希處理,然后使用發送方的私鑰對哈希值進行加密,形成數字簽名。接收方收到信息后,可以使用發送方的公鑰對簽名進行解密驗證。
對于常用的簽名算法,主要包括RSA、DSA和ECDSA三種。RSA是一種非常經典的算法,廣泛用于SSL證書、代碼簽名等場景。DSA則專門用于數字簽名,不能用于加密和解密,其優點是速度較快。ECDSA則是基于橢圓曲線密碼學的簽名算法,相對于RSA和DSA,其具有更高的安全性和更快的處理速度。
在實際應用中,數字簽名常常應用于軟件發布、文件傳輸、在線交易等領域,以確保信息的完整性和真實性。例如,下載軟件時,開發者通常會提供MD5或SHA256散列值,用戶可以通過驗證這些散列值來確保所下載的文件未被篡改。同樣,在線支付過程中,通過數字簽名驗證可以確保交易信息的安全和真實。
此外,選擇適當的簽名算法也至關重要。RSA算法因其歷史悠久和廣泛的支持而被普遍接受,但ECDSA由于其更高的安全性和效率正逐漸受到重視。在選擇算法時,除了考慮安全性外,還需考慮性能、兼容性和實現的便利性等因素。
SSL/TLS證書有效期
證書有效期是SSL/TLS證書有效性的時間范圍,通常為13個月。 SSL(Secure Sockets Layer)和TLS(Transport Layer Security)證書用于在互聯網上保護數據的安全傳輸,它們通過加密和身份驗證機制防止數據被竊取或篡改。證書的有效期是其重要屬性之一,決定了證書能夠在多長時間內提供安全保障。以下將詳細分析證書有效期的各個方面:
- 證書有效期的歷史變化
- 早期規定:在2011年之前,SSL/TLS證書的有效期通常為8-10年。隨著時間的推移,為了提高安全性,有效期逐漸縮短。
- 逐步縮短:2011年,CA/B論壇將證書有效期縮短至5年。2015年,有效期進一步縮短至3年。2018年,有效期再次縮短為2年。
- 最新規定:從2020年9月1日起,主流瀏覽器廠商如蘋果、谷歌和火狐推動了一項新政策,要求SSL/TLS證書的最長有效期不得超過13個月(398天)。
- 為什么證書有效期要縮短
- 安全性提升:縮短證書有效期可以更頻繁地更新加密算法和密鑰,降低被破解的風險。這有助于應對快速發展的網絡安全威脅。
- 減少舊證書數量:較短的有效期迫使網站管理員定期更新證書,從而減少了被遺忘或被忽視的舊證書數量,提高了整體網絡安全性。
- 快速響應漏洞:一旦發現加密算法或證書管理方面的漏洞,短期證書可以更快地推動修復和更新,確保系統安全。
- 證書有效期對企業的影響
- 安全管理優勢:短期證書能夠促使企業保持對安全措施的關注和更新,從而使用最新的加密技術和標準。
- 管理負擔加重:需要每年更新證書會增加IT管理人員的工作負擔和管理成本。對于擁有大量服務器和證書的企業來說,這一挑戰尤為顯著。
- 經濟成本增加:頻繁更新證書可能會增加企業的運營成本,包括人工費、管理費等。
- 如何查看和管理證書有效期
- 在瀏覽器中查看:訪問網站時,點擊地址欄的安全鎖標志,可以查看SSL證書的有效期。
- 使用工具查看:利用各種在線工具,只需輸入域名即可檢測到SSL證書的詳細信息,包括有效期。
- 自動化管理:對于大量證書的管理,建議采用自動化工具進行監控和更新,以避免因疏忽導致證書過期。
- 證書有效期過期的實際案例
- 特斯拉APP宕機:2020年,特斯拉APP因SSL證書過期導致大面積宕機,用戶無法正常使用手機鑰匙功能。
- 美國政府網站故障:2018年,美國國家航空航天局、司法部等80多個政府網站因SSL證書過期出現無法訪問的情況。
- 愛立信手機服務中斷:同年,愛立信手機服務因數字證書過期,導致數百萬用戶無法發短信或打電話。
頒發者可信度
頒發者可信度是評估SSL/TLS證書安全性的重要指標之一。在網絡安全中,SSL和TLS證書通過加密和身份驗證機制保護數據傳輸的安全性。而證書的頒發者,即證書頒發機構(CA),在信任鏈中扮演著至關重要的角色。以下將詳細分析頒發者可信度的各個方面:
- CA的信任基礎
- 法律授權:CA的合法性通常基于國家法律或國際認可,確保其具備合法的資格簽發受信任的證書。
- 技術能力:CA需要具備強大的加密技術和管理能力,以保證證書的生成、分發和吊銷過程的安全性和可靠性。
- 中立性:CA必須保持嚴格的中立性,不受任何第三方影響,公正地處理證書相關事務。
- CA的驗證流程
- 域名驗證:對于域驗證(DV)證書,CA只需驗證申請者是否控制了相應的域名。
- 組織驗證:對于組織驗證(OV)證書,CA會進一步驗證組織的身份和合法性,確保申請者是合法實體。
- 擴展驗證:擴展驗證(EV)證書要求最嚴格,包括詳盡的背景調查和法律文件審核,確保申請者的合法身份和業務真實性。
- CA的公信力
- 市場認可度:知名CA如VeriSign、DigiCert、GlobalSign等因其長期的良好表現和廣泛預裝在各種設備上的根證書而享有較高聲譽。
- 用戶反饋:用戶對CA服務的評價也會影響其公信力,包括響應速度、技術支持和問題解決能力。
- 透明度:CA的透明度越高,用戶越能了解其運營和策略,從而增強信任感。
- CA的安全記錄
- 歷史安全事件:CA歷史上是否發生過重大安全事件,如未經授權的證書簽發,會對可信度產生重大影響。
- 漏洞響應:CA面對發現的漏洞和安全威脅時,其響應速度和處理方式也是衡量可信度的重要標準。
- 持續監控:CA是否擁有持續的安全監控和改進機制,以確保長期保持高水平的安全性。
- 頒發者可信度的實際案例
- DigiNotar事件:2011年,荷蘭CA DigiNotar遭受黑客攻擊,導致其信任基礎完全崩潰,最終破產。
- Symantec的公信力問題:2018年,Symantec因未能妥善管理其PKI基礎設施而被瀏覽器廠商逐步不信任其舊證書,損害了其公信力。
- Let’s Encrypt的崛起:作為一個免費、自動化和開放的CA,Let’s Encrypt以其創新和透明性迅速獲得了廣泛的市場認可。
公鑰強度
公鑰強度是衡量非對稱加密算法安全性的關鍵指標,它決定了密碼破解的難易程度和計算復雜度。在密碼學中,公鑰和私鑰成對出現,公鑰用于加密數據,而私鑰則用于解密。已知私鑰可以推導出公鑰,但公鑰不能反推私鑰,從而確保了加密信息的安全性。以下將詳細分析公鑰強度的各個方面:
- 密鑰長度與強度
- RSA算法:RSA算法是最廣泛使用的非對稱加密算法之一,其強度主要取決于密鑰長度。目前,RSA 1024位密鑰已不再安全,逐漸被2048位及以上的密鑰替代。RSA 2048位密鑰可提供約112位的安全強度,而3072位密鑰提供128位安全強度。
- ECC算法:相比于RSA,橢圓曲線密碼(ECC)算法具有更高的單位比特安全強度。例如,256位的ECC密鑰強度已經比2048位的RSA密鑰強度要高。
- SM2算法:作為國產密碼標準,SM2算法也是基于橢圓曲線的,其256位密鑰即可達到較高的安全強度。
- 密碼算法與強度
- 對稱式加密算法:這類算法的密鑰長度直接決定了窮舉攻擊的復雜度,例如AES算法的密鑰長度即代表其安全強度。
- 非對稱式加密算法:RSA和ECC等算法的密鑰長度不僅影響加密速度,還決定破解難度。長密鑰意味著更高的安全強度。
- Hash算法:如SHA-2系列算法,其強度體現在抗碰撞和雪崩效應上。
- 國際與國產算法
- RSA與SM2:RSA算法由美國NSA提出,密鑰長度不斷增加以應對安全威脅;SM2則是中國自主研發的,基于橢圓曲線,相對于RSA在同等安全強度下運算速度更快。
- ECC與SM2:SM2與國際上的ECC算法相對應,其簽名、密鑰交換和公鑰加密功能分別對應于ECC算法的ECDSA、ECDH、ECIES。
- 不同應用場景的密鑰要求
- 金融級應用:根據國際建議,金融級應用的加密算法密鑰強度應達到112位,長期保護則需128位或更高。
- 國家安全應用:美國NSA對SECRET級別信息的密鑰強度要求為128位,TOP SECRET級別則需192位。
- 密碼算法發展趨勢
- 對稱密碼算法:如AES算法,密鑰長度將逐漸從128位增加到192位、256位。
- 非對稱密碼算法:ECC算法將逐漸占據重要地位,密鑰長度從224位增加;RSA算法密鑰長度也在增加。
- 輕量級密碼:適用于資源受限環境,如物聯網設備。這些算法包括DESL、HIGHT等對稱密碼,及NTRU、BlueJay等非對稱密碼。
- 國密算法與安全性
- SM2:基于橢圓曲線,設計時考慮多種攻擊手段,具有較高的安全性。
- SM3:輸出長度為256比特的散列算法,抗碰撞能力強,設計上考慮了雪崩效應。
- SM4:分組密碼算法,128比特密鑰和分組長度,經過多輪安全性評估,尚未有公開的有效攻擊方法。
證書擴展
證書擴展是數字證書中的一個重要組成部分,它提供了一種機制,允許在證書中包含額外的屬性和信息,以增強證書的功能性和靈活性。
自簽名證書可以進行私有擴展,這對于內部使用或測試環境非常有用。標準擴展則適用于由CA機構簽發的證書,這些擴展項包括SAN(Subject Alternative Name)、密鑰標識符、密鑰用法和基本約束等,它們大大增加了證書的使用場景和靈活性。特別是SAN擴展,它允許一張證書綁定多個域名、IP地址或電子郵件地址,這對多域名支持尤其重要。
X.509標準定義了公鑰證書的字段和擴展名,其中版本3引入了對證書擴展的支持,這為證書提供了更多屬性與公鑰關聯的方法。例如,subjectAltName擴展可以包含電子郵件地址、域名、IP地址等,并且這些值可以有多個,這在實際應用中非常重要。
當一個網站使用TLS證書進行身份標記時,如果證書中包含subjectAltName,系統將優先使用這些信息來識別證書持有者,而不是依賴于Subject子項。這種機制在現代網站的TLS實現中非常常見,以確保網站身份的準確識別。
證書吊銷列表(CRL)和在線證書狀態協議(OCSP)
證書吊銷列表(CRL)和在線證書狀態協議(OCSP)都是用于驗證數字證書有效性的重要機制,它們各自以不同的方式幫助維護網絡安全和信任。
CRL是一種由證書頒發機構(CA)定期發布的文件,其中列出了所有已吊銷的證書序列號及其吊銷日期。這種機制允許網站管理員和瀏覽器檢查特定證書是否已被吊銷。CRL的訪問方式通常是通過下載最新的CRL文件,并與本地證書進行比對來確認其有效性。這種方法是靜態的,意味著它需要定期手動更新CRL文件,以確保信息的最新性。
相比之下,OCSP提供了一種動態的證書狀態檢查方法。通過實時向CA發送請求,OCSP能夠即時返回證書的狀態,包括“正常”、“吊銷”或“未知”。這種即時性使得OCSP在需要快速驗證證書狀態的場景中特別有用,如在線事務處理時。
CRL的更新頻率通常較低,這可能導致其信息可能不是最即時的。更新的頻率取決于CA的政策,可能是每天一次或每月一次。因此,盡管CRL提供了一種可行的證書狀態檢查方式,但它不能提供實時的證書狀態信息。
而OCSP正好彌補了CRL的這一不足,它通過實時查詢,能夠提供即時的證書狀態信息。當用戶需要確保交易時對方證書的即時有效性時,OCSP提供了一個可靠的解決方案。然而,OCSP的響應時間受到服務器性能和網絡延遲的影響,可能在高并發場景下影響性能。
從應用場景來看,CRL更適合于不頻繁變更證書的場景,或者在對實時性要求不高的環境中使用。例如,一些企業內部系統可能會選擇CRL作為驗證員工證書狀態的方式。相反,對于那些要求高安全性和即時性的應用場景,如電子商務平臺,更傾向于使用OCSP來確保每次交易的安全性。
在選擇使用CRL還是OCSP時,還應考慮系統的性能和網絡環境。CRL由于需要定期下載,可能會增加網絡負擔,特別是在網絡條件受限的環境下。而OCSP雖然提供了實時的驗證,但需要維護穩定的網絡連接到OCSP服務器,并且其響應速度必須足夠快以支持大量的實時查詢。
使用OpenSSL工具分析SSL/TLS證書
使用OpenSSL工具分析SSL/TLS證書可以提供證書的詳細信息,包括其結構、內容、有效性等。以下是一些常用的OpenSSL命令示例,用于分析證書:
1. 顯示證書信息
要查看證書的詳細信息,可以使用以下命令:
openssl x509 -in certificate.crt -text -noout
這個命令將顯示證書的文本表示形式,包括版本、序列號、簽名算法、有效期、主題信息、頒發者信息等。
2. 檢查證書鏈
要驗證證書鏈,可以使用-untrusted
選項和中間CA證書或鏈中的其他證書:
openssl verify -CAfile intermediate.crt certificate.crt
如果證書鏈有效,命令將顯示類似certificate.crt: OK
的消息。
3. 檢查證書有效期
要快速查看證書的有效期,可以使用:
openssl x509 -in certificate.crt -dates -noout
這將輸出證書的"notBefore"和"notAfter"日期。
4. 提取證書的公鑰
要提取并顯示證書的公鑰,可以使用:
openssl x509 -in certificate.crt -pubkey -noout
這將顯示證書公鑰的詳細信息。
5. 驗證證書簽名
要驗證證書的簽名,可以使用:
openssl x509 -in certificate.crt -check_ss_sig
如果證書是由其頒發者正確簽名的,命令將顯示簽名驗證成功的消息。
6. 檢查證書是否被吊銷
要檢查證書是否被吊銷,可以使用CRL或OCSP。對于CRL,可以使用:
openssl crl -in crl_number.crl -noout -text
對于OCSP,可以使用:
openssl ocsp -issuer issuer_certificate.pem -cert certificate_to_check.crt -url http://ocsp.certificateAuthority.com
這些命令將檢查證書是否在CRL中或OCSP響應中被標記為吊銷。
7. 顯示證書的指紋
要顯示證書的指紋,可以使用:
openssl x509 -in certificate.crt -noout -fingerprint -sha256
這將輸出證書的SHA-256指紋,可用于比較和驗證。
8. 導出證書為DER格式
如果需要將證書導出為DER格式,可以使用:
openssl x509 -outform der -in certificate.crt -out certificate.der
這將證書從PEM格式轉換為DER格式。
9. 從證書中提取證書策略
要查看證書的CPS(證書策略)或任何其他擴展,可以使用:
openssl x509 -in certificate.crt -extfile <(echo "[ v3_ca ]") -extensions v3_ca -noout -text
這將顯示證書中的自定義擴展信息。
10. 顯示證書的主題備用名稱(SAN)
要查看證書的SAN擴展,可以使用:
openssl x509 -in certificate.crt -text -noout -subject_alt_name
這將列出證書支持的所有備用域名或IP地址。
這些命令提供了對SSL/TLS證書進行深入分析的基礎,可以幫助你了解證書的屬性、驗證其安全性和信任鏈,以及確保它適用于你的安全需求。
...int main (int argc, char **argv)
{...static struct option long_options[] = {{ "bits", no_argument, 0, 'b' },{ "chain", no_argument, 0, 'c' },{ "cipher", no_argument, 0, 'C' },{ "issuer", no_argument, 0, 'i' },{ "method", no_argument, 0, 'm' },{ "no-sni", no_argument, 0, 'N' },{ "quiet", no_argument, 0, 'q' },{ "raw", no_argument, 0, 'r' },{ "serial", no_argument, 0, 'S' },{ "signature-algorithm", no_argument, 0, 'A' },{ "subject", no_argument, 0, 's' },{ "validity", no_argument, 0, 'V' },{ "help", no_argument, 0, 'h' },{ "version", no_argument, 0, 'v' },};while ((opt_value = getopt_long(argc, argv, "bcCimNqrSAsVhv", long_options, &long_opt_index)) != -1) {switch (opt_value) {case 'b':bits = 1;continue;case 'c':chain = 1;continue;case 'C':cipher = 1;continue;case 'i':issuer = 1;continue;case 'm':method = 1;continue;case 'N':no_sni = 1;continue;case 'q':quiet = 1;pad_fmt = 0;continue;case 'r':raw = 1;continue;case 'S':serial = 1;continue;case 'A':sig_algo = 1;continue;case 's':subject = 1;continue;case 'V':validity = 1;continue;case 'h':usage();exit(EXIT_SUCCESS);case 'v':fprintf(stdout, "%s\n", KEUKA_VERSION);exit(EXIT_SUCCESS);case '?':usage();exit(EXIT_FAILURE);default:break;}}
.../*** 限制作為參數給定的主機名的長度*/if (length(argv[last_index]) > MAX_HOSTNAME_LENGTH) {fprintf(stderr, "Error: Hostname exceeds maximum length of 256 characters.\n");exit(EXIT_FAILURE);}/*** argv中的最后一個元素應該是對等主機名*/hostname = argv[last_index];/*** 組裝請求的URL*/copy(url, protocol);concat(url, "://");concat(url, hostname);/*** 運行OpenSSL初始化任務*/SSL_load_error_strings();ERR_load_crypto_strings();OpenSSL_add_all_algorithms();OpenSSL_add_all_digests();SSL_library_init();/*** Start execution clock.*/start = clock();/*** 初始化新的BIO.*/bp = BIO_new_fp(stdout, BIO_NOCLOSE);ssl_method = SSLv23_client_method();if (!quiet) {BIO_printf(bp,"%s [%fs] Establishing SSL context.\n",KEUKA_NEUTRAL_INDICATOR,get_elapsed_ticks(start));}/*** 建立新的SSL上下文*/if (is_null(ctx = SSL_CTX_new(ssl_method))) {/*** 以進度格式顯示錯誤,除非給出--quiet。*/if (!quiet) {BIO_printf(bp,"%s [%fs] Error: Unable to establish SSL context.\n",KEUKA_NEUTRAL_INDICATOR,get_elapsed_ticks(start));} else {BIO_printf(bp, "Error: Unable to establish SSL context.\n");}goto on_error;}if (!quiet) {BIO_printf(bp,"%s [%fs] SSL context established.\n",KEUKA_NEUTRAL_INDICATOR,get_elapsed_ticks(start));}/*** 建立TCP套接字連接*/server = mksock(url, bp);if (!quiet) {BIO_printf(bp,"%s [%fs] Establishing connection to %s.\n",KEUKA_OUTBOUND_INDICATOR,get_elapsed_ticks(start),hostname);}/*** 如果建立連接時出現問題,請退出。*/if (is_error(server, -1)) {if (!quiet) {BIO_printf(bp,"%s [%fs] Error: Unable to resolve hostname %s.\n",KEUKA_INBOUND_INDICATOR,get_elapsed_ticks(start),hostname);} else {BIO_printf(bp, "Error: Unable to resolve hostname %s.\n", hostname);}exit(EXIT_FAILURE);}if (!quiet) {BIO_printf(bp,"%s [%fs] Connection established.\n",KEUKA_INBOUND_INDICATOR,get_elapsed_ticks(start));}/*** 建立連接,在客戶端模式下設置狀態。*/ssl = SSL_new(ctx);SSL_set_connect_state(ssl);/*** Disable SNI support if --no-sni was given.*/if (!no_sni) {SSL_set_tlsext_host_name(ssl, hostname);}if (!quiet) {BIO_printf(bp,"%s [%fs] Attaching SSL session to socket.\n",KEUKA_NEUTRAL_INDICATOR,get_elapsed_ticks(start));}attach = SSL_set_fd(ssl, server);/*** 將SSL會話連接到TCP套接字。*/if (is_error(attach, -1)) {if (!quiet) {BIO_printf(bp,"%s [%fs] Error: Unable to attach SSL session to socket.\n",KEUKA_NEUTRAL_INDICATOR,get_elapsed_ticks(start));} else {BIO_printf(bp, "Error: Unable to attach SSL session to socket.\n");}goto on_error;}if (!quiet) {BIO_printf(bp,"%s [%fs] SSL session attached, handshake initiated.\n",KEUKA_OUTBOUND_INDICATOR,get_elapsed_ticks(start));}status = SSL_connect(ssl);if (status != 1) {if (!quiet) {BIO_printf(bp,"%s [%fs] Error: Could not build SSL session with %s. Handshake aborted.\n",KEUKA_NEUTRAL_INDICATOR,get_elapsed_ticks(start),url);} else {BIO_printf(bp,"Error: Could not build SSL session with %s. Handshake aborted.\n",url);}goto on_error;}ssl_cipher = SSL_get_current_cipher(ssl);if (!quiet) {BIO_printf(bp,"%s [%fs] %s negotiated, handshake complete.\n",KEUKA_INBOUND_INDICATOR,get_elapsed_ticks(start),SSL_CIPHER_get_version(ssl_cipher));if (pad_fmt) {BIO_printf(bp, "\n");}}/*** 如果給定了--cipher,則打印使用的密碼。*/if (cipher) {BIO_printf(bp,"--- Cipher: %s\n",SSL_CIPHER_get_name(ssl_cipher));}/**如果給定了--method選項,則輸出用于握手的方法的版本*/if (method) {BIO_printf(bp,"--- Method: %s\n",SSL_get_version(ssl));}/*** 如果給定了--chain,則打印完整的chain。*/if (chain) {/*** 獲取對等證書鏈。*/if (is_null(fullchain = SSL_get_peer_cert_chain(ssl))) {BIO_printf(bp, "Error: Could not get certificate chain from %s.\n", url);goto on_error;}BIO_printf(bp, "--- Certificate Chain:\n");/*** 輸出證書鏈*/
..../*** 證書的輸出簽名算法*/if (sig_algo) {if (pad_tfmt) {BIO_printf(bp, "%s%7s", "\n", "");} else {pad_tfmt = 1;}#if OPENSSL_VERSION_NUMBER >= 0x10100000LX509_get0_signature(&asn1_sig, &sig_type, tcrt);
#elsesig_type = tcrt->sig_alg;asn1_sig = tcrt->signature;
#endifBIO_printf(bp, "--- Signature Algorithm: ");sig_type_err = i2a_ASN1_OBJECT(bp, sig_type->algorithm);if (is_error(sig_type_err, -1) || is_error(sig_type_err, 0)) {BIO_printf(bp, "Could not get signature algorithm.");}}...crtname = X509_get_subject_name(crt);pubkey = X509_get_pubkey(crt);/*** 輸出證書主題信息*/if (subject) {BIO_printf(bp, "--- Subject: ");X509_NAME_print_ex(bp, crtname, 0, XN_FLAG_SEP_COMMA_PLUS);BIO_printf(bp, "\n");}/*** 輸出證書頒發者信息。*/if (issuer) {BIO_printf(bp, "--- Issuer: ");X509_NAME_print_ex(bp, X509_get_issuer_name(crt), 0, XN_FLAG_SEP_CPLUS_SPC);BIO_printf(bp, "\n");}if (bits) {BIO_printf(bp, "%s%d\n", "--- Bits: ", EVP_PKEY_bits(pubkey));}.../*** If --signature-algorithm option was given,* 證書的輸出簽名算法*/if (sig_algo) {
#if OPENSSL_VERSION_NUMBER >= 0x10100000LX509_get0_signature(&asn1_sig, &sig_type, crt);
#elsesig_type = crt->sig_alg;asn1_sig = crt->signature;
#endifBIO_printf(bp, "--- Signature Algorithm: ");sig_type_err = i2a_ASN1_OBJECT(bp, sig_type->algorithm);BIO_printf(bp, "\n");if (is_error(sig_type_err, -1) || is_error(sig_type_err, 0)) {BIO_printf(bp, "Error: Could not get signature algorithm.\n");}}/*** 輸出不在前/不在后時間戳的范圍*/if (validity) {BIO_printf(bp, "%s", "--- Validity:\n");BIO_printf(bp, "%4s%s", "", "--- Not Before: ");ASN1_TIME_print(bp, X509_get_notBefore(crt));BIO_printf(bp, "\n");BIO_printf(bp, "%4s%s", "", "--- Not After: ");ASN1_TIME_print(bp, X509_get_notAfter(crt));BIO_printf(bp, "\n");}/*** 輸出原始證書內容*/if (raw) {BIO_printf(bp, "\n");PEM_write_bio_PUBKEY(bp, pubkey);BIO_printf(bp, "\n");PEM_write_bio_X509(bp, crt);BIO_printf(bp, "\n");}}....return EXIT_FAILURE;
}
If you need the complete source code, please add the WeChat number (c17865354792)
用于建立一個安全的SSL/TLS連接。它接受一系列命令行參數,如–bits, --chain, --cipher, --issuer, --method, --no-sni, --quiet, --raw, --serial, --signature-algorithm, --subject, --validity, --help, 和 --version。這些參數允許用戶指定他們想要從服務器獲取的信息類型。一旦建立了與SSL/TLS服務器的連接,將根據用戶指定的參數獲取證書信息。
總結
SSL/TLS服務器的證書是網絡安全不可或缺的一部分,不僅提供了身份驗證和數據加密,還增強了用戶對網站安全性的信心。隨著網絡攻擊的日益復雜和頻繁,理解和正確實施SSL/TLS證書變得尤為重要。
We also undertake the development of program requirements here. If necessary, please follow the WeChat official account 【程序猿編碼】and contact me
參考:1.https://www.idc.net/help/229710/
2.https://learn.microsoft.com/zh-cn/azure/iot-hub/reference-x509-certificates