假设由Bob和Alice两个用户，他们之间想要通信，必须首先进行密钥交换： 使用公钥密码，Alice只需要将她的公钥发给Bob，Bob可以生成一个密钥，并用Alice的公钥加密后发送给Alice，由于Alice是唯一可以解密的人，窃听这个通信的攻击者是无法获得密钥的。 中间人攻击： 假设Mallory是一个攻击者，她可以截获Alice与Bob之间的通信并实施攻击： Mallory实施攻击的过程如下：
Mallory截获Alice发送的公钥，用自己的公钥代替Alice的公钥发送给Bob。 Bob无法判断公钥的来源，因为消息看起来是来自Alice的，因此他用收到的公钥加密自己生成的随机密钥。 Mallory截获Bob的加密消息，由于消息是用她的公钥加密的，因此她可以解密消息，获得随机密钥，随后，她用Alice的公钥将随机密钥加密后发送个Alice。 Alice可以解密消息，获得随机密钥，然后Alice与Bob就可以用该密钥来加密他们之间的通信。 由于Mallory以及获得了这个密钥，因此她可以解密Alice与Bob之间的整个通信，并且可以修改他们的通信数据，Alice与Bob之间的通信安全完全被破坏。 防御中间人攻击 中间人攻击的基本问题是Bob收到声称是Alice的公钥，但他没有办法判别这个公钥是否属于Alice。 数字签名也是基于公钥密码学的，它用签名者的私钥签名，任何知道签名者公钥的人都可以验证它，如果消息的内容被篡改，数字签名就失效了。 可以用数字签名技术防御中间人攻击，因此之前的Alice和Bob可以找一个信任方对他们的身份进行验证，Alice可以到DMV办公室出示她的身份证并提交她的公钥，她必须亲自到DMV办公室，从而保证没有其他人可以截获这个流程，在验证完ID后，DMV办公室会准备一个数字文件，其中包含Alice的名字和公钥，以及一些其他信息，如过期时间等，DMV办公室为这个数字文件进行数字签名，这个数字文件和数字签名称为证书。 现在，当Alice发送他的公钥给Bob时，Alice也发送整个证书给Bob，因此公钥与一个经信任机构验证过的名字一起发过来，Mallory仍然可能截获证书，但是她不能用自己的公钥代替Alice的公钥且仍然保持Alice的名字，那将使DMV的签名无效，，如果他将自己的证书发给Bob,Bob将不知道这个公钥属于Alice，因此会终止通信，Mallory没有办法获得一个包含她的公钥和Alice名字的证书，因为作为信任机构知道Mallory不是Alice，它会拒绝签发这样的证书。 为了验证DMV在Alice证书上的签名，Bob需要获得DMV的公钥，但是他不能通过网络获得，因为这又得面临潜在的中间人攻击，他也必须亲自到DMV办公室以获得它的公钥。 公钥基础设施 两个重要组件：
认证机构（CA）：他们负责验证用户的身份并且提供经由他们签名的数字证书。 数字证书：他提供了一个公钥以及与这个公钥相关的信息，认证机构需要在数字证书上签名以证明它核实过证书的内容，数字证书也称为公钥证书。 公钥证书由公钥和它的拥有者，以及认证机构的签名组成。证书接收者可以验证签名以确保证书的完整性，在认证成功后，接收者可以得到公钥真正拥有者。 X.509数字证书 Certificate:
Data:
Version: 3 ( 0x2)
Serial Number:
0e:c3:4e:77:02:57:00:4f:ad:cc:f4:a2:f5:19:d6:0c
Signature Algorithm: sha256WithRSAEncryption
Issuer: C= US, O= DigiCert Inc, OU= www.digicert.com, CN= DigiCert SHA2 Extended Validation Server CA
Validity
Not Before: Jan 9 00:00:00 2020 GMT
Not After : Jan 12 12:00:00 2022 GMT
Subject: businessCategory= Private Organization/jurisdictionC= US/jurisdictionST= Delaware/serialNumber= 3014267, C= US, ST= California, L= San Jose, O= PayPal, Inc., OU= CDN Support, CN= www.paypal.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: ( 2048 bit)
Modulus:
00:ab:9a:c4:47:e6:4f:4b:f0:7a:29:6f:9a:1d:6b:
4e:d5:04:0e:b2:02:ed:8d:d1:a9:ae:d5:da:20:8c:
7e:8a:49:1a:3c:09:13:f7:72:ee:2e:40:e0:29:41:
02:78:97:55:f8:06:0d:7b:2a:e3:e0:b3:e5:64:f2:
de:b8:b8:35:e1:c5:7c:eb:12:e3:68:47:74:6c:bc:
04:25:33:09:17:28:e0:c9:3a:b2:4e:65:50:d0:4a:
e4:3b:b2:e1:2e:82:45:cb:52:05:3b:a4:b7:37:eb:
c8:29:fc:43:67:cc:66:a9:e5:9f:22:1b:1b:f7:86:
36:35:9b:45:f5:0f:6c:3d:1d:15:55:5d:fe:ca:7d:
5c:ef:1d:76:b7:f0:59:85:89:1a:c9:d2:bf:58:bc:
26:9c:11:75:60:cb:59:e6:74:18:ee:0e:06:bc:54:
a1:47:f9:f5:b5:c0:be:ad:6d:ee:dd:99:b6:50:ed:
85:33:f5:bd:93:4b:66:a9:08:f0:67:c7:bd:42:24:
c2:3b:e3:7f:f1:e2:51:62:b5:51:ae:21:a8:24:d9:
c9:ed:d3:b4:60:17:6a:0c:78:69:c1:96:ad:62:1d:
18:11:a6:ea:f4:83:eb:2d:ae:b0:be:2e:56:9d:cf:
9d:2c:70:5a:df:b2:1e:3a:c7:e4:23:e3:3b:58:e1:
fd:9d
Exponent: 65537 ( 0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:3D:D3:50:A5:D6:A0:AD:EE:F3:4A:60:0A:65:D3:21:D4:F8:F8:D6:0F
X509v3 Subject Key Identifier:
F0:1E:F5:E3:EE:33:53:69:54:6A:27:40:E0:CE:84:B6:69:68:4B:9E
X509v3 Subject Alternative Name:
DNS:www.paypal.com, DNS:login.paypal.com, DNS:history.paypal.com, DNS:www.paypalobjects.com, DNS:pics.paypal.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/sha2-ev-server-g2.crl
Full Name:
URI:http://crl4.digicert.com/sha2-ev-server-g2.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.114412.2.1
CPS: https://www.digicert.com/CPS
Policy: 2.23.140.1.1
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2ExtendedValidationServerCA.crt
X509v3 Basic Constraints: critical
CA:FALSE
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1( 0)
Log ID : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
Timestamp : Jan 9 00:41:33.309 2020 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:F6:D8:70:6F:DE:F3:A1:DF:10:DF:94:
78:E6:27:98:A9:7C:60:D1:C2:09:7D:39:DE:18:E6:4B:
D4:79:F7:FB:00:02:21:00:A5:B9:13:F3:F6:69:AB:70:
DC:D0:F3:AD:1F:EF:FA:4F:57:0E:38:00:6C:48:A8:78:
99:9C:8C:32:94:97:21:24
Signed Certificate Timestamp:
Version : v1( 0)
Log ID : 56:14:06:9A:2F:D7:C2:EC:D3:F5:E1:BD:44:B2:3E:C7:
46:76:B9:BC:99:11:5C:C0:EF:94:98:55:D6:89:D0:DD
Timestamp : Jan 9 00:41:33.535 2020 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:FF:91:95:F6:47:8B:41:58:C0:BD:19:
73:8B:9F:98:A0:5C:F2:9A:24:22:2A:F2:64:0F:48:B7:
DE:40:22:8D:DC:02:20:4B:9A:A9:F1:79:A3:01:65:10:
CA:BC:FC:24:F5:0A:9D:9A:1A:05:10:F0:2E:0C:EF:CC:
A9:AF:24:84:13:29:A0
Signed Certificate Timestamp:
Version : v1( 0)
Log ID : EE:4B:BD:B7:75:CE:60:BA:E1:42:69:1F:AB:E1:9E:66:
A3:0F:7E:5F:B0:72:D8:83:00:C4:7B:89:7A:A8:FD:CB
Timestamp : Jan 9 00:41:33.381 2020 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:44:02:20:08:FE:99:AB:2F:BE:95:36:08:E0:23:F7:
FA:0D:EE:50:A2:46:00:51:D3:F4:8A:75:8C:74:62:02:
A4:53:5C:8A:02:20:13:8A:4C:E6:E2:C7:0D:38:39:EB:
49:29:D4:23:43:4C:FA:4B:01:8C:D2:DB:CB:7F:39:4C:
84:14:E4:A4:DD:24
Signature Algorithm: sha256WithRSAEncryption
95:06:8c:5c:1c:39:aa:19:33:0c:70:58:7f:94:2b:a4:71:be:
f7:13:4e:23:73:f0:a8:7c:35:16:0e:e2:be:59:56:3d:8c:5d:
fa:8c:fb:dd:de:8e:34:a3:6a:b3:86:5b:29:52:4a:5f:f7:cb:
1f:33:b8:c8:60:3b:30:72:94:fc:61:df:5d:80:2f:f9:8f:ad:
f3:85:98:2a:e8:ed:6c:02:e1:3e:d0:cc:ef:68:36:4e:ae:51:
6d:ca:2e:7b:ae:a3:79:3d:27:67:74:15:4d:cf:c9:1d:a1:f9:
43:69:ce:66:b2:eb:ec:c4:31:48:27:d9:2d:e2:eb:f4:72:0a:
73:23:d1:9c:5d:8e:34:b2:95:a3:a8:09:16:ce:2f:bf:d1:f8:
47:bd:c1:6d:36:7e:3a:9c:58:c1:47:40:92:8e:b6:32:97:89:
5e:fb:46:c3:3d:2c:06:46:23:86:2a:6c:d2:3a:18:3e:3a:2b:
fc:c3:3a:c0:17:6a:4c:32:f5:d2:a8:a9:a3:5f:2a:53:c9:bf:
88:9f:0f:c6:74:63:7d:83:17:49:60:72:d2:cb:c9:b8:02:58:
f7:d9:f0:3c:fe:1f:4d:fb:eb:43:a0:fa:58:9e:19:1c:b7:6c:
45:ec:0c:b9:0d:4a:09:be:76:68:35:48:62:5c:82:3c:80:e4:
e7:7b:66:f7
Issuer：这个域提供签发证书的认证机构的信息。 Subject：这个域提供该证书拥有者的信息。 Subject Public Key Info：这个域包含实际的公钥。 Signature Algorithm：这个域包含签发者的数字签名。 Validity：这个域定义了证书的有效时间。 Serial Number：每一个证书都有一个独特的序列号，这个序列号位于证书的开头部分。 Extension：新版本的X.509证书包含可选拓展域。 从真实服务器获取证书 下面的openssl s_client命令开启一个HTTPS客户端，并且连接到Paypal网站，使用-showcerts选项可以打印处所有从Paypal服务器接收到的证书： [ 07/19/20] seed@VM:~$ openssl s_client -showcerts -connect www.paypal.com:443 < /dev/null
上面的命令不打印证书的原始内容，而是打印已被编码的内容，X.509证书使用的使二进制数据，其中有很多不能打印的字符，也无法复制粘贴。 我们将得到证书的内容，保存在pem文件中： [ 07/20/20] seed@VM:~$ cat paypal.pem
-----BEGIN CERTIFICATE-----
MIIHmTCCBoGgAwIBAgIQDsNOdwJXAE+tzPSi9RnWDDANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTIwMDEwOTAwMDAwMFoXDTIyMDExMjEy
MDAwMFowgdwxHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlVTMRkwFwYLKwYBBAGCNzwCAQITCERlbGF3YXJlMRAwDgYDVQQF
EwczMDE0MjY3MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8G
A1UEBxMIU2FuIEpvc2UxFTATBgNVBAoTDFBheVBhbCwgSW5jLjEUMBIGA1UECxML
Q0ROIFN1cHBvcnQxFzAVBgNVBAMTDnd3dy5wYXlwYWwuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq5rER+ZPS/B6KW+aHWtO1QQOsgLtjdGprtXa
IIx+ikkaPAkT93LuLkDgKUECeJdV+AYNeyrj4LPlZPLeuLg14cV86xLjaEd0bLwE
JTMJFyjgyTqyTmVQ0ErkO7LhLoJFy1IFO6S3N+vIKfxDZ8xmqeWfIhsb94Y2NZtF
9Q9sPR0VVV3+yn1c7x12t/BZhYkaydK/WLwmnBF1YMtZ5nQY7g4GvFShR/n1tcC+
rW3u3Zm2UO2FM/W9k0tmqQjwZ8e9QiTCO+N/8eJRYrVRriGoJNnJ7dO0YBdqDHhp
wZatYh0YEabq9IPrLa6wvi5Wnc+dLHBa37IeOsfkI+M7WOH9nQIDAQABo4IDuzCC
A7cwHwYDVR0jBBgwFoAUPdNQpdagre7zSmAKZdMh1Pj41g8wHQYDVR0OBBYEFPAe
9ePuM1NpVGonQODOhLZpaEueMGcGA1UdEQRgMF6CDnd3dy5wYXlwYWwuY29tghBs
b2dpbi5wYXlwYWwuY29tghJoaXN0b3J5LnBheXBhbC5jb22CFXd3dy5wYXlwYWxv
YmplY3RzLmNvbYIPcGljcy5wYXlwYWwuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4wbDA0oDKgMIYuaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcyLmNybDA0oDKg
MIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcyLmNy
bDBLBgNVHSAERDBCMDcGCWCGSAGG/WwCATAqMCgGCCsGAQUFBwIBFhxodHRwczov
L3d3dy5kaWdpY2VydC5jb20vQ1BTMAcGBWeBDAEBMIGIBggrBgEFBQcBAQR8MHow
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBSBggrBgEFBQcw
AoZGaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkV4dGVu
ZGVkVmFsaWRhdGlvblNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMIIBfgYKKwYB
BAHWeQIEAgSCAW4EggFqAWgAdwCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jjd80O
yA3cEAAAAW+Hv9N9AAAEAwBIMEYCIQD22HBv3vOh3xDflHjmJ5ipfGDRwgl9Od4Y
5kvUeff7AAIhAKW5E/P2aatw3NDzrR/v+k9XDjgAbEioeJmcjDKUlyEkAHYAVhQG
mi/XwuzT9eG9RLI+x0Z2ubyZEVzA75SYVdaJ0N0AAAFvh7/UXwAABAMARzBFAiEA
/5GV9keLQVjAvRlzi5+YoFzymiQiKvJkD0i33kAijdwCIEuaqfF5owFlEMq8/CT1
Cp2aGgUQ8C4M78yprySEEymgAHUA7ku9t3XOYLrhQmkfq+GeZqMPfl+wctiDAMR7
iXqo/csAAAFvh7/TxQAABAMARjBEAiAI/pmrL76VNgjgI/f6De5QokYAUdP0inWM
dGICpFNcigIgE4pM5uLHDTg560kp1CNDTPpLAYzS28t/OUyEFOSk3SQwDQYJKoZI
hvcNAQELBQADggEBAJUGjFwcOaoZMwxwWH+UK6RxvvcTTiNz8Kh8NRYO4r5ZVj2M
XfqM+93ejjSjarOGWylSSl/3yx8zuMhgOzBylPxh312AL/mPrfOFmCro7WwC4T7Q
zO9oNk6uUW3KLnuuo3k9J2d0FU3PyR2h+UNpzmay6+zEMUgn2S3i6/RyCnMj0Zxd
jjSylaOoCRbOL7/R+Ee9wW02fjqcWMFHQJKOtjKXiV77RsM9LAZGI4YqbNI6GD46
K/zDOsAXakwy9dKoqaNfKlPJv4ifD8Z0Y32DF0lgctLLybgCWPfZ8Dz+H03760Og
+lieGRy3bEXsDLkNSgm+dmg1SGJcgjyA5Od7Zvc=
-----END CERTIFICATE-----
把PEM文件解码为原始二进制数据，解密结果无法用文本编辑器查看，需要使用二进制文件查看器，例如ghex和bless。 [ 07/20/20] seed@VM:~/.. ./pki$ openssl x509 -in paypal.pem -outform der > paypal.der
[ 07/20/20] seed@VM:~/.. ./pki$ ls
paypal.der paypal.pem
直接查看X.509证书的原始二进制数据和Base64编码后的数据，看到的都是乱码，可以用以下命令把这些乱码转换成可读的形式： [ 07/20/20] seed@VM:~/.. ./pki$ openssl x509 -in paypal.pem -text -noou
认证机构（CA）是一个可信的、能够签发数字证书的实体，在签发证书之前，CA需要验证证书申请者的身份。 CA核心功能有两个： Subject域验证：数字证书的重要组成部分是Subject域，Subject域由证书拥有者的身份信息组成，在签发证书之前，CA需要确认证书申请者拥有或代表Subject域内注册的身份。在许多公钥证书中，SUbject域包含一个域名，CA需要检查申请者是否拥有该域名。 签名数字证书：一旦CA验证了证书申请者的身份，它就可以用私钥为这个证书生成一个数字签名，这个数字签名实际上将证书中的公钥和它的拥有者绑定在一起，任何对证书的篡改都将使证书失效，任何人只要拥有CA的公钥就可以验证证书的真伪。 申请数字证书的过程如下：首先银行和ModelA需要生成各自的“公钥-私钥”对，然后，银行生成一个证书签名请求，其中包含获得证书需要的域名和公钥，银行提交请求给ModelCA,ModelCA会对请求中的信息进行验证，包括验证bank32是否属于该银行。 一旦所有信息被验证，ModelCA会用自己的私钥生成一个数字证书，这个数字证书将交给银行，银行部署基于HTTPS的网络服务器。 ubuntu进行模拟： 用openssl创建一个CA，签名时，openssl会使用一个默认的配置文件（/usr/lib/ssl/openssl.cnf)，该文件中以及配置了需要的文件夹和文件的名字。根据这些配置我们创建如下文件夹及文件，serial文件包含证书的序列号，可以将1000或任意数字放在文件夹中来初始化序列号。 [ 07/20/20] seed@VM:~/.. ./pki$ mkdir demoCA
[ 07/20/20] seed@VM:~/.. ./pki$ cd demoCA/
[ 07/20/20] seed@VM:~/.. ./demoCA$ mkdir certs crl newcerts
[ 07/20/20] seed@VM:~/.. ./demoCA$ touch index.txt serial
[ 07/20/20] seed@VM:~/.. ./demoCA$ echo 1000 > serial
为ModelCA生成公钥-私钥对和证书：为了验证CA生成的证书，需要用到CA的公钥，因此每一个CA都需要有自己的数字证书，如果CA是一个中间CA，那么它的证书由其他CA颁发，如果CA是一个根CA，则需要自己给自己颁发公钥证书，也就是自己在公钥证书上签名，这样的证书称为自签名证书。 下面需要为ModelCA创建公钥-私钥对，并且为它生成一个自签名的证书： [ 07/20/20] seed@VM:~/.. ./demoCA$ openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -keyout modelCA_key.pem -out modelCA_cert.pem
Generating a 4096 bit RSA private key
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ++
.. .. .. .. .. .. .. .. ++
writing new private key to 'modelCA_key.pem'
Enter PEM pass phrase:
3070285504:error:28069065:lib( 40) :UI_set_result:result too small:ui_lib.c:823:You must type in 4 to 1024 characters
3070285504:error:0906406D:PEM routines:PEM_def_callback:problems getting password:pem_lib.c:110:
3070285504:error:0907E06F:PEM routines:DO_PK8PKEY:read key:pem_pk8.c:130:
公钥和私钥对存储在受密码保护的文件modelCA_key.pem中，选项-x509指明生成一个自签名的公钥证书，而不是一个整数请求，自签名的证书保存在modelCA_cert.pem中，该证书在3650天内有效。 为了获得X.509证书，银行首先需要生成自己的公钥-私钥对，这可以由以下的opensl命令实现： [ 07/20/20] seed@VM:~/.. ./demoCA$ openssl genrsa -aes128 -out bank_key.pem 2048
Generating RSA private key, 2048 bit long modulus
.. +++
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .+++
e is 65537 ( 0x10001)
Enter pass phrase for bank_key.pem:
Verifying - Enter pass phrase for bank_key.pem:
以上命令生成一个名为bank_key.pem的文件，这个文件由用户设置的密码保护，如果没有-aes128选项则不需要密码保护，可以用下面指令查看bank_key.pem的实际内容： [ 07/20/20] seed@VM:~/.. ./demoCA$ openssl rsa -noout -text -in bank_key.pem
Enter pass phrase for bank_key.pem:
Private-Key: ( 2048 bit)
modulus:
00:d4:71:89:e6:0e:dc:f1:b4:05:25:fe:88:f4:6f:
.. .
publicExponent: 65537 ( 0x10001)
privateExponent:
00:86:e0:2e:b4:a8:eb:0d:69:45:7b:81:c6:61:aa:
1b:fa:63:0c:3f:25:2a:e7:1b:d5:ab:fb:8a:0c:99:
.. .
c4:41
prime1:
00:f4:e0:28:45:0d:a7:be:8d:c1:f8:1f:5a:2a:0e:
ad:78:27:22:0d:94:bc:9f:c7:43:89:01:c5:07:f8:
..
prime2:
00:de:18:34:3b:73:bc:61:93:e7:86:da:36:d0:33:
ad:76:e8:23:bb:89:fc:1f:2e:59:60:fd:97:d1:27:
.. .
exponent1:
6c:c0:c8:e1:b2:28:d7:96:39:99:2a:c3:6e:7e:4a:
48:5c:88:e1:23:37:8a:76:82:e5:ec:25:47:5e:d5:
..
exponent2:
54:63:92:05:3d:16:c9:64:ef:c6:77:c7:f8:18:8a:
..
coefficient:
00:ee:2e:62:31:8d:09:ec:db:61:cc:34:87:4e:01:
9d:7a:a8:23:3c:00:1e:2b:6e:79:b3:d1:c0:ad:3c:
..
可以看到，bank_key.pem除了包含公钥、私钥、模数的质因子，还包含一些数字，例如指数1、指数2和系数，这些数用来对解密进行优化的。 为了从CA处获得公钥证书，银行需要创建一个证书签名请求，请求中包含银行的公钥与其身份的细节，请求中包含银行的公钥与其身份的司机，如机构的名称，地址与域名等，可以用下面的命令生成基于bank_key.pem的证书请求信息。 [ 07/20/20] seed@VM:~/.. ./demoCA$ openssl req -new -key bank_key.pem
-out bank.csr -sha256
Common Name ( e.g. server FQDN or YOUR name) [ ] :bank32.com
openssl程序会要求提供主题信息，如公司名、地址、邮件等，在常用名CN域，使用bank32.com，把生成的证书签名请求保存在bank.csr中，这是一个经过编码的文件，可以允许下面命令查看该文件： [ 07/20/20] seed@VM:~/.. ./demoCA$ openssl req -in bank.csr -text -noout
Certificate Request:
Data:
Version: 0 ( 0x0)
Subject: C= CN, ST= Henan, L= XINyang, O= bank, OU= bank, CN= bank32.com/emailAddress= 125686568@qq.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: ( 2048 bit)
Modulus:
00:d4:71:89:e6:0e:dc:f1:b4:05:25:fe:88:f4:6f:
9e:91:c9:9a:20:19:da:91:a3:58:7f:b0:00:d6:6e:
97:53:30:8f:bf:ca:bb:6d:af:8e:69:55:97:92:99:
73:1b:f9:8c:34:43:3a:d6:12:d6:14:03:6b:b5:2c:
19:9b:d2:ec:7a:1b:78:7b:e0:6e:05:90:44:7f:89:
08:8c:42:8e:af:90:95:df:dc:94:a6:c5:48:92:14:
de:09:b6:93:c4:a4:0c:19:31:2f:58:dd:25:4b:83:
da:c7:b8:ae:4a:f8:05:6d:9e:f9:76:76:0b:39:74:
bd:14:94:f7:8c:a1:c3:43:0b:40:05:3a:e5:d4:67:
09:89:5b:d3:ad:b2:bc:dc:5a:85:45:5a:a2:b0:32:
46:bd:1c:d0:96:7d:f2:7f:74:ae:36:d3:af:fc:ad:
1c:c6:36:c1:05:8e:37:a6:09:28:27:a7:91:a1:20:
71:4d:55:b6:59:d7:d3:6d:2e:a6:9c:ed:f7:37:6c:
d8:9e:10:02:34:69:ef:b8:7c:b1:51:bf:0f:58:a3:
85:44:57:a4:0e:27:0a:e7:40:cd:eb:81:36:dd:56:
7d:d7:4e:eb:c4:6a:41:89:cb:87:ec:4a:21:b5:68:
68:88:d5:4a:1b:d2:af:b2:17:6d:94:44:dd:13:0e:
e8:e7
Exponent: 65537 ( 0x10001)
Attributes:
unstructuredName :unable to print attribute
challengePassword :unable to print attribute
Signature Algorithm: sha256WithRSAEncryption
19:cc:98:6b:bc:3b:e7:f7:cf:9c:d2:b0:43:d7:37:94:10:99:
d7:8a:b1:75:61:26:04:fe:46:a2:d8:96:39:40:3e:c5:0e:9b:
d7:03:47:88:93:2f:a4:14:5c:27:19:70:db:33:c7:25:48:95:
5e:e9:10:4a:09:51:35:3c:4f:45:dc:61:61:96:88:b4:a0:cf:
dd:9c:89:43:4d:6d:f3:61:ff:b8:e0:22:97:9e:c7:04:5b:78:
6e:51:71:b0:5a:15:eb:f4:c6:13:54:8d:2e:b0:15:0a:77:c2:
4f:b2:f9:21:aa:2a:b2:be:ce:85:bb:fc:37:1f:de:39:e8:28:
b8:1e:34:29:d4:16:0b:49:58:ee:74:7e:8d:74:a4:03:e6:25:
e7:d3:c2:6a:83:fe:2c:62:5a:1a:ab:60:53:52:09:d1:60:2a:
7d:4e:17:e7:c1:e4:00:16:69:aa:4f:69:3c:1c:e9:57:3e:0a:
5d:da:31:65:e0:1b:47:6b:79:39:ef:18:e2:2c:ac:d5:5e:40:
33:27:24:cc:1a:6f:a4:0d:3a:c2:bb:11:78:19:42:3e:cf:2a:
f8:17:0e:f5:55:ef:1e:16:5b:38:aa:8d:6e:a1:91:e9:94:33:
d2:8d:91:7a:7e:4d:21:9c:2d:cc:6c:c1:6b:de:71:39:6c:6a:
28:83:36:20
上面的证书签名请求中也包含一个数字签名，这个签名是由申请者用自己的私钥生成的，这个签名的目的是证明申请者的确知道请求中公钥所对应的私钥，通过校验这个签名，CA可以确信请求中的公钥的确属于申请者。 在现实世界中，银行在提交CSR文件给CA，CA在验证完CSR中的信息后，会给银行签发一个X.509证书，在本模拟实验，省略了验证这一步，直接使用下面的命令来生成证书： seed@VM:/home/seed/code/pki/demoCA$ openssl ca -in bank.csr -out bank_cert.pem
-md sha256 -cert modelCA_cert.pem -keyfile modelCA_key.pem
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for modelCA_key.pem:
I am unable to access the ./demoCA/newcerts directory
./demoCA/newcerts: No such file or directory
报错，显示没有newcerts这个目录，应该是文件路径解析出了问题，我们把配置文件复制到当前文件夹下，修改dir=./demoCA为dir=./，然后指定该文件为配置文件： seed@VM:/home/seed/code/pki/demoCA$ openssl ca -in bank.csr -out bank_cert.pem
-md sha256 -cert modelCA_cert.pem -keyfile modelCA_key.pem -config openssl.cnf
Using configuration from openssl.cnf
Enter pass phrase for modelCA_key.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 4096 ( 0x1000)
Validity
Not Before: Jul 20 07:16:05 2020 GMT
Not After : Jul 20 07:16:05 2021 GMT
Subject:
countryName = CN
stateOrProvinceName = Henan
organizationName = bank
organizationalUnitName = bank
commonName = bank32.com
emailAddress = 125686568@qq.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
F6:ED:8E:BA:02:57:30:30:5C:F3:5A:73:86:D8:4D:62:34:09:78:3D
X509v3 Authority Key Identifier:
keyid:7A:4D:24:90:8F:48:52:A6:F4:C8:B4:B0:38:AC:27:C7:98:9C:69:7E
Certificate is to be certified until Jul 20 07:16:05 2021 GMT ( 365 days)
Sign the certificate? [ y/n] :y
1 out of 1 certificate requests certified, commit? [ y/n] y
Write out database with 1 new entries
Data Base Updated
在网络服务器中部署公钥证书 一旦银行收到数字证书，他就可以在HTTPS网站中部署该证书，为了使用openssl自带的服务器，需要将银行的私钥文件和公钥证书合并到一个文件中，然后使用命令启动服务器，服务器监听4433端口： [ 07/20/20] seed@VM:~/.. ./demoCA$ cp bank_key.pem bank_all.pem
[ 07/20/20] seed@VM:~/.. ./demoCA$ cat bank_cert.pem >> bank_all.pem
[ 07/20/20] seed@VM:~/.. ./demoCA$ openssl s_server -cert bank_all.pem -accept 4433 -www
Enter pass phrase for bank_all.pem:
Using default temp DH parameters
ACCEPT
ACCEPT
ACCEPT
上述opensll命令启动一个HTTPS网站服务器，为了可以通过https://bank32.com访问该服务器，需要添加条目到客户端的/etc/hosts文件中，从而将主机名bank32.com映射到网站服务器的IP地址，为了方便实验，网站服务器在本机，及127.0.0.1. 使用火狐浏览器访问，显示这个连接不安全，这是因为浏览器没有modelCA的公钥，因此它们不能验证银行证书中的签名，浏览器有一个它信任的CA列表，但是很明显，ModelCA不在列表中，如果CA是不可信的，那么CA签发的证书也是不可信的。 为了进入信任列表，需要让浏览器开发者认为ModelCA是可信的CA，火狐浏览器允许用户手动添加CA证书到它的信任列表中。 添加完成之后，再次访问https://bank32.com:4433浏览器不再显示错误，能成功接收到来自服务器的响应。 除了使用浏览器，也可以使用openssl s_client命令访问网络服务器，这个命令可以输出大量调试信息，这对于观察客户端域服务器之间的交互相当有帮助： [ 07/20/20] seed@VM:~$ openssl s_client -connect bank32.com:4433
CONNECTED( 00000003)
depth= 0 C = CN, ST = Henan, O = bank, OU = bank, CN = bank32.com, emailAddress = 125686568@qq.com
verify error:num= 20:unable to get local issuer certificate
verify return:1
depth= 0 C = CN, ST = Henan, O = bank, OU = bank, CN = bank32.com, emailAddress = 125686568@qq.com
verify error:num= 21:unable to verify the first certificate
因为客户端程序无法获得签发者ModelCA的证书，所以它不能验证bank32.com的证书，使用-CAfile选项告诉客户端程序ModelCA的证书。 [ 07/20/20] seed@VM:~/.. ./demoCA$ openssl s_client -connect bank32.com:4433 -CAfile modelCA_cert.pem
CONNECTED( 00000003)
depth= 1 C = CN, ST = Henan, L = xinyang, O = bank, OU = bank, CN = bank, emailAddress = bank@qq.o\08co
verify return:1
depth= 0 C = CN, ST = Henan, O = bank, OU = bank, CN = bank32.com, emailAddress = 125686568@qq.com
verify return:1
---
使用Apache部署HTTPS 为了建立一个HTTPS网站，只需配置Apache服务器，让它知道从哪里得到私钥和证书即可，添加下面的VirtualHost条目到Apache服务器配置文件default-ssl.conf中： < VirtualHost _default_:443>
ServerName bank32.com
DocumentRoot /var/www/html
DirectoryIndex index.html
SSLEngine On
SSLCertificateFile /home/seed/code/pki/demoCA/bank_cert.pem
SSLCertificateKeyFile /home/seed/code/pki/demoCA/bank_key.pem
< /VirtualHost>
ServerName指定网站的URL，DocumentRoot指定网站文件的存放位置，还需要把公钥证书和私钥的文件名告诉Apache服务器，修改完Apache服务器，需要运行以下命令启动SSL，一旦部署成功，此时所有服务器与浏览器之间的流量都将被加密。 [ 07/20/20] seed@VM:~/.. ./demoCA$ sudo apachectl configtest
AH00112: Warning: DocumentRoot [ /var/www/seedlabclickjacking] does not exist
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the ' ServerName' directive globally to suppress this message
Syntax OK
[ 07/20/20] seed@VM:~/.. ./demoCA$ sudo a2enmod ssl
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
service apache2 restart
[ 07/20/20] seed@VM:~/.. ./demoCA$ sudo a2ensite default-ssl
Enabling site default-ssl.
To activate the new configuration, you need to run:
service apache2 reload
[ 07/20/20] seed@VM:~/.. ./demoCA$ sudo service apache2 restart
Enter passphrase for SSL/TLS keys for bank32.com:443 ( RSA) : ****
根CA和自签名证书 为了验证根CA签发的证书，需要有根CA的公钥，问题是如何安全的获取它，因为中间人攻击的问题，不能要求根CA把它的公钥发给用户，或通过其他人发给用户。 根CA的公钥通常通过一些特殊渠道分发给用户，它们被预装进操作系统、浏览器或者其他软件，这些软件为根CA的公钥进行担保，只要信任这些软件，那么也就信任了这些软件伴随而来的公钥。 根CA的公钥也存储在一个X.509证书中，但是这个证书并没有被其他CA签名，而是自签名，在自签名的X.509证书中，证书签发者和拥有着是同一个实体。 根CA可以将证书签发功能委派给其他信任的中间CA，然而这些中间CA的公钥不一定被外界所知，因此根CA必须为它们的公钥进行担保，也就是为了中间CA签发公钥证书，这样中间CA才可以为其他用户签发证书。 [ 07/20/20] seed@VM:~/.. ./demoCA$ openssl s_client -showcerts -connect www.alibaba.com:443
---
Certificate chain
0 s:/C= CN/ST= ZheJiang/L= HangZhou/O= Alibaba ( China) Technology Co., Ltd./CN= *.alibaba.com
i:/C= BE/O= GlobalSign nv-sa/CN= GlobalSign Organization Validation CA - SHA256 - G2
-----BEGIN CERTIFICATE-----
MIImajCCJVKgAwIBAgIMGEmABohi7zhwIKNtMA0GCSqGSIb3DQEBCwUAMGYxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH
bG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g
RzIwHhcNMjAwNzA5MDIyMjAyWhcNMjEwMzE3MDYwNDU3WjB6MQswCQYDVQQGEwJD
TjERMA8GA1UECBMIWmhlSmlhbmcxETAPBgNVBAcTCEhhbmdaaG91MS0wKwYDVQQK
.. .
-----END CERTIFICATE-----
1 s:/C= BE/O= GlobalSign nv-sa/CN= GlobalSign Organization Validation CA - SHA256 - G2
i:/C= BE/O= GlobalSign nv-sa/OU= Root CA/CN= GlobalSign Root CA
-----BEGIN CERTIFICATE-----
MIIEaTCCA1GgAwIBAgILBAAAAAABRE7wQkcwDQYJKoZIhvcNAQELBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
.. .
-----END CERTIFICATE-----
以上结果显示来自alibaba.com的所有证书，其中包含两个证书，第一个是Alibaba公司的证书，它是由名为GlobalSign Organization Validation CA - SHA256 - G2的CA签发的，这是一个中间CA。第二个整数是该中间CA自己的证书，它是由另一个名为GlobalSign Root CA，这是一个根CA。 客户端会通过以下步骤验证Alibaba公司证书：
检查根CA是否存在浏览器的信任列表中，如果在，说明浏览器已经有了根CA的公钥。 用根CA的公钥验证中间CA的证书。 用中间CA的公钥验证Alibaba公司的证书。 可以用openssl手动验证证书链，将Alibaba公司的证书保存为文件Alibaba.pem,将中间CA的证书保存为文件GlobalSign-G2.pem。从浏览器中获得GlobalSign Root CA的自签名证书，并将它保存为Global SignRootCA.pem，然后运行下面的命令验证Alibaba公司的证书。 $ openssl verify -verbose -CAfile GlobalSignRootCA.pem -untrusted GlobalSign-G2.pem
Alibaba.pem
选项-untrusted提供了一个证书链，该链的最后一个元素必须是域名服务器的证书，-CAfile选项提供了一个可信任的CA证书，把根CA的证书放在这里，它被用来验证证书链中的第一个证书，在验证完第一个证书后，第一个证书中的公钥来验证第二个证书，以此类推，如果整个证书链被成功验证，OK将被打印出来。 为中间CA制作证书 一个CA可以用openssl为中间CA签发证书，中间CA也需要生成一个证书请求（modelIntCA.csr),并将请求发送到一个可信CA，这个CA根据请求，用下面的命令生成一个证书：
[ 07/20/20] seed@VM:~/.. ./demoCA$ openssl genrsa -aes128 -out modelIntCA_key.pem 2048
[ 07/20/20] seed@VM:~/.. ./demoCA$ openssl req -new -key modelIntCA_key.pem -out modelIntC
A.csr -sha256
[ 07/20/20] seed@VM:~/.. ./demoCA$ openssl ca -in modelIntCA.csr -out modelIntCA_cert.pem -md sha256 -cert modelCA_cert.pem -keyfile modelCA_key.pem -extensions v3_ca -config openssl.cnf
上面的证书签发命令与签发服务器证书的命令基本相似，但它包含了一个-extensions v3_ca选项，这个选项会让openssl将证书拓展项中的CA字段设置为TRUE，该字段指明这个证书是否能来验证其他证书。 非CA证书的CA字段的值是FALSE，表示这个证书不能用来验证其他证书，也就是该证书的拥有者不能充当一个CA，如果非CA证书的拥有者为一些实体签发了证书，这些证书将无法被验证，因为签发者的证书不是一个CA证书。 Apache服务器的部署 如果网络服务器的证书是由中间CA颁发的，当客户端请求它的证书时，它应该给出所有涉及中间CA的证书，这些证书都应该放在一个文件中，并在Apache服务器配置文件default-ssl.conf的SSLCertificateFile条目中表明文件名： < VirtualHost _default_:443>
ServerName bank32.com
DocumentRoot /var/www/html
DirectoryIndex index.html
SSLEngine On
SSLCertificateFile /home/seed/code/pki/demoCA/bank_cert2.pem
SSLCertificateKeyFile /home/seed/code/pki/demoCA/bank_key.pem
< /VirtualHost>
注意此时的bank_cert2.pem中应该包括两个公钥证书，第一个是bank32的，第二个modelIntCA的，二者顺序不能颠倒。 获取google浏览器的可信CA。 进入settings页面，输入管理证书。 假设Alice想要用HTTPS访问example.com，她在浏览器中输入https://example.com，浏览器会与example.com服务器执行一个SSL握手协议，该服务器会返回它的证书，当存在一个中间人攻击时，攻击者可以拦截此握手协议。攻击者可以做以下几件事：
攻击者转发真实证书 如果攻击者转发来自eaxmple.com的真实证书给用户Alice，这个证书将通过验证，Alice的浏览器将用证书中的公钥加密一个密钥，由于攻击者不知道相应的密钥，他们将不会能解密被加密的密钥，这个密钥会用来在Alice与服务器之间建立一个SSL会话，一旦会话建立，攻击者就无法在做什么。 攻击者制作假证书 攻击者可以伪造一个example.com的证书，但是其中存放的是自己的公钥，没有任何一个CA会签发这样的证书，因为攻击者不是example.com的合法拥有者。 攻击者也可以自己为假证书签名，创建一个自签名证书，然而， 当Alice的浏览器接收到一个证书时，它会把该证书当成一个根CA的证书，但这个假的根CA证书并不被浏览器所信任，浏览器将显示警告，并让用户决定是中断连接还是继续访问，如果用户选择中断连接，该攻击将失败；如果用户忽视警告并继续访问，攻击将成功。 攻击者发送自己的证书 攻击者也可以发送自己的合法证书给Alice，在这个证书Subject域不能是example.com，因为攻击者不拥有example.com，攻击者只能在Subject域放入自己的合法身份（例如attacker32.com），一旦该证书到达Alice的浏览器，浏览器将用已经预装的可信证书区验证它，这个验证将通过，因为攻击者的证书是有效的，但这里还会有一个附加的验证。 浏览器需要知道证书的Subject域中的域名是否与用户的目的相同，注意Alice在浏览器中输入的是https://eaxample.com，因此浏览器知道Alice的目的是访问example.com，但是证书的Subject域是attacker32，这个不匹配导致浏览器立即中断握手协议。 在SSL握手期间，浏览器会进行两个重要的验证，第一个验证是核对接收到的证书是否有效，一个有效的证书能确保证书中公钥属于Subject域描述的主体，但是不能说明这个主体是否是用户想要访问的网站。第二个验证的目的，它检查的通用名称域是否域网站名一致。 在用户和HTTPS网站通信中可以插入中间人的，这种中间人叫HTTPS代理，它可以截获并检测浏览器与服务器之间的HTTPS流量，这是一个实实在在的中间人攻击。 HTTPS代理它为用户访问的每一个HTTPS网站创建一个假证书，假证书是由HTTPS代理签发的，显示，浏览器不能验证这些假证书，因为它没有HTTPS代理的公钥，但如果将HTTPS代理的证书添加到浏览器的信任列表，浏览器就有了HTTPS代理的公钥，并把它当成一个根CA来看待，用它来验证所由它签名的证书，因为用户自愿把HTTPS代理当成可信任的根CA，因此HTTPS代理并不算是攻击者。 PKI依赖的4个关键性校验和安全保证： CA的认证：为了抵御中间人攻击，对于客户端来说，知道接收到的公钥是否属于目的服务器很重要，由于不能相信公钥拥有者声称的所有者信息，因此不得不依赖于第三方CA获知公钥的实际拥有者。 证书的安全：一旦CA验证了公钥拥有者的身份，CA将为这个拥有者生成一个证书，证书一定不能被修改，这是由单向哈希值和数字签名算法保证的。 预加载的可信证书的验证：证书的完整性是由CA的签名保护的，为了验证这个签名，需要CA的公钥，这个公钥要么被客户端预加载，要么由另一个CA的签名保护，只有可信的公钥才会被预加载。 用户确认：客户端需要确认证书中的Subject域与用户想访问的目的地一致。 对CA认证过程的攻击 CA的作用是确认公钥属于一个特定的主体，它的工作分为两部分：1.验证证书申请者与证书Subject域中主体之间的关系。2. 对证书做签名。 如果CA在主体认证上没有做好工作，或者验证过程不安全，攻击者就能够获得一个伪造的证书，证书中存放的是攻击者的公钥，但Subject域缺失攻击目标的域名，有个这个假证书，攻击者可以针对目标网站实施中间人攻击。 对签名过程的攻击 一旦CA验证了证书请求的Subject域，它会用私钥签发证书，如果CA的私钥被泄漏，攻击者可以签发一个Subject域为任意数据的证书，这会生成有效但虚假的证书。 CA的私钥不应该暴露出来，大部分CA把私钥存在特殊硬件设备中，这些设备是防篡改的，而且需要物理接触才能得到密钥，它一般存储在受着严密监视和保护的地方。 对算法的攻击 数字证书依赖域两种类型的算法：单向哈希函数和数字签名。证书的签名实际上是对证书的单向哈希值进行签名，一个好的单向哈希函数应该有两个属性：单向属性和抗碰撞属性。抗碰撞属性确保很难找到两个内容不同但有相同哈希值的消息。 抗碰撞性弱的算法，攻击者可以准备两个版本的证书请求，版本A的Subject域存放example.com，版本B的Subject域存放attacker32.com，这两个证书虽然内容不同，但可以生成相同的哈希值，因为攻击者不拥有example.com，所以如果攻击者给CA发送版本A，CA将不会签署该请求，但是如果攻击者发送版本B，CA会签署该请求，因为签署用的只是哈希值，再版本B上签名其实也是在版本A上签名 当CA在给证书签名时，CA可以增加一些不可预测的数据，例如序列号，使得攻击者不大可能实现准备两个内容不同但哈希值相同的证书。 对用户确认的攻击 在验证服务的证书后，客户端能够确信证书是有效的并且证书的名称是认证过的，但是客户端不知道该实体是否是用户想要交互的对象。因此这里需要一个用户确认的过程。 域名验证型证书 对于DV证书来说，CA验证域名记录以核对域名是否属于申请者，这个过程一般称为域控制验证（DCV），是通过WHOIS（一个在线存储域名注册信息的资料库）中获取的信息来验证包含证书请求中的域名。 DCV一般使用下列方法：
通过电子邮件：CA首先获取证书请求中域名注册的邮箱，然后发送一封邮件给这个邮箱，这封邮件包含一个链接，如果它被点击，域名验证就通过了，即CA相信申请者的确拥有该域名。 通过HTTP：在这个方法中，CA把证书请求的哈希值发给申请者，申请者应该创建一个以哈希值命名的文件，并把该文件放在请求域名的网络服务器中。 通过DNS：在这个方法中，CA把证书请求的哈希值发给申请者，申请者需要在请求域名的DNS服务器中增加一条CNAME记录，CNAME记录的值就是该哈希值。 机构验证型证书 出了验证域名外，还需要验证：
域名控制验证 申请者的身份和地址 申请者和机构的关系 机构的地址 机构的WHOIS的记录 机构的电话号码 拓展验证型证书 需要验证：
域名控制验证 验证证书请求中涉及的身份、机构、签名以及和申请者直接的关系 验证组织的物理地址和电话号码 验证组织实际业务的存在性，确保机构知道申请日期还在开展业务 验证机构合法性，确保机构过去没有非法或不良记录。 浏览器通常维护一个单独的、可以验证EV证书的列表，一个CA想要称为EV-compliant列表的一部分，他必须要遵循所有标准，对它的基础设施实行严格的安全保护，而且需要第三方审计向浏览器供应商证明它的安全性。
3504
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
