❤️【OpenSSL】证书关于 pem der cer crt csr pfx 的区别

刚开始接触证书的时候，对于这几个词语 pem der crt cer pfx尤为的疑惑。研究了一番，总结如下。

一.名词解释
这里先介绍一下X.690，它是ITU-T标准，规定了几种ASN.1编码格式：

Basic Encoding Rules (BER)
Canonical Encoding Rules (CER)
Distinguished Encoding Rules (DER)

关于X.690知道上面的关系就可以了，在此我不做更多介绍。有兴趣的读者可以自行google。

注意，上面编码格式CER是一种和DER很相似的编码格式，与后文提到的.cer后缀没有任何关系。大家最好忘记它。

这里我们先看看wiki上对于DER和PEM是怎么说的。

1.DER    （Distinguished Encoding Rules）
DER是BER的一个受限变体，用于为ASN.1中描述的数据结构生成明确的传输语法。与CER一样，DER编码也是有效的BER编码。DER除了删除了一个发送者选项外，其他的与BER完全相同。

DER是BER的子集，提供了一种准确编码ASN.1值的方法。DER适用于需要唯一编码情况，例如在加密中，确保需要进行数字签名的数据结构产生一个唯一的序列化表示。DER可以被认为是BER的规范形式。例如，在BER中，布尔值true可以编码为255个非零字节值中的任何一个，而在DER中，只有一种方法编码布尔值true。

DER被广泛的用户数字证书，例如X.509。

2.PEM    （Privacy-Enhanced Mail）
pem 是一种基于一组定义“隐私增强邮件”的1993 IETF标准的文件格式，用于存储和发送加密密钥，证书和其他数据。虽然原始标准从未被广泛采用，并已经被PGP和S / MIME取代，但它们定义的文本编码方式流行起来了。PEM格式最终由IETF在RFC 7468中正式确定。

许多加密标准使用ASN.1来定义它们的数据结构，使用区分编码规则（Distinguished Encoding Rules，DER）来序列化这些结构。由于DER 产生二进制输出，它在传输结果文件通过只支持ASCII的系统系统时，具有很大的挑战性，比如通过电子邮件系统时。PEM格式则使用Base64编码二进制数据的方式解决了这个问题。PEM还定义了其文件格式

-----BEGIN (label) -----
...
-----END (label) -----
这个 label  决定了被编码消息的类型，通常这些类型有如下一些：

"CERTIFICATE", "CERTIFICATE REQUEST", "PRIVATE KEY" and "X509 CRL".

PEM 格式的数据通常存储在以 ".pem",".cer",".crt"(证书)或者".key"(公钥或私钥)为后缀的文件中。这个PEM文件中的lable字段比文件后缀名更加准确地代表了数据类型，因为许多不同类型的数据都可以保存在".pem"结尾的文件中。

一个PEM文件可能包含了多个实例。比如，一个操作系统可能提供一个含有一系列信任的"CA证书"，或者web服务器可能配置了一个"证书链"，该证书链包含了一个客户端证书加一系列的中间证书。

例子

一个PEM编码的证书文件：

-----BEGIN CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0
ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw
CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy
dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu
dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X
uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud
DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG
SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA
l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo=
-----END CERTIFICATE-----

一个 PEM编码的证书签名请求文件：

-----BEGIN CERTIFICATE REQUEST-----
MIICXTCCAUUCAQAwGDEWMBQGA1UEAwwNaGkgd2lraXBlZGlhITCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAMTwzCYD+iLlDwTu5Y43aQH9q1LF3kgot8I4
9ZgbFhDmCE4YlLhZKO4hieK6z8z+IfZjfapn01rzuzvTHESj5bSSU6AcEsKSOgTQ
uB+KKn4mgngyBrJwWjr4IZ9XkGsCLAP2/wkyJC2ire6FuTSQ00YGhKf1B3WbIBbn
5i1rvZXnYxlheWlNSmxx54q4gTwcd/V4nS4BThYA/ypATjHS/gfQ650cOQzRK/Jh
WfAbfnETYUpD6MCgZAIbaBuYvYpQEGqQ4niTvtSd07RHKnewcPFqJhMV86qN4HQY
4ZBNzQcF/2aCGHYyRniKznSDNijT2kaAz/L7ORqh+90qH/BLnKsCAwEAAaAAMA0G
CSqGSIb3DQEBCwUAA4IBAQAqV5g9AZGXEbM97ouTGDJqFNP2QjO9ZK9J3BOUTrFO
tMUrVWj+ixhC6vXD3o5uVL/fg6OlmK+13gsBpzg2mq72TBrZsNOK4+O0XvltIvSx
0H5tf1NYwuHxFgHDqgs/fQBOKFTadebJZHbPBtMrqlnenKYJiVb5YSWBZ7JKRCK7
VSgwNxxAMnSCNI0xF3EjZ1bjQkM8xGhnwe+n/RAd5Q2pMLIrquMoGMTUYLOq1xSB
sGTp8iLWbbWPl6gC1hcSMpFsbdyjMCWs+a2R2F8QnahrRfvpgFEndvzA2EvqHIoR
BHE1ChD7l691PxZP1eKA1I4AzZno5sb6SWyd8+pqY0oG
-----END CERTIFICATE REQUEST-----

3.PKCS     (Public Key Cryptography Standards)
在密码学里，PKCS代表"Public Key Cryptography Standards"（公开密钥密码学标准）。这些是RSA Security LLC从上世纪90年代初开始设计并发布的一组公钥加密标准。该公司发布这些标准是为了推广使用他们拥有专利的加密技术，比如RSA算法、Schnorr签名算法和其他一些技术。虽然不是行业标准(因为公司保留了对它们的控制)，但近年来，一些标准已经开始进入相关标准组织的“标准跟踪”过程，如IETF和PKIX工作组。

PKCS Standards Summary

	Version	Name	Comments
PKCS #1	2.2	RSA Cryptography Standard[1]	See RFC 8017. Defines the mathematical properties and format of RSA public and private keys (ASN.1-encoded in clear-text), and the basic algorithms and encoding/padding schemes for performing RSA encryption, decryption, and producing and verifying signatures.
PKCS #2	-	Withdrawn	No longer active as of 2010. Covered RSA encryption of message digests; subsequently merged into PKCS #1.
PKCS #3	1.4	Diffie–Hellman Key Agreement Standard[2]	A cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel.
PKCS #4	-	Withdrawn	No longer active as of 2010. Covered RSA key syntax; subsequently merged into PKCS #1.
PKCS #5	2.1	Password-based Encryption Standard[3]	See RFC 8018 and PBKDF2.
PKCS #6	1.5	Extended-Certificate Syntax Standard[4]	Defines extensions to the old v1 X.509 certificate specification. Obsoleted by v3 of the same.
PKCS #7	1.5	Cryptographic Message Syntax Standard[5]	See RFC 2315. Used to sign and/or encrypt messages under a PKI. Used also for certificate dissemination (for instance as a response to a PKCS #10 message). Formed the basis for S/MIME, which is as of 2010 based on RFC 5652, an updated Cryptographic Message Syntax Standard (CMS). Often used for single sign-on.
PKCS #8	1.2	Private-Key Information Syntax Standard[6]	See RFC 5958. Used to carry private certificate keypairs (encrypted or unencrypted).
PKCS #9	2.0	Selected Attribute Types[7]	See RFC 2985. Defines selected attribute types for use in PKCS #6 extended certificates, PKCS #7 digitally signed messages, PKCS #8 private-key information, and PKCS #10 certificate-signing requests.
PKCS #10	1.7	Certification Request Standard[8]	See RFC 2986. Format of messages sent to a certification authority to request certification of a public key. See certificate signing request.
PKCS #11	3.0	Cryptographic Token Interface[9]	Also known as "Cryptoki". An API defining a generic interface to cryptographic tokens (see also hardware security module). Often used in single sign-on, public-key cryptography and disk encryption[10] systems. RSA Security has turned over further development of the PKCS #11 standard to the OASIS PKCS 11 Technical Committee.
PKCS #12	1.1	Personal Information Exchange Syntax Standard[11]	See RFC 7292. Defines a file format commonly used to store private keys with accompanying public key certificates, protected with a password-based symmetric key. PFX is a predecessor to PKCS #12. This container format can contain multiple embedded objects, such as multiple certificates. Usually protected/encrypted with a password. Usable as a format for the Java key store and to establish client authentication certificates in Mozilla Firefox. Usable by Apache Tomcat.
PKCS #13	–	Elliptic Curve Cryptography Standard	(Apparently abandoned, only reference is a proposal from 1998.)[12]
PKCS #14	–	Pseudo-random Number Generation	(Apparently abandoned, no documents exist.)
PKCS #15	1.1	Cryptographic Token Information Format Standard[13]	Defines a standard allowing users of cryptographic tokens to identify themselves to applications, independent of the application's Cryptoki implementation (PKCS #11) or other API. RSA has relinquished IC-card-related parts of this standard to ISO/IEC 7816-15.[14]

我们常见的有PKCS#7，PKCS#10和PKCS#12,其他的格式忽略吧。

4.CSR    (certificate signing request )
在公钥基础设施(PKI)系统中，证书签名请求(certificate signing request，也称为CSR或certificate request)是申请人向证书颁发机构发送的一条消息，用于申请数字身份证书。它通常包含需要被颁发证书的公钥、标识信息(例如域名)和完整性保护(例如数字签名)。CSR最常见的格式是PKCS#10规范，另一种格式是由一些web浏览器生成的SPKAC(Signed Public Key and Challenge，签名公钥和挑战，哎呀，这个是我直译的，不要打我)格式。

认证请求由三个主要部分组成:认证请求信息、签名算法标识符和认证请求信息上的数字签名。第一部分包含重要信息，包括公钥。请求者的签名防止实体请求他人公钥的伪造证书。因此，生成CSR需要私钥，但私钥不是CSR的一部分。

第一部分,asn.1类型CertificationRequestInfo,包括版本号(对于所有已知版本规范1.0,1.5和1.7，它为0),主题名称、公钥(算法标识符+位串)和一组属性证书的主题提供额外的信息。这些属性可以包含所需的证书扩展名、限制撤销的质询密码，以及关于证书主题的任何附加信息(可能包括本地类型或未来类型)。

PKCS＃10标准定义了用于编码CSR的二进制格式，以便与X.509一起使用。 它在ASN.1中进行了阐述。

openssl asn1parse -i -in your_request_file

CSR可以表示为Base64编码的PKCS#10。这里给了一个示例文件

-----BEGIN CERTIFICATE REQUEST-----
MIICzDCCAbQCAQAwgYYxCzAJBgNVBAYTAkVOMQ0wCwYDVQQIDARub25lMQ0wCwYD
VQQHDARub25lMRIwEAYDVQQKDAlXaWtpcGVkaWExDTALBgNVBAsMBG5vbmUxGDAW
BgNVBAMMDyoud2lraXBlZGlhLm9yZzEcMBoGCSqGSIb3DQEJARYNbm9uZUBub25l
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMP/U8RlcCD6E8AL
PT8LLUR9ygyygPCaSmIEC8zXGJung3ykElXFRz/Jc/bu0hxCxi2YDz5IjxBBOpB/
kieG83HsSmZZtR+drZIQ6vOsr/ucvpnB9z4XzKuabNGZ5ZiTSQ9L7Mx8FzvUTq5y
/ArIuM+FBeuno/IV8zvwAe/VRa8i0QjFXT9vBBp35aeatdnJ2ds50yKCsHHcjvtr
9/8zPVqqmhl2XFS3Qdqlsprzbgksom67OobJGjaV+fNHNQ0o/rzP//Pl3i7vvaEG
7Ff8tQhEwR9nJUR1T6Z7ln7S6cOr23YozgWVkEJ/dSr6LAopb+cZ88FzW5NszU6i
57HhA7ECAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4IBAQBn8OCVOIx+n0AS6WbEmYDR
SspR9xOCoOwYfamB+2Bpmt82R01zJ/kaqzUtZUjaGvQvAaz5lUwoMdaO0X7I5Xfl
sllMFDaYoGD4Rru4s8gz2qG/QHWA8uPXzJVAj6X0olbIdLTEqTKsnBj4Zr1AJCNy
/YcG4ouLJr140o26MhwBpoCRpPjAgdYMH60BYfnc4/DILxMVqR9xqK1s98d6Ob/+
3wHFK+S7BRWrJQXcM8veAexXuk9lHQ+FgGfD0eSYGz0kyP26Qa2pLTwumjt+nBPl
rfJxaLHwTQ/1988G0H35ED0f9Md5fzoKi5evU1wG5WRxdEUPyt3QUXxdQ69i0C+7
-----END CERTIFICATE REQUEST-----
上面的证书签名请求ASN.1结构(openssl解析)如下所示，其中第一个数字是字节偏移量，d=深度，hl=当前类型的头文件长度，l=内容长度:

    0:d=0  hl=4 l= 716 cons: SEQUENCE          
    4:d=1  hl=4 l= 436 cons:  SEQUENCE          
    8:d=2  hl=2 l=   1 prim:   INTEGER           :00
   11:d=2  hl=3 l= 134 cons:   SEQUENCE          
   14:d=3  hl=2 l=  11 cons:    SET               
   16:d=4  hl=2 l=   9 cons:     SEQUENCE          
   18:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
   23:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :EN
   27:d=3  hl=2 l=  13 cons:    SET               
   29:d=4  hl=2 l=  11 cons:     SEQUENCE          
   31:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
   36:d=5  hl=2 l=   4 prim:      UTF8STRING        :none
   42:d=3  hl=2 l=  13 cons:    SET               
   44:d=4  hl=2 l=  11 cons:     SEQUENCE          
   46:d=5  hl=2 l=   3 prim:      OBJECT            :localityName
   51:d=5  hl=2 l=   4 prim:      UTF8STRING        :none
   57:d=3  hl=2 l=  18 cons:    SET               
   59:d=4  hl=2 l=  16 cons:     SEQUENCE          
   61:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
   66:d=5  hl=2 l=   9 prim:      UTF8STRING        :Wikipedia
   77:d=3  hl=2 l=  13 cons:    SET               
   79:d=4  hl=2 l=  11 cons:     SEQUENCE          
   81:d=5  hl=2 l=   3 prim:      OBJECT            :organizationalUnitName
   86:d=5  hl=2 l=   4 prim:      UTF8STRING        :none
   92:d=3  hl=2 l=  24 cons:    SET               
   94:d=4  hl=2 l=  22 cons:     SEQUENCE          
   96:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
  101:d=5  hl=2 l=  15 prim:      UTF8STRING        :*.wikipedia.org
  118:d=3  hl=2 l=  28 cons:    SET               
  120:d=4  hl=2 l=  26 cons:     SEQUENCE          
  122:d=5  hl=2 l=   9 prim:      OBJECT            :emailAddress
  133:d=5  hl=2 l=  13 prim:      IA5STRING         :none@none.com
  148:d=2  hl=4 l= 290 cons:   SEQUENCE          
  152:d=3  hl=2 l=  13 cons:    SEQUENCE          
  154:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
  165:d=4  hl=2 l=   0 prim:     NULL              
  167:d=3  hl=4 l= 271 prim:    BIT STRING        
  442:d=2  hl=2 l=   0 cons:   cont [ 0 ]        
  444:d=1  hl=2 l=  13 cons:  SEQUENCE          
  446:d=2  hl=2 l=   9 prim:   OBJECT            :md5WithRSAEncryption
  457:d=2  hl=2 l=   0 prim:   NULL              
  459:d=1  hl=4 l= 257 prim:  BIT STRING   
这是通过在命令"openssl asn1parse -inform PEM -i -in your_request_file "中提供base64编码生成的，其中PEM代表Privacy-enhanced mail，并描述了base64中ASN.1 DER编码。

有CSR必定有KEY，是成对的，CSR最终变成为证书crt，和私钥key配对使用。

证书下发后，CSR就没有用了，只是在交时候需要。 

4. X.509
Public-Key Infrastructure (X.509) (pkix) 

在密码学中，X.509是定义公钥证书格式的标准。X.509证书用于许多Internet协议，包括TLS/SSL，它是HTTPS(用于浏览web的安全协议)的基础。它们也用于离线应用程序，比如电子签名。一个X.509证书包含一个公钥和一个标识(主机名、组织或个人)，由证书颁发机构签名或自签名。当证书由受信任的证书颁发机构签名时，或者通过其他方法进行验证时，持有该证书的人可以依赖于它包含的公钥来与另一方建立安全通信，或者验证由相应私钥数字签名的文档。

X.509还定义了证书撤销列表，这是一种分发被签名机构认为无效的证书信息的方法，以及认证路径验证算法，该算法允许证书由中间CA证书签名，而中间CA证书又由其他证书签名，最终到达信任锚。

X.509由国际电信联盟标准化部门(ITU-T)定义，并基于ITU-T的另一个标准ASN.1。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

二.SSL Certificate (编码)格式
SSL Certificate实际上就是X.509 Certificate。X.509是一个定义了certificate结构的标准。它在SSL certificate中定义了一个数据域。X.509使用名为 Abstract Syntax Notation One (ASN.1)的通用语言来描述certificate的数据结构。

X.509 certificate 有几种不同的格式，例如 PEM，DER，PKCS#7 和 PKCS#12。 PEM和PKCS#7格式使用Base64 ASCII编码，而DER和PKCS#12使用二进制编码。certificate文件基于不同的编码格式有不同的文件扩展名。

如下图就展示了X.509证书的编码方式和文件扩展名。

PEM 格式
大多数 CA (Certificate Authority) 提供了Base64 ASCII编码的PEM格式的certificate文件。这些证书文件的后缀可以是 .pem, .crt, .cer, .key。 以.pem结尾的文件可以将服务端证书（server certificate），中间证书（intermediate certificate）和私钥（private key）包含在一个文件中。服务端证书和中间证书也可以分别存放在.crt 和 .cer两个文件中。私钥可以单独在一个 .key文件中。

PEM文件使用ASCII编码，所以你可以用文本编辑器打开它，例如notepad，微软的word等等。每一个PEM文件中的证书都在"---- BEGIN CERTIFICATE---- " 和 "----END CERTIFICATE----"语句之间。私钥包括在"---- BEGIN RSA PRIVATE KEY-----" 和 "-----END RSA PRIVATE KEY-----"语句之间。而CSR则包含在"-----BEGIN CERTIFICATE REQUEST----- " 和 "-----END CERTIFICATE REQUEST-----"语句之间。

PKCS#7 格式
PKCS#7格式是一种加密消息语法标准。PKCS#7证书使用Base64 ASCII编码和文件扩展名 .p7b 或 .p7c 。只有证书可以存储在这种格式的文件中，私钥则不可以。P7B证书包含在"-----BEGIN PKCS7-----"  和 "-----END PKCS7-----" 语句之间。

DER 格式
DER格式的证书是二进制形式，存储在以 .der 和 .cer 为扩展名的文件中。这些证书大部分使用在基于java的web服务器上。

PKCS#12 格式
PKCS#12格式的证书也是二进制形式，存储在以 .pfx 或 .p12为扩展名的文件中。

PKCS#12文件可以存储服务端证书，中间证书和私钥在一个 .pfx文件中，并且使用密码保护。 这类证书主要使用在Windows平台。

总结
DER 实际上就是密钥的最原始的二进制格式；而 PEM 是对 DER 的 Base64 的编码，PEM 解码后得到的就是 DER 编码格式。

只要是文本格式的文件，用文本编辑器打开后查看关键语句即可。

参考：

https://www.shangyang.me/2017/05/24/encrypt-rsa-keyformat/

https://blog.csdn.net/hqy1719239337/article/details/88896074

https://blog.csdn.net/xiangguiwang/article/details/76400805

https://en.wikipedia.org/wiki/X.690#DER_encoding

https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail

https://en.wikipedia.org/wiki/PKCS

https://en.wikipedia.org/wiki/Certificate_signing_request

https://en.wikipedia.org/wiki/X.509

https://www.tutorialsteacher.com/https/ssl-certificate-format
————————————————
版权声明：本文为CSDN博主「庚庚911」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/yetugeng/article/details/100629159