SSL中，公鑰、私鑰、證書的後綴名都是些啥？

12-28

今天做這麼一個事，
centos伺服器，tomcat8+nginx1.6，現在要在上面運行cas4.0。
所以需要配ssl，
然後找教程，了解到，需要把tomcat和nginx的ssl都配置好。
到這裡就暈了，tomcat配ssl需要一個.keystore文件，nginx則需要配一個.crt和一個.key的文件。
按照教程使用keytool生成了.keystore文件，
然後我需要通過.keystore導出一個.crt文件，但是找了好多教程只是導出.cer文件。
找來找去發現.crt和.cer是一個東西。
後來又找到了一個.pem的東西，好像和.crt,.cer也是一個東西。
然後我就凌亂了。
希望有高手能指點一下，SSL的公鑰、私鑰、證書都有些啥後綴？
若能再指點一下tomcat8+nginx1.6上安裝cas4.0，那就更好了。

純粹個人理解，因為SSL本身確實比較複雜，歡迎糾正。
我把SSL系統比喻為工商局系統。
首先有SSL就有CA，certificate authority。證書局，用於製作、認證證書的第三方機構，我們假設營業執照非常難製作，就像身份證一樣，需要有制證公司來提供，並且提供技術幫助工商局驗證執照的真偽。
然後CA是可以有多個的，也就是可以有多個制證公司，但工商局就只有一個，它來說那個制證公司是可信的，那些是假的，需要打擊。在SSL的世界中，微軟、Google和Mozilla扮演了一部分這個角色。也就是說，IE、Chrome、Firefox中內置有一些CA，經過這些CA頒發，驗證過的證書都是可以信的，否則就會提示你不安全。
這也是為什麼前幾天Chrome決定屏蔽CNNIC的CA時，CNNIC那麼遺憾了。
也因為內置的CA是相對固定的，所以當你決定要新建網站時，就需要購買這些內置CA頒發的證書來讓用戶看到你的域名前面是綠色的，而不是紅色。而這個最大的賣證書的公司就是VeriSign如果你聽說過的話，當然它被賣給了Symantec，這傢伙不只出Ghost，還是個賣證書的公司。

要開店的老闆去申請營業執照的時候是需要交他的身份證的，然後辦出來的營業執照上也會有他的照片和名字。身份證相當於私鑰，營業執照就是證書，Ceritficate，.cer文件。

然後關於私鑰和公鑰如何解釋我沒想好，而它們在數據加密層面，數據的流向是這樣的。

消息--&>[公鑰]--&>加密後的信息--&>[私鑰]--&>消息

公鑰是可以隨便扔給誰的，他把消息加了密傳給我。對了，可以這樣理解，我有一個箱子，一把鎖和一把鑰匙，我把箱子和開著的鎖給別人，他寫了信放箱子里，鎖上，然後傳遞迴我手上的途中誰都是打不開箱子的，只有我可以用原來的鑰匙打開，這就是SSL，公鑰，私鑰傳遞加密消息的方式。這裡的密鑰就是key文件。

於是我們就有了.cer和.key文件。接下來說keystore

不同的語言、工具序列SSL相關文件的格式和擴展名是不一樣的。
其中Java系喜歡用keystore, truststore來幹活，你看它的名字，Store，倉庫，它裡面存放著key和信任的CA，key和CA可以有多個。
這裡的truststore就像你自己電腦的證書管理器一樣，如果你打開Chrome的設置，找到HTTP SSL，就可以看到裡面有很多CA，truststore就是干這個活兒的，它也裡面也是存一個或多個CA讓Tomcat或Java程序來調用。
而keystore就是用來存密鑰文件的，可以存放多個。

然後是PEM，它是由RFC1421至1424定義的一種數據格式。其實前面的.cert和.key文件都是PEM格式的，只不過在有些系統中（比如Windows）會根據擴展名不同而做不同的事。所以當你看到.pem文件時，它裡面的內容可能是certificate也可能是key，也可能兩個都有，要看具體情況。可以通過openssl查看。

RFC1421的第一節是這樣說的

1. Executive Summary


   This document defines message encryption and authentication

   procedures, in order to provide privacy-enhanced mail (PEM) services

   for electronic mail transfer in the Internet.  It is intended to

   become one member of a related set of four RFCs.  The procedures

   defined in the current document are intended to be compatible with a

   wide range of key management approaches, including both symmetric

   (secret-key) and asymmetric (public-key) approaches for encryption of

   data encrypting keys.  Use of symmetric cryptography for message text

   encryption and/or integrity check computation is anticipated. RFC1422 specifies supporting key management mechanisms based on the use

   of public-key certificates.  RFC 1423 specifies algorithms, modes,

   and associated identifiers relevant to the current RFC and to RFC1422.  RFC 1424 provides details of paper and electronic formats and

   procedures for the key management infrastructure being established in

   support of these services.
   本文檔定義了Internet中消息加密和身份認證的流程，它用於為電子郵件傳輸提供增強的私密郵件服務(PEM)。它是4個相關RFC組中的一個，當前文檔中定義的流程打算與各種密鑰管理方法兼容，包含對稱和不對稱數據加密協議。使用對稱方式來加密文本消息和完整性檢查是可以預期的。RFC1422描述了基於公鑰證書和密鑰管理機制，RFC1423描述了演算法，模式和與RFC1421/1422相關的身份認證的內容，RFC1424提供了詳盡的紙制/電子格式和流程，來描述如何構建支持這些協議的密鑰管理基礎設施。
   Privacy enhancement services (confidentiality, authentication,

   message integrity assurance, and non-repudiation of origin) are

   offered through the use of end-to-end cryptography between originator

   and recipient processes at or above the User Agent level.  No special

   processing requirements are imposed on the Message Transfer System at

   endpoints or at intermediate relay sites.  This approach allows

   privacy enhancement facilities to be incorporated selectively on a

   site-by-site or user-by-user basis without impact on other Internet

   entities.  Interoperability among heterogeneous components and mail

   transport facilities is supported.

The current specification"s scope is confined to PEM processing procedures for the RFC-822 textual mail environment, and defines the Content-Domain indicator value "RFC822" to signify this usage. Follow-on work in integration of PEM capabilities with other messaging environments (e.g., MIME) is anticipated and will be addressed in separate and/or successor documents, at which point additional Content-Domain indicator values will be defined.

至於CAS4.0這個東西，網上一堆的教程，中文的、英文的，先自己做吧，遇到問題時把你的操作過程，在什麼步驟遇到什麼問題，出現什麼錯誤，你怎麼理解都寫出來，成長比你成功部署一個CAS要大多了。

最後，看到一篇文章寫的不錯，在這裡翻譯一部分。
What is SSL and what are Certificates?

The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works.

A browser requests a secure page (usually https://).
The web server sends its public key with its certificate.
The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.
The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data.
The web server sends back the requested html document and http data encrypted with the symmetric key.
The browser decrypts the http data and html document using the symmetric key and displays the information.

安全套接層協議是由Netscape創建的，它用來保證在WEB伺服器和瀏覽器間的數據被安全傳輸。
協議使用一個第三方的證書局（CA）來驗證傳輸的一方或雙方的身份。下面是簡單的描述它如何工作：

瀏覽器請求一個安全的頁面(通過以https://開頭)
WEB伺服器返回它的公鑰和證書
瀏覽檢查證書是由可信的機構頒發的（通過是可信的根CA），證書仍然有效並且證書與被訪問的網站相關
瀏覽器使用公鑰來加密一個隨機的對稱密鑰，加上加密後的URL和其它加密後的http數據一起發回至伺服器。
WEB伺服器使用私鑰解密對稱密鑰，並用它來解密在瀏覽器上加密了的URL和http數據
WEB伺服器使用對稱密鑰加密請求的HTML文檔和http數據並發回至瀏覽器
瀏覽器使用對稱密鑰解密HTML文檔和http數據並展示給用戶

PKCS 全稱是 Public-Key Cryptography Standards ，是由 RSA 實驗室與其它安全系統開發商為促進公鑰密碼的發展而制訂的一系列標準，PKCS 目前共發布過 15 個標準。常用的有：

PKCS#7 Cryptographic Message Syntax Standard

PKCS#10 Certification Request Standard

PKCS#12 Personal Information Exchange Syntax Standard

X.509是常見通用的證書格式。所有的證書都符合為Public Key Infrastructure (PKI) 制定的 ITU-T X509 國際標準。

PKCS#7 常用的後綴是： .P7B .P7C .SPC

PKCS#12 常用的後綴有： .P12 .PFX

X.509 DER 編碼(ASCII)的後綴是： .DER .CER .CRT

X.509 PAM 編碼(Base64)的後綴是： .PEM .CER .CRT

.cer/.crt是用於存放證書，它是2進位形式存放的，不含私鑰。

.pem跟crt/cer的區別是它以Ascii來表示。

pfx/p12用於存放個人證書/私鑰，他通常包含保護密碼，2進位方式

p10是證書請求

p7r是CA對證書請求的回復，只用於導入

p7b以樹狀展示證書鏈(certificate chain)，同時也支持單個證書，不含私鑰。

7.6. 證書轉換

Linux 下的工具們通常使用 base64 編碼的文本格式，相關常用後綴如下：
* 證書：.crt, .pem
* 私鑰：.key
* 證書請求：.csr

.cer 好像是二進位的證書。當然你也可以把證書和 key 放到同一個文件裡邊。這時候擴展名通常叫 .pem。Java 的 keystore 什麼的都是二進位的，好像是自有格式。

其實在類 UNIX 系統上，關注文件名後綴的程序並不多的。而證書、密鑰都是有明顯的標識的，所以相關軟體（如 openssl）可以處理，而不管你用的什麼擴展名。當然亂用擴展名自己識別不便，桌面環境也不能將擴展名與默認操作、圖標關聯起來。

如果不知道一個文件是個啥，可以使用 file 命令識別試試。有經驗的也可以直接拿文本編輯器打開看看。

首先要說明一下幾個格式的基本含義：

ASN.1是一套完整的數據結構與數據存儲格式描述
BER/DER是ASN.1的二進位編碼方式
PEM是DER編碼再進行Base64編碼後的文本格式

上面三個都是「表示格式」

公鑰和私鑰一般都是用PEM方式保存，但是公鑰文件還不足以成為證書，還需要CA的簽名
CSR是證書籤名請求，CA用自己的私鑰文件簽名之後生成CRT文件就是完整的證書了
CER和CRT其實是一樣的，只是一般Linux下面叫CRT多，Windows下面叫CER多

證書(Certificate) - *.cer *.crt
私鑰(Private Key) - *.key
證書籤名請求(Certificate sign request) - *.csr

至於pem和der，是編碼方式，以上三類均可以使用這兩種編碼方式，因此*.pem和*.der(少見)不一定是以上三種(Cert,Key,CSR)中的某一種

pem - base64編碼
der - 二進位編碼