題 有關SSL的證書和密鑰有什麼區別?


每當我試圖了解有關SSL的任何內容時,我總是很難跟踪“密鑰”和“證書”所指的內容。我擔心很多人會錯誤地或互換地使用它們。密鑰和證書之間是否存在標準差異?


88
2017-07-15 17:55


起源


用於SSL的證書主要基於PKI en.wikipedia.org/wiki/Public-key_cryptography - Zoredache


答案:


證書包含公鑰。

除了包含公鑰之外,證書還包含其他信息,例如頒發者,證書應該用於什麼以及其他類型的元數據。

通常,證書本身使用私鑰進行簽名,以驗證其真實性。


80
2017-07-15 18:01



證書是密鑰的公共組件,而不是整個密鑰。 - Zoredache
我做了更正。 :) - LawrenceC
@Zoredache如果證書通常只有一個公鑰,是否有一個好的名稱來調用包含證書和私鑰的.p12或.pfx文件? - drs
這些額外信息埋在哪裡?我正在看一些證書,這對我來說都是胡言亂語 - CodyBugstein
你正在看的亂碼是Base64編碼。這樣做可能是出於類似的原因,電子郵件附件被轉換為 - 基本上是為了確保它們可以通過專為ASCII設計的協議和機制進行傳輸,無需隨意修改,也不必擔心換行符,括號等內容。 openssl 命令可以解碼和解析這些,或者您可以使用以下在線實用程序: lapo.it/asn1js - LawrenceC


這兩張照片一起向我解釋了一切:

資源: linuxvoice

enter image description here

資源: infosecinstitute

enter image description here


34
2018-04-05 11:16



相關的xkcd - Blacksilver
尼斯。 1澄清:第1張照片是標準(單向)TLS驗證;第二,相互(雙向)認證。在第一個中額外調出1個將進一步幫助解釋信任是如何實際建立的(所有這些都在那個看起來更友好的圖片中):在客戶端獲得服務器的公鑰證書之後,客戶端驗證簽署了該信任的CA服務器的證書包含在客戶端的可信CA的私有列表中(確定它現在也信任該CA)。然後,向服務器發送會話密鑰是安全的,每個會話密鑰現在都可以加密和解密後續通信。 - user1172173


讓我們說公司A有一個 密鑰對 並且需要發布他的公鑰用於公共用途(在他的網站上也稱為ssl)。

  • 公司A必須向證書頒發機構(CA)提出證書申請(CR),以獲得其密鑰對的證書。
  • 公司A的密鑰對的公鑰而非私鑰包含在證書請求的一部分中。
  • 然後,CA使用公司A的身份信息來確定請求是否符合CA頒發證書的標準。
     如果CA批准該請求,它會向公司A頒發證書。簡而言之,CA使用其(CA)私鑰對公司A的公鑰進行簽名,以驗證其真實性。

因此,使用有效CA的私鑰簽署的公司A的公鑰稱為公司A的證書。


33
2017-12-16 06:40



公司A是否將其(公司A)私鑰與其(公司A)證書相關聯? - Tola Odejayi
不,私鑰仍然是A的privet。 - Mohsen Heydari
那麼公司A的私鑰在哪裡使用? - sivann
經過上述手續。 A公司將在其網站上擁有有效的SSL證書。任何與網站通信的訪問者(瀏覽器)都將使用證書公鑰來加密他的消息。具有SSL證書私鑰的公司A是唯一可以解密該消息的人。 - Mohsen Heydari
我猜公司A是男性。 - DimiDak


一個SSL 證書 從受信任的證書頒發機構獲得,該證書頒發機構擔保網站的安全連接。 SSL證書通常包含身份驗證徽標以及加密和解密要發送到計算機的數據所需的公鑰。 SSL密鑰功能

幾個SSL 按鍵 可以在會話期間生成。它們用於加密和解密發送到計算機和從計算機發送的信息。密鑰用於驗證信息是否未被修改或篡改。

生命週期差異

證書的持續時間比SSL密鑰長。 SSL證書從證書頒發機構獲得,可以由銀行和企業定期更新。另一方面,SSL密鑰或會話密鑰在會話期間唯一生成,並在會話結束時被丟棄。

在這裡閱讀更多


3
2017-07-15 18:02





讓我舉個例子來解釋一下。

在基於正常密鑰對的PKI中,存在私鑰和公鑰。

在基於證書的系統中,有私鑰和證書。證書包含的信息多於公鑰。

演示(您可以生成證書和私鑰): http://www.selfsignedcertificate.com/

您可以下載打開私鑰文件和證書文件,您會看到證書文件包含的信息如下所示。 enter image description here enter image description here

您可以從此站點匹配生成的證書(由文本編輯器打開)和私鑰(由文本編輯器打開): https://www.sslshopper.com/certificate-key-matcher.html

如果證書與客戶端的私鑰匹配,則客戶端確定該證書由客戶端提供或由客戶端的可信代理(CA)提供。

但是,僅私鑰和基於證書的通信存在問題

因為,任何人都可以生成自己的證書和私鑰,因此除了服務器知道與證書的公鑰匹配的私鑰之外,簡單的握手不能證明服務器的任何信息。解決這個問題的一種方法是讓客戶擁有 一套 它信任的一個或多個證書。 如果證書不在集合中,則不信任服務器

這種簡單的方法有幾個缺點。服務器應該能夠隨著時間的推移升級到更強的密鑰(“密鑰輪換”),這將用新的密鑰替換證書中的公鑰。不幸的是,現在客戶端應用程序必須更新,因為本質上是服務器配置更改。如果服務器不在應用程序開發人員的控制之下,例如,如果它是第三方Web服務,則這尤其成問題。如果應用程序必須與任意服務器(如Web瀏覽器或電子郵件應用程序)進行通信,則此方法也存在問題。

為了解決這些缺點,服務器通常配置有來自知名發行人的證書,稱為證書頒發機構(CA)。主機平台(客戶端)通常包含它信任的眾所周知的CA列表。與服務器類似,CA具有證書和私鑰。為服務器頒發證書時,CA使用其私鑰對服務器證書進行簽名。然後,客戶端可以驗證服務器是否具有由平台已知的CA頒發的證書。

然而,在解決一些問題時,使用CA引入了另一個問題。由於CA為許多服務器頒發證書,因此您仍需要某種方法來確保與所需的服務器通信。為解決此問題,CA頒發的證書使用特定名稱(如gmail.com)或通配符集(如* .google.com)標識服務器。

以下示例將使這些概念更加具體。在命令行下面的代碼片段中,openssl工具的s_client命令查看Wikipedia的服務器證書信息。它指定端口443,因為這是HTTPS的默認值。該命令將openssl s_client的輸出發送到openssl x509,後者根據X.509標準格式化有關證書的信息。具體地,該命令要求包含服務器名稱信息的主題和標識CA的發行者。

$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA

您可以看到該證書是由RapidSSL CA為符合* .wikipedia.org的服務器頒發的。

如您所見,由於CA向服務器發送的這些附加信息,客戶端可以很容易地知道它是否正在與其服務器通信。


2
2018-05-09 20:57





好吧,讓我們打破這一點,以便非技術人員能夠理解。

可以這樣想。證書就像銀行的保險箱一樣。它包含許多重要的東西;通常包含您身份的東西。證書有一個公鑰,需要一個私鑰才能打開它。

您的保險箱也需要兩把鑰匙打開,就像證書一樣。
有了保險箱,銀行家的鑰匙就像公鑰一樣,因為它留在銀行,公鑰與證書一起保留。您擁有“獲取證書”所需的私鑰,在保險箱示例中,除了公鑰外,還需要您的私鑰。

在您真正打開保險箱之前,您必須首先驗證您的身份(有點像證書請求);一旦識別出來,您就可以使用私鑰和公鑰打開保險箱。這有點像發出證書請求,然後從證書頒發機構獲取證書(只要您可以識別(信任)並且您擁有正確的密鑰)。


1
2018-05-12 01:49



<PiratesOfTheCarribean>所以我們正在追尋這把鑰匙!</ PiratesOfTheCarribean>(讀:你根本沒有任何意義......) - Timo


瀏覽器和服務器通信

次握手:

  • 客戶端發送隨機數以及支持的加密
  • 服務器使用支持的加密發送其證書。並且隨機數客戶端使用其私鑰加密並發回。 證書包含公鑰。證書頒發者或(CA),到期等。
  • 客戶端驗證服務器發送的證書。

所有PC都附帶一份他們信任的CA列表,如VeriSign或DigiCert。這些是ROOT CA.All根CA是自簽名的。要明白。這就像我相信服務器A和服務器A知道服務器B然後服務器A可以證明這是服務器B他說的是。並且服務器A證券的方式是通過向服務器B提供證書。在我們的案例服務器A中,該證書實際上是由CA的私鑰進行的,其公共簽名已經在我們的PC上,我可以通過它來驗證證書的真實性。服務器B.

  • 客戶端使用公鑰(在證書中收到)驗證之前發送的消息或隨機數。

  • 現在,客戶端通過發送OCSP請求並簽入CRL DB來檢查證書是否有效。

  • 現在,如果證書尚未被撤銷,則將建立會話密鑰對,利用該會話密鑰對建立加密隧道,現在所有流量都被加密。

所有CSR請求均由中間證書籤署,而不是根CA直接簽署,以保留ROOT CA的完整性,以便它們不會受到損害。


-2
2018-04-14 15:47



我知道它沒有直接回答這個問題,但請在downvoting時做評論。 - Kid101