那些证书相关的玩意儿(SSL,X.509,PEM,DER,CRT,CER,KEY,CSR,P12等)[zz]

http://liuzhigong.blog.163.com/blog/static/178272375201492711829687/

Ubuntu使用OpenSSL生成数字证书详解

https://blog.csdn.net/kswkly/article/details/83617944

加密方式
简单来说分为两种，对称加密和非对称加密。

对称加密：
加密和解密用的是同一个秘钥，在对称加密算法中常用的算法有：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA等。这类加密算法的优点就是计算量小、加密速度快、加密效率高；但是缺点也很明显，在传输数据前，双方必须商定并保存好秘钥，任何一方的秘钥被泄露，加密信息就不再安全了。另外，每次使用对称加密算法时，都需要使用其他人不知道的唯一秘钥，这会使得收、发双方所拥有的钥匙数量巨大，密钥管理成为双方的负担。

非对称加密：
非对称加密需要两个秘钥来进行加密和解密，这两个秘钥非别是公有秘钥（公钥）和私有秘钥（私钥），公钥与私钥是一对，如果用公钥对数据进行加密，那么就必须用对应的私钥才能解密；同理，如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。在非对称加密中使用的主要算法有：RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）等。

工作流程（如下图）：
1、首先乙生成一对公钥和私钥，自己保存好私钥，并将公钥向其他所有人公开
2、然后甲使用乙的公钥对原始数据进行加密，并将生成的密文发送给乙
3、乙接收到消息后用自己的私钥对密文进行解密，得到原始数据
即使密文在传输过程中被截获了也没关系，因为别人根本不知道乙的私钥，所以无法解密。同理，如果乙要给甲回信，首先乙要得到甲的公钥，然后用甲的公钥对消息进行加密，发送给甲，甲用私钥进行解密。

上面的传输方式看似无懈可击，但是请设想这样的一个场景：由于公钥是公开的，所以除了甲以外其他人也知道乙的公钥，那么这时候我们就能用乙的公钥对消息进行加密，然后冒充甲给乙发消息，导致乙无法区分消息到底是不是甲发送的。
为了解决这个问题可以这样做：首先甲用自己的私钥对消息进行加密，生成另一个密文，然后将密文发送给乙，乙收到消息后，如果能用甲的公钥对密文进行解密，就说明这个这个消息确实是甲发送的。

数字签名
虽然上面的方法解决了身份认证的问题，但是由于所有人都有甲的公钥，所以只要消息发送中途被截获就一定能被解密；而且对文件加密可能是个耗时过程，比如文件足够大，那么用私钥加密整个文件以及拿到文件后解密的开销无疑是巨大的。为了解决这两个问题数字签名就被提了出来，有了数字签名就可以用下面的方式发送消息了：

甲先用hash函数对消息进行运算，得到的hash值成为“摘要”，我们就叫它h1吧
然后甲用自己私钥对摘要进行加密，生成的密文就叫做“数字签名”，我们就叫它signature吧
之后用乙的公钥对消息进行加密，生成的密文就叫secret吧
最后把密文secret和signature一起发送给乙
乙收到后首先用甲的公钥对signature进行解密，如果能够解密说明消息确实是甲发送的，失败说明不是甲发的
然后乙用自己的私钥对密文secret进行解密，并使用相同的hash函数对解密后的结果进行运算，得到一个hash值，我们就叫它h2吧，如果h2=h1，说明消息内容没有被篡改，如果不等于说明消息内容中途被篡改了
流程图如下：

有了数字签名，我们就可以验证消息来源和消息的完整性了，但是这个过程真的就完美了吗？让我们设想以下场景：如果第三者丙偷偷在乙的电脑用自己公钥替换了甲的公钥，然后用自己的私钥给乙发送消息，这时乙收到的消息其实是被丙冒充的，但是乙却无法察觉，仍认为是甲发送的消息。
为了解决上面这个问题数字证书就出现了。

数字证书
在说数字证书之前，我们首先要搞明白导致发生上面那种情况的根源在哪里？本质上来说就是乙无法区分电脑中公钥到底是谁的，以至于乙会把丙错当成甲，所以我们就要想办法给公钥做身份认证（数字证书），以便能让别人搞清楚公钥到底是谁的。有了数字证书后就可以用以下方式发送消息了：

首先甲去找"证书中心"（certificate authority，简称CA），为自己公钥做认证（就好比去公安局办身份证一样）。CA用自己的私钥对甲的公钥和一些其他信息进行加密，生成的东西就叫"数字证书"（Digital Certificate）

甲给乙发送的消息如下：

乙收到消息后用CA的公钥解密甲的数字证书，拿到甲的公钥，然后验证甲的数字签名，后面流程和上面的一样。

如此一来问题就解决了，但是新的问题又出现了：每个人都有一个CA给颁发的数字证书，如果有一百万个人给乙发消息，那么乙就要保存一百万份不同的CA公钥来验证这些人的身份。显然这是不可能接受的，所以就有了“根证书”，里面存储CA公钥来验证所有CA分部颁发的数字证书，乙直接保存一份“根证书”就可以验证所有人的身份了。最后一点就是“根证书”的可靠性有谁来保证呢？确切的来说无法保证，就好像你自己无法证明你是你一样，“根证书”也是如此，只不过CA机构是获得社会绝对认可和有绝对权威的第三方机构，就像政府法院一样，这一点保证了根证书的绝对可靠。如果根证书都有问题那么整个加密体系毫无意义。
————————————————
版权声明：本文为CSDN博主「想养一只雪狐」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/kswkly/article/details/83617944

openssl dgst –sign privatekey.pem –sha1 –keyform PEM –c c:\server.pem
将文件用sha1摘要，并用privatekey.pem中的私钥签名。

openssl x509 -in keytool_crt.pem -inform pem -noout -text (-inform means input format,like der)

那些证书相关的玩意儿(SSL,X.509,PEM,DER,CRT,CER,KEY,CSR,P12等)[zz]
转载 <javascript:;> 2015-06-09 20:21:04
from:http://www.cnblogs.com/guogangj/p/4118605.html
之前没接触过证书加密的话,对证书相关的这些概念真是感觉挺棘手的,因为一下子来了一大堆新名词,看起来像是另一个领域的东西,而不是我们所熟悉的编程领 域的那些东西,起码我个人感觉如此,且很长时间都没怎么搞懂.写这篇文章的目的就是为了理理清这些概念,搞清楚它们的含义及关联,还有一些基本操作.
SSL
SSL - Secure Sockets Layer,现在应该叫"TLS",但由于习惯问题,我们还是叫"SSL"比较多.http协议默认情况下是不加密内容的,这样就很可能在内容传播的时候 被别人监听到,对于安全性要求较高的场合,必须要加密,https就是带加密的http协议,而https的加密是基于SSL的,它执行的是一个比较下层 的加密,也就是说,在加密前,你的服务器程序在干嘛,加密后也一样在干嘛,不用动,这个加密对用户和开发者来说都是透明的.More:[维基百科
]

openssl是一个开源程序的套件、这个套件有三个部分组成：一是libcryto，这是一个具有通用功能的加密库，里面实现了众多的加密库；二是libssl，这个是实现ssl机制的，它是用于实现TLS/SSL的功能；三是openssl，是个多功能命令行工具，它可以实现加密解密，甚至还可以当CA来用，可以让你创建证书、吊销证书。

默认情况ubuntu和CentOS上都已安装好openssl。CentOS 6.x 上有关ssl证书的目录结构：

/etc/pki/CA/
newcerts 存放CA签署（颁发）过的数字证书（证书备份目录）
private 用于存放CA的私钥
crl 吊销的证书

/etc/pki/tls/
cert.pem 软链接到certs/ca-bundle.crt
certs/ 该服务器上的证书存放目录，可以房子自己的证书和内置证书
ca-bundle.crt 内置信任的证书
private 证书密钥存放目录
openssl.cnf openssl的CA主配置文件

OpenSSL - 简单地说,OpenSSL是SSL的一个实现,SSL只是一种规范.理论上来说,SSL这种规范是安全的,目前的技术水平很难破解,但SSL的实现就可能有些漏洞,如著名的"心脏出血".OpenSSL还提供了一大堆强大的工具软件,强大到90%我们都用不到.
证书标准
X.509 - 这是一种证书标准,主要定义了证书中应该包含哪些内容.其详情可以参考RFC5280,SSL使用的就是这种证书标准.
编码格式
同样的X.509证书,可能有不同的编码格式,目前有以下两种编码格式.
PEM - Privacy Enhanced Mail,打开看文本格式,以"-----BEGIN..."开头, "-----END..."结尾,内容是BASE64编码.查看PEM格式证书的信息:openssl x509 -in certificate.pem -text -nooutApache和*NIX服务器偏向于使用这种编码格式.
DER - Distinguished Encoding Rules,打开看是二进制格式,不可读.查看DER格式证书的信息:openssl x509 -in certificate.der -inform der -text -nooutJava和Windows服务器偏向于使用这种编码格式.
相关的文件扩展名
这是比较误导人的地方,虽然我们已经知道有PEM和DER这两种编码格式,但文件扩展名并不一定就叫"PEM"或者"DER",常见的扩展名除了PEM和DER还有以下这些,它们除了编码格式可能不同之外,内容也有差别,但大多数都能相互转换编码格式.
CRT - CRT应该是certificate的三个字母,其实还是证书的意思,常见于*NIX系统,有可能是PEM编码,也有可能是DER编码,大多数应该是PEM编码,相信你已经知道怎么辨别.
CER - 还是certificate,还是证书,常见于Windows系统,同样的,可能是PEM编码,也可能是DER编码,大多数应该是DER编码.
KEY - 通常用来存放一个公钥或者私钥,并非X.509证书,编码同样的,可能是PEM,也可能是DER.查看KEY的办法:openssl rsa -in mykey.key -text -noout如果是DER格式的话,同理应该这样了:openssl rsa -in mykey.key -text -noout -inform der
CSR - Certificate Signing Request,即证书签名请求,这个并不是证书,而是向权威证书颁发机构获得签名证书的申请,其核心内容是一个公钥(当然还附带了一些别的信息),在生成这个申请的时候,同时也会生成一个私钥,私钥要自己保管好.做过iOS APP的朋友都应该知道是怎么向苹果申请开发者证书的吧.查看的办法:openssl req -noout -text -in my.csr (如果是DER格式的话照旧加上-inform der,这里不写了)
PFX/P12 - predecessor of PKCS#12,对*nix服务器来说,一般CRT和KEY是分开存放在不同文件中的,但Windows的IIS则将它们存在一个PFX文件中,(因此这 个文件包含了证书及私钥)这样会不会不安全？应该不会,PFX通常会有一个"提取密码",你想把里面的东西读取出来的话,它就要求你提供提取密码,PFX 使用的时DER编码,如何把PFX转换为PEM编码？openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes这个时候会提示你输入提取代码. for-iis.pem就是可读的文本.生成pfx的命令类似这样:openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt其中CACert.crt是CA(权威证书颁发机构)的根证书,有的话也通过-certfile参数一起带进去.这么看来,PFX其实是个证书密钥库.
JKS - 即Java Key Storage,这是Java的专利,跟OpenSSL关系不大,利用Java的一个叫"keytool"的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS,不过在此就不多表了.
证书编码的转换
PEM转为DER openssl x509 -in cert.crt -outform der -out cert.der
DER转为PEM openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
(提示:要转换KEY文件也类似,只不过把x509换成rsa,要转CSR的话,把x509换成req...)
获得证书
向权威证书颁发机构申请证书
用这命令生成一个csr: openssl req -newkey rsa:2048 -new -nodes -keyout my.key -out my.csr把csr交给权威证书颁发机构,权威证书颁发机构对此进行签名,完成.保留好csr,当权威证书颁发机构颁发的证书过期的时候,你还可以用同样的csr来申请新的证书,key保持不变.
或者生成自签名的证书openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem在生成证书的过程中会要你填一堆的东西,其实真正要填的只有Common Name,通常填写你服务器的域名,如"yourcompany.com",或者你服务器的IP地址,其它都可以留空的.生产环境中还是不要使用自签的证 书,否则浏览器会不认,或者如果你是企业应用的话能够强制让用户的浏览器接受你的自签证书也行.向权威机构要证书通常是要钱的,但现在也有免费的,仅仅需 要一个简单的域名验证即可.有兴趣的话查查"沃通数字证书".