【ssl认证、证书】SSL 证书基本概念、证书格式、openssl和keytool的区别-Toy模板网

这篇具有很好参考价值的文章主要介绍了【ssl认证、证书】SSL 证书基本概念、证书格式、openssl和keytool的区别。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

相关文章：
//-----------Java SSL begin----------------------
【ssl认证、证书】SSL双向认证和SSL单向认证的区别(示意图)
【ssl认证、证书】java中的ssl语法API说明(SSLContext)、与keytool 工具的联系
【ssl认证、证书】SSL双向认证java实战、keytool创建证书
【ssl认证、证书】Wireshark抓包分析
【ssl认证、证书】查看keystore文件内容
//------------Java SSL end--------------------------

//-----------下面的是CA证书和openssl相关的知识--------------
【ssl认证、证书】TLS/SSL双向认证概念、openssl genrsa示例
【ssl认证、证书】openssl genrsa 命令详解
【ssl认证、证书】SSL 证书基本概念、证书格式、openssl和keytool的区别

1. keytool VS openssl

keytool 和 openssl 是俩个证书管理工具。

首先要确认一个前提，keytool生成的证书和Java语言的ssl通信是强相关的，OpenSSL生成的证书，需要先按照相应的格式转换为Java能识别的格式之后，才能使用。

keytool 是 java JDK 自带的证书管理工具，使用 keytool 可以生成密钥，创建证书。只要装了 jdk，并正确设置了环境变量，就可以之间通过命令行执行 keytool 命令来管理证书。

keytool只能生成自签名的数字证书。所谓的自签名证书就是没有经CA签发机构签发，而是自己签发的，由于无法利用CA根证书进行判断证书的合法性，只能通过白名单形式进行证书验证，对于每一个要连接的服务器，都要提前拷贝一个证书的副本，放入trust key store(简称TKS)，TKS内的证书就是已授信证书的白名单，即Java SSL通信与标准的SSL相比，JAVA定制化了证书的验证，TKS的设计替代了CA_ROOT检测证书。因此Keytool存在这样的缺点：需要提前拷贝，并导入到TKS作为白名单。
openssl 则是一个开源的安全套接字层密码库，功能比 keytool 更加丰富。

OpenSSL是标准的SSL实现，利用证书链进行双向认证或单向认证。证书链是指对证书的签名有一个预先部署的，众所周知的签名方签名完成，这样每次需要验证证书时只要用这个公用的签名方的公钥(根证书本质就是这个公钥)进行验证就可以了。比如我们使用的浏览器就保存了几个常用的CA_ROOT(即常说的根证书)。每次连接到网站时只要判断这个网站的证书是经过这些CA_ROOT签名过的，就认可通过验证了。

并且证书是通过网络发送到对端的，不需要提前拷贝至对端，CA_ROOT是预置的，都是知名CA机构的，非常可靠。

共用的CA_ROOT的服务不是免费的，而且价格不菲，如果是企业内部的通信，可以使用自签发的CA_ROOT，进而生成自签名的证书，同时把CA_ROOT提前发至对端，那么后续流程是和标准的SSL流程就一样了

2. X.509 VS PKCS

在计算机界，有各种密码学标准，它们表示了如何在计算机中计算、存储、传输（等）各种算法，这些标准由 IEFT、ITU-T、ISO 等标准组织机构编写。

在探讨这些东西之前，这里先提醒一件事情，下文中有些地方提到的私钥，实际上并不是纯粹的私钥（例如 RSA 中的
），而是包含了整个密钥对全部必要信息的密钥（自然也包含公钥），这就是为什么在私钥中可以提取出公钥。

如 RSA 公钥包括在 RSAPrivateKey 中，ECC 公钥包括在 ECPrivateKey 中。

PKCS 协议组和 X.509 协议均采用 ASN.1 来定义密钥或证书的数据结构。都是 ASN.1 协议的具体实现。

关系总览：
【ssl认证、证书】SSL 证书基本概念、证书格式、openssl和keytool的区别

2.1 PKCS

PKCS 全称 Public-Key Cryptography Standards ，即公钥标准，PKCS 已经发布了15个标准。

PKCS#1 和 X.509比较接近
…
PKCS#12 包含了公钥和私钥的二进制格式的证书形式，以 .pfx 作为证书文件后缀。其他类型的一般公钥和私钥不会放在一起，一般都是非 .pfx 格式。

虽然叫公钥标准，但是也含有私钥的标准

标准	版本	名称	简介
PKCS #1	2.2	RSA 加密规范（RSA Cryptography Standard）	提供了基于 RSA 算法的公钥加密实现的建议，包括加密原语、加密方案、带附录的签名方案，以及用于表示密钥和识别方案的 ASN.1 语法。参见 RFC 8017。
PKCS #2	-	弃用	原本是用以规范 RSA 加密摘要的转换方式，现已被纳入 PKCS #1 之中。
PKCS #3	1.4	Diffie-Hellman 协议标准（Diffie-Hellman key agreement Standard）	规范以 Diffie-Hellman 协议为基础的密钥协议标准。其功能可以让两方通过过协议，拟定一把会议密钥（Session key）。
PKCS #4	-	弃用	原本用以规范转换 RSA 密钥的流程。已被纳入 PKCS #1 之中。
PKCS #5	2.1	基于密码的加密规范（Password-based Encryption Standard）	参见 RFC 8018。
PKCS #6	1.5	证书扩展语法标准（Extended-Certificate Syntax Standard）	将原本 X.509 的证书格式标准加以扩充。
PKCS #7	1.5	密码讯息语法标准（Cryptographic Message Syntax Standard）	参见 RFC 2315。规范了以公开密钥基础设施（PKI）所产生之签章/密文的格式。其目的一样是为了拓展数位证书的应用。其中，包含了 S/MIME 与 CMS（英语：Cryptographic Message Syntax）。
PKCS #8	1.2	私钥信息语法规范（Private-Key Information Syntax Standard）	存储私钥信息的标准语法。参见 RFC 5208。
PKCS #9	2.0	选择属性格式（Selected Attribute Types）	定义 PKCS #6、7、8、10 的选择属性格式。
PKCS #10	1.7	证书申请标准（Certification Request Standard）	参见 RFC 2986。规范了向证书中心申请证书的 CSR（certificate signing request）的格式。
PKCS #11	2.20	密码装置标准介面（Cryptographic Token Interface (Cryptoki)）	定义了密码装置的应用程式介面（API）之规格。
PKCS #12	1.0	个人讯息交换标准（Personal Information Exchange Syntax Standard）	定义了包含私钥与公钥证书（public key certificate）的文件格式。私钥采密码（password）保护。常见的 PFX格式就履行了 PKCS #12。
PKCS #13	–	椭圆曲线密码学标准（Elliptic curve cryptography Standard）	制定中。规范以椭圆曲线密码学为基础所发展之密码技术应用。椭圆曲线密码学是新的密码学技术，其强度与效率皆比现行以指数运算为基础之密码学演算法来的优秀。然而，该演算法的应用尚不普及。
PKCS #14	–	伪随机数生成器（英语：Pseudorandom number generator）标准	制定中。规范伪随机数生成器的使用与设计。
PKCS #15	1.1	密码装置讯息格式标准（Cryptographic Token Information Format Standard）	定义了密码设备内部数据的组织结构。

2.2 X.509

X.509 是密码学里公钥证书的格式标准。X.509 证书已应用在包括 TLS/SSL 在内的众多网络协议里，同时它也用在很多非在线应用场景里，比如电子签名服务。X.509 证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构 CA 的签名，也可以是自签名）

虽然叫公钥标准，但是也含有私钥的标准

2.2.1 证书编码格式

DER和perm是协议，前者是二进制，后者是文本；

2.2.1.1 DER 证书编码格式二进制

X.690 是一种 ITU-T 标准，指定了几种 ASN.1 编码格式：

基本编码规则（BER，Basic Encoding Rules） 抽象的编码格式，一般不会实际使用作为后缀
规范编码规则（CER，Canonical Encoding Rules）二进制，常作为实际后缀名
可分辨编码规则（DER，Distinguished Encoding Rules）二进制，是BER的子集，常作为实际后缀名

BER 是 ASN.1 标准制定的用于将数据编码为二进制格式的原始规则。这些规则在 ASN.1 用语中统称为传输语法，指定用于编码数据的确切八位字节（8 位字节）。

DER 是 BER 的子集，提供了一种对 ASN.1 值进行编码的方式。DER 适用于需要唯一编码的情况，例如在密码学中，并确保需要数字签名的数据结构产生唯一的序列化表示。DER 可以被认为是 BER 的规范形式。

在密码学方面，可以简单理解为 DER 就是 ASN.1 的二进制表达，平常使用的后缀名为.der的密钥/证书文件里存储的就是 DER 规则的二进制，这些二进制可以被解析为 ASN.1 抽象结构。

举个例子，这是实际的一个 X.509 公钥的.der文件的字节内容：

30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01
01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01
00 B5 42 F1 89 F0 7D 0D 70 44 D3 CA 3D 6A 94 A8
D8 5A A7 C9 CC 02 8A 23 F7 AB F8 87 A7 3A 60 FC
EC DE 1D 25 8C 27 8D 19 C3 21 84 5C D4 D7 8A 2E
32 BF 66 C1 51 8A 94 B3 72 06 BE D5 B8 41 15 DF
7F C4 1B 55 F4 4A 60 CC 54 0B B8 AD 3F AF AF 71
FC 17 42 78 72 AC 8D 5E BE C3 29 D8 98 6B AA DB
90 86 AB 08 A7 19 FE 33 FB FB 56 23 EE 33 3E F3
95 98 09 38 6C B9 A1 F9 F5 18 94 1B 8E CF D2 F0
27 4B BC 24 52 0C 70 E4 A6 B9 EB 96 60 14 09 BB
7C B7 FF E4 B0 17 A4 28 68 55 D5 1E 5E 84 57 CD
9C E0 FC 35 31 A7 53 80 BE 30 82 94 34 15 C0 75
DB EF A4 BB 01 D7 E6 17 83 52 8B 2E 0E B1 DA C5
32 2D B6 F7 EB 2F AE 3A ED DE 3B FA 3A F8 F2 5D
BC 84 BC E3 F8 BB 1B 5D 85 06 AB C2 B8 8A 82 8E
9D 38 71 79 54 7E 91 FA 7A 14 CF 20 AF 5E 54 22
F1 B6 D3 D2 89 21 43 75 65 3D 74 4B D7 2E 78 52
03 02 03 01 00 01

它对应的 ASN.1 为：

SEQUENCE {
  SEQUENCE {
    OBJECT IDENTIFIER 1.2.840.113549.1.1.1 rsaEncryption (PKCS #1)
    NULL
  }
  BIT STRING {
    SEQUENCE {
      INTEGER 228821442744892501318627381803596567786967739438082404228277133253533…
      INTEGER 65537
    }
  }
}

2.2.1.2 文本格式 pem

互联网上使用的几个安全相关标准定义了 ASN.1 数据格式，这些格式通常使用基本编码规则（BER）或可分辨编码规则（DER）进行编码，这是二进制的编码。二进制数据格式的一个缺点是不能在文本传输（如电子邮件或文本文档）中交换。基于文本的编码的一个优点是，它们很容易使用通用文本编辑器进行修改；例如，用户可以连接多个证书以形成具有复制和粘贴操作的证书链。

隐私增强邮件（PEM, Privacy Enhanced Mail）则可以追溯到 RFC 1421，这是基于 Marshall Rose 在消息封装（RFC 934）中提出的建议。最初被称为“PEM 封装机制”、“封装的 PEM 消息”或“PEM 可打印编码”，今天这种格式有时被称为“PEM 编码”。它指定了语法的标准格式，并将行尾字符声明为回车符/换行符对。

简单来说，它实际上就是把二进制内容用 Base64 编码一下，然后加上-----BEGIN label-----形式的头部和-----END label-----形式的尾部。

不过，RFC 是通过查看现有实现并记录它们所做的事情来编写的。RFC 不是首先编写的，也不是基于一些现有的权威文档编写的。因此，如果想要与某些实现进行互操作，则可能必须查看实现的源代码以确定它们支持的内容。

例如，OpenSSL 在crypto/pem/pem.h中定义了这些 BEGIN 和 END 标记。以下是头文件的摘录，其中包含它们支持的所有 BEGIN 和 END 标签。

# define PEM_STRING_X509_OLD     "X509 CERTIFICATE"
# define PEM_STRING_X509         "CERTIFICATE"
# define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE"
# define PEM_STRING_X509_REQ_OLD "NEW CERTIFICATE REQUEST"
# define PEM_STRING_X509_REQ     "CERTIFICATE REQUEST"
# define PEM_STRING_X509_CRL     "X509 CRL"
# define PEM_STRING_EVP_PKEY     "ANY PRIVATE KEY"
# define PEM_STRING_PUBLIC       "PUBLIC KEY"
# define PEM_STRING_RSA          "RSA PRIVATE KEY"
# define PEM_STRING_RSA_PUBLIC   "RSA PUBLIC KEY"
# define PEM_STRING_DSA          "DSA PRIVATE KEY"
# define PEM_STRING_DSA_PUBLIC   "DSA PUBLIC KEY"
# define PEM_STRING_PKCS7        "PKCS7"
# define PEM_STRING_PKCS7_SIGNED "PKCS #7 SIGNED DATA"
# define PEM_STRING_PKCS8        "ENCRYPTED PRIVATE KEY"
# define PEM_STRING_PKCS8INF     "PRIVATE KEY"
# define PEM_STRING_DHPARAMS     "DH PARAMETERS"
# define PEM_STRING_DHXPARAMS    "X9.42 DH PARAMETERS"
# define PEM_STRING_SSL_SESSION  "SSL SESSION PARAMETERS"
# define PEM_STRING_DSAPARAMS    "DSA PARAMETERS"
# define PEM_STRING_ECDSA_PUBLIC "ECDSA PUBLIC KEY"
# define PEM_STRING_ECPARAMETERS "EC PARAMETERS"
# define PEM_STRING_ECPRIVATEKEY "EC PRIVATE KEY"
# define PEM_STRING_PARAMETERS   "PARAMETERS"
# define PEM_STRING_CMS          "CMS"

PEM文件的文件格式：

-----BEGIN (label)-----
/*　　data　　*/
-----END (label)-----

label 决定了被编码消息的类型，通常这些类型有如下一些：
“CERTIFICATE”, “CERTIFICATE REQUEST”, “PRIVATE KEY”, “ENCRYPTED PRIVATE KEY” and “X509 CRL”.

如，X.509 公钥的标记为：

-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

X.509 证书的标记为：

---- BEGIN CERTIFICATE----
/* 证书 */
----END CERTIFICATE----

X.509 证书请求的标记为：

-----BEGIN CERTIFICATE REQUEST-----
/*    CSR    */
-----END CERTIFICATE REQUEST-----

PKCS #1 公钥的标记为：

-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----

PKCS #1 加密私钥的标记为：

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

PKCS #8 未加密私钥的标记为：

-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

PKCS #8 加密后私钥的标记为：

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

2.2.2 文件后缀名

前面我们知道了二进制和文本形式的证书格式，那么为了便于用户识别证书的协议等信息，约定了一些后缀，通过后缀，用户大概就知道了证书的一些信息

文件后缀	文件类型	说明
*.CRT	二进制格式或文本格式	Certificate的缩写，表示证书文件，且只含有证书信息，不包含私钥。多用于linux系统
*.CER	二进制格式或文本格式	和上面的crt几乎相同，表示证书文件，多用于windows
*.PEM	文本格式	既是协议，又可作为后缀；文本格式IDE编码，一般存放证书或私钥，或同时包含证书和私钥。 .PEM文件如果只包含私钥，一般用.KEY文件代替。
*.DER	二进制格式	既是协议，又可作为后缀；二进制格式IDE编码，一般存放证书或私钥，或同时包含证书和私钥。
.PFX或.P12	二进制格式	同时包含证书和私钥，且一般有密码保护。
.JKS	二进制格式	同时包含证书和私钥，一般有密码保护。

从上面表格可看到：

CER或CRT 就是证书的代名词，并且不含私钥。
der 和pem 是协议，又可以直接作为后缀名，让用户知道是用二进制还是文本存储的，但是具体的内容可以是证书，也可以是密钥
pem格式，可以直接通过 cat命令查看，以”—–BEGIN…”开头, “—–END…”结尾
二进制格式无法直接查看，可以通过 openssl x509 -text -in server.cert 进行查看，此时会转换为以”—–BEGIN…”开头, “—–END…”结尾
二进制和文本之间PEM可以互相转换，因为只是编码格式的转换，你也可以把pem转换为二进制格式
PFX和JKS 是包含证书和私钥的，其他的一定都不含。
- 利用Java的一个叫”keytool”的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS
- 此外，证书含有私钥，那么别人获取证书时，要是导出私钥怎么办？很简单，在创建pfx时，有参数可以禁止导出私钥；即使允许导出私钥，你需要提供导出私钥的密码，这个密码保证了不是任何人都能随意导出私钥
BER是编码的基础规范，一般不作为文件的具体后缀名
.csr 是证书请求文件，由客户生成，然后提供给CA签发机构，是由 RFC 2986定义的PKCS10格式，包含部分/全部的请求证书的信息，比如，主题, 机构，国家等，并且包含了请求证书的公玥，这些被CA签发机构中心签名后返回一张证书。返回的证书是公钥证书（只包含公玥不含私钥）。

也就是说公司名称等这些参数是放在请求文件中的，并且含有公钥，一并交给CA机构，公钥怎么来的？是利用私钥生成的，因此这个步骤入参需要私钥。虽然用到了私钥，但是产出的请求文件中，一定不含私钥。

证书签名请求是申请人向证书颁发机构发送的一条消息，用于申请数字身份证书。

有 CSR 必定有 KEY，是成对的，CSR 最终变成为证书 crt，和私钥 key 配对使用。证书下发后，CSR 就没有用了，只是在交时候需要。

3. 常见Web服务软件及证书格式

证书的使用分为2种场景，一种是web服务器，就是我们通过浏览器访问web网站时，由网站侧开启Https，通过443端口进行安全通信，背后实际上是web服务器在起作用，而web服务器能只能识别指定的证书格式；另一个场景就是端到端通信，就是socket编码，此时需要根据不同的语言，来实现具体的证书格式。

常见的 Web 服务软件，通常都基于 OpenSSL 和 Java 两种基础密码库。

Tomcat、Weblogic、JBoss 等 Web 服务软件，一般使用 Java 提供的密码库。通过 Java Development Kit（JDK）工具包中的 Keytool 工具，生成 Java Keystore（JKS）、keystore 格式的证书文件。

.keystore 和 .jks 都是 java 用来存放密钥的文件。它使用户能够管理自己的公钥/私钥对及相关证书，用于（通过数字签名）自我认证（用户向别的用户/服务认证自己）或数据完整性以及认证服务。它还允许用户储存他们的通信对等者的公钥（以证书形式）。
Apache、Nginx 等 Web 服务软件，一般使用 OpenSSL 工具提供的密码库，生成 PEM、KEY、CRT 等格式的证书文件。
IBM 的 Web 服务产品，如 Websphere、IBM Http Server（IHS）等，一般使用 IBM 产品自带的 iKeyman 工具，生成 KDB 格式的证书文件。
微软 Windows Server 中的 Internet Information Services（IIS）服务，使用 Windows 自带的证书库生成 PFX 格式的证书文件。