SSL中，公钥、私钥、证书的后缀名都是些啥？

今天做这么一个事，
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，那就更好了。

关注者

229

被浏览

52,145

7 个回答

刘长元

尊贵的Starbucks会员

纯粹个人理解，因为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.

1. A browser requests a secure page (usually https://).

2. The web server sends its public key with its certificate.

3. 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.

4. 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.

5. The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data.

6. The web server sends back the requested html document and http data encrypted with the symmetric key.

7. The browser decrypts the http data and html document using the symmetric key and displays the information.

安全套接层协议是由Netscape创建的，它用来保证在WEB服务器和浏览器间的数据被安全传输。
协议使用一个第三方的证书局（CA）来验证传输的一方或双方的身份。下面是简单的描述它如何工作：

1. 浏览器请求一个安全的页面(通过以https://开头)
2. WEB服务器返回它的公钥和证书
3. 浏览检查证书是由可信的机构颁发的（通过是可信的根CA），证书仍然有效并且证书与被访问的网站相关
4. 浏览器使用公钥来加密一个随机的对称密钥，加上加密后的URL和其它加密后的http数据一起发回至服务器。
5. WEB服务器使用私钥解密对称密钥，并用它来解密在浏览器上加密了的URL和http数据
6. WEB服务器使用对称密钥加密请求的HTML文档和http数据并发回至浏览器
7. 浏览器使用对称密钥解密HTML文档和http数据并展示给用户