PKI 体系

按照 X.509 规范,公钥可以通过证书机制来进行保护,但证书的生成、分发、撤销等步骤并未涉及。

实际上,要实现安全地管理、分发证书需要遵循 PKI(Public Key Infrastructure)体系。该体系解决了证书生命周期相关的认证和管理问题。

需要注意,PKI 是建立在公私钥基础上实现安全可靠传递消息和身份确认的一个通用框架,并不代表某个特定的密码学技术和流程。实现了 PKI 规范的平台可以安全可靠地管理网络中用户的密钥和证书。目前包括多个具体实现和规范,知名的有 RSA 公司的 PKCS(Public Key Cryptography Standards)标准和 OpenSSL 等开源工具。

PKI 基本组件

一般情况下,PKI 至少包括如下核心组件:

  • CA(Certification Authority):负责证书的颁发和吊销(Revoke),接收来自 RA 的请求,是最核心的部分;
  • RA(Registration Authority):对用户身份进行验证,校验数据合法性,负责登记,审核过了就发给 CA;
  • 证书数据库:存放证书,多采用 X.500 系列标准格式。可以配合LDAP 目录服务管理用户信息。

其中,CA 是最核心的组件,主要完成对证书信息的维护。

常见的操作流程为,用户通过 RA 登记申请证书,提供身份和认证信息等;CA 审核后完成证书的制造,颁发给用户。用户如果需要撤销证书则需要再次向 CA 发出申请。

证书的签发

CA 对用户签发证书实际上是对某个用户公钥,使用 CA 的私钥对其进行签名。这样任何人都可以用 CA 的公钥对该证书进行合法性验证。验证成功则认可该证书中所提供的用户公钥内容,实现用户公钥的安全分发。

用户证书的签发可以有两种方式。可以由用户自己生成公钥和私钥,然后 CA 来对公钥内容进行签名(只有用户持有私钥);也可以由 CA 直接来生成证书(内含公钥)和对应的私钥发给用户(用户和 CA 均持有私钥)。

前者情况下,用户一般会首先自行生成一个私钥和证书申请文件(Certificate Signing Request,即 csr 文件),该文件中包括了用户对应的公钥和一些基本信息,如通用名(common name,即 cn)、组织信息、地理位置等。CA 只需要对证书请求文件进行签名,生成证书文件,颁发给用户即可。整个过程中,用户可以保持私钥信息的私密性,不会被其他方获知(包括 CA 方)。

生成证书申请文件的过程并不复杂,用户可以很容易地使用开源软件 openssl 来生成 csr 文件和对应的私钥文件。

例如,安装 openssl 后可以执行如下命令来生成私钥和对应的证书请求文件:

  1. $ openssl req -new -keyout private.key -out for_request.csr
  2. Generating a 1024 bit RSA private key
  3. ...........................++++++
  4. ............................................++++++
  5. writing new private key to 'private.key'
  6. Enter PEM pass phrase:
  7. Verifying - Enter PEM pass phrase:
  8. -----
  9. You are about to be asked to enter information that will be incorporated
  10. into your certificate request.
  11. What you are about to enter is what is called a Distinguished Name or a DN.
  12. There are quite a few fields but you can leave some blank
  13. For some fields there will be a default value,
  14. If you enter '.', the field will be left blank.
  15. -----
  16. Country Name (2 letter code) [AU]:CN
  17. State or Province Name (full name) [Some-State]:Beijing
  18. Locality Name (eg, city) []:Beijing
  19. Organization Name (eg, company) [Internet Widgits Pty Ltd]:Blockchain
  20. Organizational Unit Name (eg, section) []:Dev
  21. Common Name (e.g. server FQDN or YOUR name) []:example.com
  22. Email Address []:
  23. Please enter the following 'extra' attributes
  24. to be sent with your certificate request
  25. A challenge password []:
  26. An optional company name []:

生成过程中需要输入地理位置、组织、通用名等信息。生成的私钥和 csr 文件默认以 PEM 格式存储,内容为 base64 编码。

如生成的 csr 文件内容可能为:

  1. $ cat for_request.csr
  2. -----BEGIN CERTIFICATE REQUEST-----
  3. MIIBrzCCARgCAQAwbzELMAkGA1UEBhMCQ04xEDAOBgNVBAgTB0JlaWppbmcxEDAO
  4. BgNVBAcTB0JlaWppbmcxEzARBgNVBAoTCkJsb2NrY2hhaW4xDDAKBgNVBAsTA0Rl
  5. djEZMBcGA1UEAxMQeWVhc3kuZ2l0aHViLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB
  6. jQAwgYkCgYEA8fzVl7MJpFOuKRH+BWqJY0RPTQK4LB7fEgQFTIotO264ZlVJVbk8
  7. Yfl42F7dh/8SgHqmGjPGZgDb3hhIJLoxSOI0vJweU9v6HiOVrFWE7BZEvhvEtP5k
  8. lXXEzOewLvhLMNQpG0kBwdIh2EcwmlZKcTSITJmdulEvoZXr/DHXnyUCAwEAAaAA
  9. MA0GCSqGSIb3DQEBBQUAA4GBAOtQDyJmfP64anQtRuEZPZji/7G2+y3LbqWLQIcj
  10. IpZbexWJvORlyg+iEbIGno3Jcia7lKLih26lr04W/7DHn19J6Kb/CeXrjDHhKGLO
  11. I7s4LuE+2YFSemzBVr4t/g24w9ZB4vKjN9X9i5hc6c6uQ45rNlQ8UK5nAByQ/TWD
  12. OxyG
  13. -----END CERTIFICATE REQUEST-----

openssl 工具提供了查看 PEM 格式文件明文的功能,如使用如下命令可以查看生成的 csr 文件的明文:

  1. $ openssl req -in for_request.csr -noout -text
  2. Certificate Request:
  3. Data:
  4. Version: 0 (0x0)
  5. Subject: C=CN, ST=Beijing, L=Beijing, O=Blockchain, OU=Dev, CN=yeasy.github.com
  6. Subject Public Key Info:
  7. Public Key Algorithm: rsaEncryption
  8. RSA Public Key: (1024 bit)
  9. Modulus (1024 bit):
  10. 00:f1:fc:d5:97:b3:09:a4:53:ae:29:11:fe:05:6a:
  11. 89:63:44:4f:4d:02:b8:2c:1e:df:12:04:05:4c:8a:
  12. 2d:3b:6e:b8:66:55:49:55:b9:3c:61:f9:78:d8:5e:
  13. dd:87:ff:12:80:7a:a6:1a:33:c6:66:00:db:de:18:
  14. 48:24:ba:31:48:e2:34:bc:9c:1e:53:db:fa:1e:23:
  15. 95:ac:55:84:ec:16:44:be:1b:c4:b4:fe:64:95:75:
  16. c4:cc:e7:b0:2e:f8:4b:30:d4:29:1b:49:01:c1:d2:
  17. 21:d8:47:30:9a:56:4a:71:34:88:4c:99:9d:ba:51:
  18. 2f:a1:95:eb:fc:31:d7:9f:25
  19. Exponent: 65537 (0x10001)
  20. Attributes:
  21. a0:00
  22. Signature Algorithm: sha1WithRSAEncryption
  23. eb:50:0f:22:66:7c:fe:b8:6a:74:2d:46:e1:19:3d:98:e2:ff:
  24. b1:b6:fb:2d:cb:6e:a5:8b:40:87:23:22:96:5b:7b:15:89:bc:
  25. e4:65:ca:0f:a2:11:b2:06:9e:8d:c9:72:26:bb:94:a2:e2:87:
  26. 6e:a5:af:4e:16:ff:b0:c7:9f:5f:49:e8:a6:ff:09:e5:eb:8c:
  27. 31:e1:28:62:ce:23:bb:38:2e:e1:3e:d9:81:52:7a:6c:c1:56:
  28. be:2d:fe:0d:b8:c3:d6:41:e2:f2:a3:37:d5:fd:8b:98:5c:e9:
  29. ce:ae:43:8e:6b:36:54:3c:50:ae:67:00:1c:90:fd:35:83:3b:
  30. 1c:86

需要注意,用户自行生成私钥情况下,私钥文件一旦丢失,CA 方由于不持有私钥信息,无法进行恢复,意味着通过该证书中公钥加密的内容将无法被解密。

证书的吊销

证书超出有效期后会作废,用户也可以主动向 CA 申请吊销某证书文件。

由于 CA 无法强制收回已经颁发出去的数字证书,因此为了实现证书的作废,往往还需要维护一个吊销证书列表(Certificate Revocation List,CRL),用于记录已经吊销的证书序号。

因此,通常情况下,当对某个证书进行验证时,需要首先检查该证书是否已经记录在列表中。如果存在,则该证书无法通过验证。如果不在,则继续进行后续的证书验证过程。

为了方便同步吊销列表信息,IETF 提出了在线证书状态协议(Online Certificate Status Protocol,或 OCSP),支持该协议的服务可以实时在线查询吊销的证书列表信息。