@zhongdao
2021-11-24T18:11:05.000000Z
字数 19577
阅读 1388
使用 openssl 命令行构建 CA 及证书
使用 OpenSSL 来生成 CA (证书授权中心 certificate authority)、 中级 CAintermediate CA 和末端证书end certificate。
将设置我们自己的根 CAroot CA,然后使用根 CA 生成一个示例的中级 CA,并使用中级 CA 签发最终用户证书。
对于创建终端用户证书的部分, 添加了定制化的参数, 并写成shell便于批量发放特定的终端用户证书.
pki的概念
CA的示例
相关概念说明如下:
CA中心又称CA机构,即证书授权中心(Certificate Authority ),或称证书授权机构,作为电子商务交易中受信任的第三方,承担公钥体系中公钥的合法性检验的责任。
CA中心为每个使用公开密钥的用户发放一个数字证书,数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。
X.509是一种非常通用的证书格式。所有的证书都符合ITU-T X.509国际标准,因此(理论上)为一种应用创建的证书可以用于任何其他符合X.509标准的应用。
在一份证书中,必须证明公钥及其所有者的姓名是一致的。对X.509证书来说,认证者总是CA或由CA指定的人,一份X.509证书是一些标准字段的集合,这些字段包含有关用户或设备及其相应公钥的信息。X.509标准定义了证书中应该包含哪些信息,并描述了这些信息是如何编码的(即数据格式)
有的行业会定制一些证书的字段, 进行规范.
mkdir -p ~/ca-company/root/
cd ~/ca-company/root/
openssl genrsa -out rootca.key 8192
需要为你的根 CA 提供识别信息:
# openssl req -sha256 -new -x509 -days 3650 -key rootca.key -out rootca.crt
提示如下信息并输入
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:Beijing
Locality Name (eg, city) []:Beijing
Organization Name (eg, company) [Internet Widgits Pty Ltd]:cfec.com.cn
Organizational Unit Name (eg, section) []:dc.cfec.com.cn
Common Name (e.g. server FQDN or YOUR name) []:ca.dc.cfec.com.cn
Email Address []:7975032@qq.com
配置CA相关文件,存储证书序号,crl作废列表序号.
touch certindex
echo 1000 > certserial
echo 1000 > crlnumber
CA根信息:
OrganmizationName: DC.cfec.com.cn
organizationalUnitName: CA.DC.cfec.com.cn
commonName: CA.DC.cfec.com.cn
# vim ca.conf
[ ca ]
default_ca = myca
[ crl_ext ]
issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always
[ myca ]
dir = ./
new_certs_dir = $dir
unique_subject = no
certificate = $dir/rootca.crt
database = $dir/certindex
private_key = $dir/rootca.key
serial = $dir/certserial
default_days = 730
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions
crlnumber = $dir/crlnumber
default_crl_days = 3650
[ myca_policy ]
commonName = supplied
organizationName = supplied
organizationalUnitName = supplied
[ myca_extensions ]
basicConstraints = critical,CA:TRUE
keyUsage = critical,any
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
keyUsage = digitalSignature,keyEncipherment,cRLSign,keyCertSign
extendedKeyUsage = serverAuth
[ v3_ca ]
basicConstraints = critical,CA:TRUE,pathlen:0
keyUsage = critical,any
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
keyUsage = digitalSignature,keyEncipherment,cRLSign,keyCertSign
extendedKeyUsage = serverAuth
生成中级 CA 的私钥
openssl genrsa -out intermediate1.key 4096
生成其 CSR:
openssl req -new -sha256 -key intermediate1.key -out intermediate1.csr
输出如下, 请确保中级 CA 的主题名(CN,Common Name)和根 CA 的不同。
# openssl req -new -sha256 -key intermediate1.key -out intermediate1.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:BEIJING
Locality Name (eg, city) []:beijing
Organization Name (eg, company) [Internet Widgits Pty Ltd]:cfec.com.cn
Organizational Unit Name (eg, section) []:ca.dc.cfec.com.cn
Common Name (e.g. server FQDN or YOUR name) []:im.ca.dc.cfec.com.cn
Email Address []:junlicn@foxmail.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:123456
An optional company name []:
使用根 CA 为你创建的中级 CA 的 CSR 签名:
# openssl ca -batch -config ca.conf -notext -in intermediate1.csr -out intermediate1.crt
Using configuration from ca.conf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'CN'
stateOrProvinceName :ASN.1 12:'BEIJING'
localityName :ASN.1 12:'beijing'
organizationName :ASN.1 12:'cfec.com.cn'
organizationalUnitName:ASN.1 12:'ca.dc.cfec.com.cn'
commonName :ASN.1 12:'im.ca.dc.cfec.com.cn'
emailAddress :IA5STRING:'junlicn@foxmail.com'
Certificate is to be certified until Dec 25 08:17:15 2019 GMT (730 days)
Write out database with 1 new entries
Data Base Updated
生成 CRL (包括 PEM 和 DER 两种格式):
openssl ca -config ca.conf -gencrl -keyfile rootca.key -cert rootca.crt -out rootca.crl.pem
openssl crl -inform PEM -in rootca.crl.pem -outform DER -out rootca.crl
如果需要的话,你可以撤销revoke这个中级证书:
openssl ca -config ca.conf -revoke intermediate1.crt -keyfile rootca.key -cert rootca.crt
给该中级 CA 创建新目录,并进入:
mkdir ~/SSLCA/intermediate1/
cd ~/SSLCA/intermediate1/
从根 CA 那边复制这个中级 CA 的证书和私钥:
cp ../root/intermediate1.key ./
cp ../root/intermediate1.crt ./
创建索引文件
touch certindex
echo 1000 > certserial
echo 1000 > crlnumber
创建中级CA的配置文件
[ ca ]
default_ca = myca
default_enddate = 20251222035911
default_startdate = 20171213035911
[ crl_ext ]
issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always
[ myca ]
dir = ./
new_certs_dir = $dir
unique_subject = no
certificate = $dir/intermediate1.crt
database = $dir/certindex
private_key = $dir/intermediate1.key
serial = $dir/certserial
default_days = 3650
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions
crlnumber = $dir/crlnumber
default_crl_days = 365
[ myca_policy ]
commonName = supplied
organizationName = supplied
organizationalUnitName = supplied
dnQualifier = supplied
[ myca_extensions ]
basicConstraints = critical,CA:FALSE
keyUsage = critical,any
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
keyUsage = digitalSignature,keyEncipherment
#extendedKeyUsage = serverAuth
生成一个空的 CRL (包括 PEM 和 DER 两种格式):
openssl ca -config ca.conf -gencrl -keyfile intermediate1.key -cert intermediate1.crt -out intermediate1.crl.pem
openssl crl -inform PEM -in intermediate1.crl.pem -outform DER -out intermediate1.crl
使用新的中级 CA 来生成最终用户的证书。为每个你需要用此 CA 签名的最终用户证书重复这些步骤。
mkdir -p ~/SSLCA/enduser-certs
cd ~/SSLCA/enduser-certs
生成一个设备的公私钥对,2048bit的rsa
openssl genrsa -out SM.xxx.gfmodel.00001.key 2048
提取出公钥
openssl rsa -in SM.xxx.gfmodel.00001.key -pubout > SM.xxx.gfmodel.00001.key.pubkey.pem
说明: 如何生成公钥的指纹的base64编码
openssl rsa -in SM.xxx.gfmodel.00001.key -pubout | openssl base64 -d | dd bs=1 skip=24 2>/dev/null | openssl sha1 -binary | openssl base64
生成dnQualifier变量, 提供给subj的一个用于smpte标准的额外参数.
dnQualifier=`openssl rsa -in SM.xxx.gfmodel.00001.key -pubout | openssl base64 -d | dd bs=1 skip=24 2>/dev/null | openssl sha1 -binary | openssl base64`
如果有"/" 还要转义成"\/" 才行. 不然无法输入到 openssl里.
dnQualifier=`echo $dnQualifier | sed 's:/:\\\/:g'`
生成终端信息, 例如包含设备角色与序号
commonName="SM.xxx.gfmodel.00001"
生成证书使用者信息,附带dnQualifier的公钥指纹(除了第一个斜杠,后面用逗号或斜杠均可) , subj后面的双引号不能去掉.
# O: Organization
# OU: Organizational Unit
# CN: Common Name
echo $subj
/dnQualifier=QlG\/IRJiU4J5fmXkBRZbVmWY7HA=/O=xxx.com.cn/OU=dev.xxx.com.cn/CN=SM.xxx.gfmodel.00001
# 注意 / 之前的转义.
-subj参数可以直接把提示输入的信息输入到openssl里.不必手工交互式输入.
#OpenSSL Generate CSR non-interactive with -subj parameter.
openssl req -new -sha256 -key SM.xxx.gfmodel.00001.key -out SM.xxx.gfmodel.00001.csr -subj "$subj"
用1号中级 CA 签名最终用户的证书
cd ~/SSLCA/intermediate1
openssl ca -batch -config ca.conf -notext -in ~/SSLCA/enduser-certs/SM.xxx.gfmodel.00001.csr -out ~/SSLCA/enduser-certs/SM.xxx.gfmodel.00001.pem
输出如下信息:
Using configuration from ca.conf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
dnQualifier :PRINTABLE:'QlG/IRJiU4J5fmXkBRZbVmWY7HA='
organizationName :ASN.1 12:'xxx.com.cn'
organizationalUnitName:ASN.1 12:'dev.xxx.com.cn'
commonName :ASN.1 12:'SM.xxx.gfmodel.00001'
Certificate is to be certified until Dec 25 01:50:24 2022 GMT (1825 days)
Write out database with 1 new entries
Data Base Updated
生成 CRL (包括 PEM 和 DER 两种格式):
cd ~/SSLCA/intermediate1/
openssl ca -config ca.conf -gencrl -keyfile intermediate1.key -cert intermediate1.crt -out intermediate1.crl.pem
openssl crl -inform PEM -in intermediate1.crl.pem -outform DER -out intermediate1.crl
将根证书和中级证书连接起来创建证书链文件:
cat ../root/rootca.crt intermediate1.crt > ~/SSLCA/enduser-certs/SM.xxx.gfmodel.00001.chain
最终输出给最终用户的文件列表如下,将这些文件发送给最终用户:
SM.xxx.gfmodel.00001.pem # 公钥证书, 后缀为 pem 或者 crt 均可.
SM.xxx.gfmodel.00001.key # 私钥
SM.xxx.gfmodel.00001.chain # 根,中级CA的证书链
其中可以
cat gen_enduser_dc.sh
#endusername=SM.cfec.gfmodel.00002
endusername=$1
cd ~/SSLCA/enduser-certs
#生成一个设备的公私钥对,2048bit的rsa
openssl genrsa -out $endusername.key 2048
#提取出公钥
openssl rsa -in $endusername.key -pubout > $endusername.key.pubkey.pem
dnQualifier=`openssl rsa -in $endusername.key -pubout | openssl base64 -d | dd bs=1 skip=24 2>/dev/null | openssl sha1 -binary | openssl base64`
dnQualifier=`echo $dnQualifier | sed 's:/:\\\/:g'`
commonName="$endusername"
subj="/dnQualifier=$dnQualifier/O=xxx.com.cn/OU=dev.xxx.com.cn/CN=$commonName"
#OpenSSL Generate CSR non-interactive with -subj parameter.
openssl req -new -sha256 -key $endusername.key -out $endusername.csr -subj "$subj"
cd ~/SSLCA/intermediate1
openssl ca -batch -config ca.conf -notext -in ~/SSLCA/enduser-certs/$endusername.csr -out ~/SSLCA/enduser-certs/$endusername.pem
cd ~/SSLCA/intermediate1/
openssl ca -config ca.conf -gencrl -keyfile intermediate1.key -cert intermediate1.crt -out intermediate1.crl.pem
openssl crl -inform PEM -in intermediate1.crl.pem -outform DER -out intermediate1.crl
cat ../root/rootca.crt intermediate1.crt > ~/SSLCA/enduser-certs/$endusername.chain
cd ~/SSLCA/enduser-certs
openssl verify -CAfile SM.xxx.gfmodel.00001.chain SM.xxx.gfmodel.00001.pem
echo " final output: "
echo $endusername.crt
echo $endusername.key
echo $endusername.chain
通过如下命令使用证书链来验证最终用户证书:
也就是通过上一级CA一级一级地验证下边的证书是否是经过上级签名和认证的.
cd ~/SSLCA/enduser-certs
openssl verify -CAfile SM.cfec.gfmodel.00001.chain SM.cfec.gfmodel.00001.pem
你也可以用 CRL 来检查它,确保证书没有被废弃。
首先将 PEM CRL 连接到证书链文件:
cd ~/SSLCA/intermediate1
cat ../root/rootca.crt intermediate1.crt intermediate1.crl.pem > ~/SSLCA/enduser-certs/SM.cfec.gfmodel.00001.crl.chain
校验证书:
cd ~/SSLCA/enduser-certs
openssl verify -crl_check -CAfile SM.cfec.gfmodel.00001.crl.chain SM.cfec.gfmodel.00001.pem
如果该证书未撤销,输出如下:
SM.cfec.gfmodel.00001.pem: OK
如果撤销了,输出则不同,提示error
证书 | 等级 | 颁发者(Issuer) | 所有者(Subject) | 签名 | 公钥 |
---|---|---|---|---|---|
root.crt | 根 | ca .dc.cfec.com.cn |
ca .dc.cfec.com.cn |
自签名, sha 256, RSA | 8192bit RSA |
intermediate1.crt | 二级 | ca .dc.cfec.com.cn |
im .ca.dc.cfec.com.cn |
根CA签发, sha1 RSA | 4096bit RSA |
SM.00001.pem | 终端证书 | im .ca.dc.cfec.com.cn |
SM .cfec.gfmodel.00001 |
二级CA签发,sha256, RSA | 2048bit RSA |
查看证书请求文件的内容
openssl req -in SM.cfec.gfmodel.00001.csr -noout -text
如下可见对公钥做了签名。所以创建时需要同时提供公私钥,公钥公布出来加入证书,私钥用来进行数字签名,表示所有者与公钥的关系。
Certificate Request:
Data:
Version: 0 (0x0)
Subject: dnQualifier=QlG/IRJiU4J5fmXkBRZbVmWY7HA=, O=cfec.com.cn, OU=dev.cfec.com.cn, CN=SM.cfec.gfmodel.00001
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:de:69:4a:55:f4:83:b1:d3:fa:b8:80:15:99:eb:
48:6a:39:52:92:2b:d0:f4:64:29:6b:d7:e0:a1:63:
32:e9:71:8b:b6:81:1e:8e:d2:95:71:0f:e9:4b:fa:
22:43:e4:64:9b:eb:21:38:29:a9:3a:4f:ad:eb:fc:
61:9f:39:89:dc:51:0b:08:0a:f5:b8:5a:b2:dc:81:
9d:87:ca:30:81:0e:80:25:0f:a0:04:e5:dd:e6:ed:
71:ea:12:eb:ed:83:c4:83:5e:ef:4b:69:c5:9d:50:
6f:d8:dd:18:b4:a0:bc:4f:82:fb:9a:b7:00:fb:4e:
7d:93:cb:ff:ab:b1:14:e5:c1:0f:96:25:e3:9e:2b:
71:a5:d4:0c:71:06:c6:2e:f4:f3:33:f7:ba:1c:99:
33:7c:94:50:3f:38:f6:94:37:ce:9b:5e:c8:0d:ff:
4c:f5:a9:e4:46:d3:54:29:4f:b5:37:50:4c:b1:92:
47:79:0f:90:5e:e8:cb:50:9f:33:92:10:6b:22:d6:
2c:1b:5f:7d:c6:fe:b2:03:54:87:4e:b3:36:4e:9b:
a9:bf:88:8a:37:46:95:33:6b:2e:b7:26:b4:2a:7e:
ea:03:86:d1:54:a5:e3:9b:0d:23:12:e1:f5:d2:72:
1b:47:ad:ec:76:a3:31:79:14:f5:9d:46:07:a5:ea:
aa:c1
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
11:5c:20:d9:c1:98:34:71:b1:fa:3f:e0:b9:fe:72:e0:c5:e9:
9b:92:bc:aa:31:48:0e:d8:ca:96:c4:82:1a:a6:65:22:db:04:
1e:02:ec:3e:7b:bf:dd:c6:e7:86:d5:ca:2b:0e:ba:53:13:6c:
a7:71:0b:92:58:74:fa:e4:2f:76:0a:5f:2a:0c:23:ee:34:6b:
a9:b9:6b:ea:ee:2e:16:41:6c:0f:3a:7c:c0:85:fe:14:0d:24:
8e:b1:41:c7:98:d5:7b:0f:b1:aa:76:62:5a:22:67:26:d2:c5:
13:b8:53:23:e0:ca:4e:0d:b8:db:6d:15:60:90:28:6c:13:01:
b6:4a:06:c6:90:2c:f1:fa:1d:ab:4d:69:c2:3d:46:98:b3:0d:
dd:ee:30:e3:32:cf:91:cc:15:50:43:a3:97:8c:ea:3a:e2:95:
79:19:87:da:e4:1e:37:31:73:d7:49:cc:76:9d:04:81:96:e6:
61:37:0f:b8:1f:f4:09:b9:aa:0d:33:b5:40:95:b0:6c:1a:1f:
f8:89:ba:65:7b:75:f0:38:f4:90:a3:ab:ca:a8:0c:2b:c0:18:
ea:52:4b:84:d9:12:6f:c3:3f:bf:c1:ff:bf:72:0b:5c:9d:69:
4c:7f:f9:a0:7d:a5:90:4f:d5:20:6c:34:21:db:11:db:0c:00:
5c:a1:03:1d
结论:如果想通过硬件的形式生成公私钥对,私钥不对外泄露,那么 就需要硬件厂商提供openssl兼容的CSR文件接口,通过内置的私钥和签名算法生成证书请求的签名,进而得到证书请求文件CSR,然后再生成证书。
或者由Openssl 生成公私钥对,导出公钥,同时生成证书请求文件,同时将私钥写入硬件不可读区域,然后删除私钥, 确保私钥的不泄露。 或者CA服务器从物理上进行隔绝来确保私钥安全。
使用 openssl 命令行构建 CA 及证书 https://linux.cn/article-6498-1-rel.html
https://raymii.org/s/tutorials/OpenSSL_command_line_Root_and_Intermediate_CA_including_OCSP_CRL%20and_revocation.html
不能只用公钥创建CSR的原因
https://stackoverflow.com/questions/14617306/how-can-i-create-a-certificate-service-request-csr-from-and-existing-public-ke
https://security.stackexchange.com/questions/116356/csr-with-only-public-key-with-openssl
SSL Converter
https://www.sslshopper.com/ssl-converter.html
https://www.freecodecamp.org/news/openssl-command-cheatsheet-b441be1e8c4a/
最常见的 OpenSSL 命令 https://www.sslshopper.com/article-most-common-openssl-commands.html
非常全面完整严谨的 教程, 有简单、专家级的CA创建过程命令。
https://pki-tutorial.readthedocs.io/en/latest/index.html
shell 包装的 一个简单 CA ,用于OPENvpn ,有意思!
https://github.com/OpenVPN/easy-rsa/blob/master/README.quickstart.md
https://letsencrypt.org/docs/glossary/
CA Issuers : Part of the AIA field containing information about the issuer of the certificate. It may be useful when the web server didn’t provide a trusted certificate chain.
CA 颁发者 (CA Issuers) : AIA 字段的一部分,包含证书颁发者的信息。它在Web服务器没有提供受信任的证书链时可能会有用。
ECDSA (椭圆曲线数字签名算法 - Elliptic Curve Digital Signature Algorithm) : 使用椭圆曲线加密的数字签名算法(DSA)的变体。维基百科条目。Let’s Encrypt 支持使用 ECDSA 的叶证书(终端实体证书),但没有全部使用 ECDSA 的完整证书链
OCSP (在线证书状态协议 - Online Certificate Status Protocol) : 检查证书的吊销状态的方法。也就是说,这是一个检查证书颁发机构是否表明证书不再有效(即使还没有到过期日期)的方法。这种请求可能会造成隐私问题,因为它允许证书颁发机构的互联网服务提供商直接得知谁在在访问哪些网站。
OCSP 装订 (OCSP stapling) : Web 服务器向浏览器发送由证书颁发机构签名的 OCSP 回复的方法。该方法使得浏览器自身不必单独向 CA 发送 OCSP 请求,能够加快网页加载速度并增强安全性。
PEM 文件(.pem) (PEM file (.pem)) : 一种密码学信息的格式(原来作为“隐私增强型邮件”互联网标准的一部分被用于保护电子邮件)。PEM 文档可以用于表示私钥、公钥、数字证书等信息。这些文件以“—–BEGIN”加上数据类型开头。
SSL (安全套接字层 - Secure Sockets Layer) : TLS 以前的名字,仍旧很常用。
TLS (传输层安全 - Transport-Level Security) : HTTPS 用于加密和认证网页访问的协议。
X.509 : 定义了公钥证书格式的标准。维基百科条目
个人信息交换文件(.pfx) (Personal Information Exchange Files (.pfx)) : 可以包含叶证书、其链接至根证书的证书链以及叶证书的私钥的文件。详见 https://en.wikipedia.org/wiki/PKCS_12
PKCS #12 是由RSA 实验室发布的称为公钥加密标准(PKCS)的标准系列之一。PKCS #12定义了一种存档文件格式,用于将许多加密对象存储为单个文件。它通常用于将私钥与其X.509证书捆绑在一起或捆绑信任链的所有成员。 PKCS #12 文件的文件扩展名是.p12或.pfx。可以使用OpenSSL pkcs12命令创建、解析和读出这些文件。 PKCS #12 是微软“PFX”的继承者;然而,术语“PKCS #12 文件”和“PFX 文件”有时可以互换使用。
PKCS #12 文件通常使用OpenSSL创建,它仅支持来自命令行界面的单个私钥。从 Java 9 开始,PKCS #12 是默认的密钥库格式。
PKCS #12 的一种更简单的替代格式是PEM,它仅将证书和可能的私钥列为文本文件中的Base 64字符串。
Certificate signing request
在公共密钥基础设施(PKI)的系统中,证书签名请求(也CSR或认证请求)是从申请人发送到一个消息注册机构registration authority 的的公共密钥基础设施,以便施加用于数字身份证书。它通常包含应为其颁发证书的公钥、标识信息(如域名)和完整性保护(如数字签名)。CSR 最常见的格式是PKCS #10 规范;
一个认证请求包括三个主要部分:认证请求信息、签名算法标识符和对认证请求信息的数字签名。第一部分包含重要信息,包括公钥。请求者的签名可防止实体请求他人公钥的伪造证书。2 因此,需要私钥来生成 CSR,但它不是 CSR 的一部分。
https://en.wikipedia.org/wiki/Certificate_signing_request
CSR的流程:
在创建 CSR 之前,申请人首先生成一个密钥对,将私钥保密。CSR包含信息识别申请人(如专有名称中的情况下X.509证书),其必须使用申请人的签名私钥。CSR 还包含申请人选择的公钥。CSR 可能附有证书颁发机构要求的其他凭据或身份证明,证书颁发机构可能会与申请人联系以获取更多信息。
如果请求成功,证书颁发机构将发回已使用证书颁发机构的私钥进行数字签名的身份证书。
中间证书 (Intermediate certificate) : 被根证书或另一个空间证书签名的,能够对其他证书签名的证书。它们被用于在保持根证书的私钥离线的前体下对叶证书进行签名。中间证书会被包含在证书链中。
叶证书(终端实体证书) (Leaf certificate (end-entity certificate)) : 大多数情况下,证书由中间证书签名,对一组域名有效,且不能对其他证书签名。
吊销 (Revocation) : 证书在其到期之前一直有效,除非 CA 声明它被吊销了。证书可能因包括私钥泄露在内的多种原因被吊销。浏览器可以通过 CRL、OCSP 或像 OneCRL 和 CRLSets 一类的较新的方法来检查证书是否被吊销。注意在许多情况下,吊销证书是没有用的。
OCSP
https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
域名验证型证书 (Domain-validated certificate) : 申请者仅证明了其对域名(而非申请的组织)的控制权的证书。
密钥对 (Key-pair) : 用于签名或加密的公钥和私钥的组合。公钥通常嵌入在证书中,而私钥则独立保密存储。根据不同的应用情况,密钥对可以用于加密和解密、签名和验证数据或是协商二级密钥。
对象标识符 (OID - Object identifier) : OID 是由国际电信联盟(ITU)和 ISO/IEC 标准化的具有唯一性的数字标识符。在证书中,OID 被用于定义扩展、字段和政策断言。
底线要求 (BRs - Baseline Requirements) : 一组针对 CA 的技术和政策上的要求。由于所有根证书项目都包含了底线要求,CA 若要被大多数浏览器信任就必须遵循这些要求。
根证书 (Root certificate) : 由证书颁发机构控制,用于对中间证书签名且包含在证书存储内的自签名证书。维基百科条目
根证书项目 (Root Program) : 有关组织用于确定在其证书存储中包含哪些证书(即哪些 CA 被其软件信任)的政策。
椭圆曲线加密 (ECC - Elliptic Curve Cryptography) : 基于椭圆曲线的公钥密码学。相较于非椭圆曲线的加密方式,ECC 在提供同等的安全性的前提下使用更小的密钥。
用户 (Subscriber) : 请求证书的个人或组织。
用户代理 (User Agent) : 能够与Web服务器通信的软件。例如:网页浏览器和 cURL。
真实名称记录 (CNAME - Canonical Name record) : 将一个域名映射到另一个域名(称为真实名称)的 DNS 记录。
证书透明度 (CT - Certificate Transparency) : 为了增强安全性,证书(或准证书)必须被发布到证书透明度日志上:https://www.certificate-transparency.org/。Let’s Encrypt 生成并发布准证书,并在之后的证书中包含了准证书的 SCT 列表。部分浏览器(如 Google Chrome)要求这一可验证的承诺必须出现在证书中,以便其验证该证书。
证书吊销列表 (CRL - Certificate Revocation List) : 通知用户代理证书的吊销状态的方法。这是一个由 CA 签名的,包含了所有已被该 CA 吊销的证书的序列号的列表。
证书存储 (Certificate Store) : 证书存储包含有受信任的根证书的列表。操作系统(如 Windows、Android、Debian)和网页浏览器(如 Firefox)都维护有证书存储。没有证书存储的浏览器依赖于操作系统的证书存储。
证书实践声明 (CPS - Certification Practice Statement,也被翻译成认证业务规则) : 证书颁发机构对证书进行颁发、管理、吊销、续期、更换密钥时所采用的实践的声明。ISRG 证书实践声明 https://letsencrypt.org/documents/isrg-cps-v4.1/
证书包a certificate bundle
The list of certificates that the browser needs to validate a certificate is called a certificate bundle.
叶证书的所有者有一个问题:仅向浏览器提供叶证书通常是不够的。浏览器并不总是知道中间证书,需要网站将它们包含在叶证书中。浏览器验证证书所需的证书列表称为证书包。它应该包含链中的所有证书,直到浏览器已知的第一个证书。
X.509 : 定义了公钥证书格式的标准。https://zh.wikipedia.org/wiki/X.509
证书 (Certificate) : 包含公钥以及其他一些描述何时使用该公钥的信息的特定格式的文件。叶证书是最常见的证书类型。另外还有中间证书和根证书这两种证书。
自签名证书 (Self-signed certificate) : 由其自己的私钥签名,并且主体与颁发者相同的证书。自签名证书仅会因为现实世界的事先安排(例如加入到受信任的根证书列表中)而被信任。根证书都是自签名的。
证书扩展 (Certificate extension) : 在证书中,大多数字段都是由扩展来定义的。例如,主体备用名称和 AIA 都是扩展。扩展机制使得添加并非原始 X.509 标准一部分的新字段成为可能。
证书链 (Certificate chain) : 帮助用户代理决定它是否可以信任叶证书(终端实体证书)的,将该证书链接到证书存储中的根证书的中间证书列表。注意:证书链并不总是唯一的,即使网站提供了链接到一个根证书的证书链,用户代理仍可能会选择使用另一个证书链来验证证书。
证书主体 (Certificate subject) : 证书的“主体”字段指明其内容。它通产包含通用名称、国家以及组织等字段。
证书颁发者 (Certificate issuer) : 证书中的"颁发者"字段描述了对该证书进行签名的证书。例如,Let’s Encrypt 颁发的终端实体证书的颁发者字段可能是:“Issuer: C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3”。它通常包含通用名称、国家、组织等字段。颁发者字段必须与某个证书的主体字段一致。对于自签名证书(例如根证书)来说,颁发者字段和其主体字段内容相同。“颁发者”这个词也可以被用于指代颁发其他证书的证书(中间证书或根证书)或组织。
通用名称 (CN - Common Name) : 用于描述证书内容的主体信息的一部分。对于根证书和中间证书来说它是证书颁发机构的人类可读的名字。对于叶证书来说它是证书上的域名之一。注意:通用名称最长 63 个字符。它曾被用于指示证书适用的域名,但现在已被废弃,因为当前的互联网标准要求软件仅通过检查主体备用名称来确定证书的适用性。
主体备用名称 (SAN - Subject Alternative Name) : 证书中用于指定其对哪些域名有效的字段。它代替了通用名称字段(后者现在仅因兼容性原因而提供)。单个证书可能包含多个 SAN 以使其对多个不同域名生效。
CMP Operations Guide
https://doc.primekey.com/ejbca/ejbca-operations/ejbca-operations-guide/ca-operations-guide/enrollment-protocol-configuration/cmp-operations-guide
在密码学中,PKCS代表“公钥密码学标准”.这些是由RSA Security LLC 于 1990 年代初设计和发布的一组公钥密码学标准。
近年来的一些标准已经开始进入“标准跟踪”相关标准组织(例如IETF和PKIX工作组)的流程。
PKCS | 版本 | 姓名 | 注释 |
---|---|---|---|
PKCS #1 | 2.2 | RSA 密码学标准[1] | 请参阅 RFC 8017。定义 RSA 公钥和私钥的数学属性和格式(以明文形式编码的ASN.1),以及用于执行 RSA 加密、解密以及生成和验证签名的基本算法和编码/填充方案。 |
PKCS #2 | —— | 撤销 | 2010 年不再活跃。涵盖消息摘要的 RSA 加密;随后合并到 PKCS #1。 |
PKCS #3 | 1.4 | Diffie-Hellman 密钥协议标准[2] | 一种加密协议,它允许互不了解的两方通过不安全的通信通道共同建立共享密钥。 |
PKCS #4 | —— | 撤销 | 2010 年不再活跃。涵盖 RSA 密钥语法;随后合并到 PKCS #1。 |
PKCS #5 | 2.1 | 基于密码的加密标准[3] | 请参阅 RFC 8018 和PBKDF2。 |
PKCS #6 | 1.5 | 扩展证书语法标准[4] | 定义对旧 v1 X.509证书规范的扩展。已被 v3 过时。 |
PKCS #7 | 1.5 | 加密消息语法标准[5] | 请参阅 RFC 2315。用于在PKI下签署和/或加密消息。也用于证书分发(例如作为对 PKCS #10 消息的响应)。形成S/MIME的基础,自 2010 年起基于 RFC 5652,更新的加密消息语法标准(CMS)。通常用于单点登录。 |
PKCS #8 | 1.2 | 私钥信息语法标准[6] | 请参阅 RFC 5958。用于携带私有证书密钥对(加密或未加密)。 |
PKCS #9 | 2.0 | 选定的属性类型[7] | 请参阅 RFC 2985。定义在 PKCS #6 扩展证书、PKCS #7 数字签名消息、PKCS #8 私钥信息和 PKCS #10 证书签名请求中使用的选定属性类型。 |
PKCS #10 | 1.7 | 认证请求标准[8] | 请参阅 RFC 2986。发送到认证机构以请求公钥认证的消息格式。请参阅证书签名请求。 |
PKCS #11 | 3.0 | 加密令牌接口[9] | 也称为“Cryptoki”。定义加密令牌的通用接口的API(另请参阅硬件安全模块)。通常用于单点登录、公钥加密和磁盘加密[10]系统。RSA Security 已将 PKCS #11 标准的进一步开发移交给OASIS PKCS 11 技术委员会。 |
PKCS #12 | 1.1 | 个人信息交换语法标准[11] | 参见RFC 7292.定义通常用于存储的文件格式私钥伴随公钥证书,与基于密码保护的对称密钥。PFX 是 PKCS #12 的前身。这种容器格式可以包含多个嵌入对象,例如多个证书。通常用密码保护/加密。可用作Java 密钥存储的格式并在 Mozilla Firefox 中建立客户端身份验证证书。可供Apache Tomcat 使用。 |
PKCS #13 | —— | 椭圆曲线密码标准 | (显然已放弃,仅参考 1998 年的提案。)[12] |
PKCS #14 | —— | 伪随机数生成 | (显然已放弃,不存在任何文件。) |
PKCS #15 | 1.1 | 密码令牌信息格式标准[13] | 定义一个标准,允许加密令牌的用户向应用程序标识他们自己,独立于应用程序的 Cryptoki 实现 (PKCS #11) 或其他API。RSA 已将本标准中与 IC 卡相关的部分放弃给 ISO/IEC 7816-15。[14] |