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
nginx ssl证书配置support of these services.
本⽂档定义了Internet中消息加密和⾝份认证的流程，它⽤于为电⼦邮件传输提供增强的私密邮件服务(PEM)。它是4个相关RFC组中的⼀个，当前⽂档中定义的流程
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要⼤多了。
最后，看到⼀篇⽂章写的不错，在这⾥翻译⼀部分。
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 ).
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. 浏览器请求⼀个安全的页⾯(通过以开头)
2. WEB服务器返回它的公钥和证书
3. 浏览检查证书是由可信的机构颁发的（通过是可信的根CA），证书仍然有效并且证书与被访问的⽹站相关
4. 浏览器使⽤公钥来加密⼀个随机的对称密钥，加上加密后的URL和其它加密后的http数据⼀起发回⾄服务器。
5. WEB服务器使⽤私钥解密对称密钥，并⽤它来解密在浏览器上加密了的URL和http数据
6. WEB服务器使⽤对称密钥加密请求的HTML⽂档和http数据并发回⾄浏览器
7. 浏览器使⽤对称密钥解密HTML⽂档和http数据并展⽰给⽤户

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。