我试图理解使用ECDSA密钥基础上的证书,即。(由CA使用RSA密钥签名)。例如,当您连接到www.facebook.com时
$ openssl s_client -connect www.facebook.com:443
您将得到用作ECDHE-ECDSA- as 128-GCM- the 256的密码套件。这意味着它使用了ECDSA密钥进行服务器身份验证。但是,如果您在这里查看服务器证书,您将看到签名算法: sha256WithRSAEncryption,这意味着它是使用RSA密钥签名的。
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0c:1b:54:74:2f:1c:31:a6:c7:90:2f:1b:65:86:a7:e1
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
Validity
Not Before: Jun 4 00:00:00 2022 GMT
Not After : Sep 2 23:59:59 2022 GMT
Subject: C=US, ST=California, L=Menlo Park, O=Facebook, Inc., CN=*.facebook.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:24:c8:04:40:24:b1:2b:4f:20:b6:a3:32:b3:94:
d5:72:84:bc:3d:50:e0:d4:92:78:fd:7e:f5:96:08:
83:a5:aa:a5:e2:79:7d:ea:19:85:92:d6:e2:0e:ea:
b8:71:12:d9:ed:4b:6c:a9:ed:d5:14:a8:dd:d0:4b:
fa:8d:4a:58:35
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:51:68:FF:90:AF:02:07:75:3C:CC:D9:65:64:62:A2:12:B8:59:72:3B
X509v3 Subject Key Identifier:
3B:D9:84:5E:21:B3:62:D1:BC:0B:EB:8A:32:89:6C:F0:28:3A:50:0A
X509v3 Subject Alternative Name:
DNS:*.facebook.com, DNS:*.facebook.net, DNS:*.fbcdn.net, DNS:*.fbsbx.com, DNS:*.m.facebook.com, DNS:*.messenger.com, DNS:*.xx.fbcdn.net, DNS:*.xy.fbcdn.net, DNS:*.xz.fbcdn.net, DNS:facebook.com, DNS:messenger.com
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/sha2-ha-server-g6.crl
Full Name:
URI:http://crl4.digicert.com/sha2-ha-server-g6.crl
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.2
CPS: http://www.digicert.com/CPS
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt
X509v3 Basic Constraints:
CA:FALSE
1.3.6.1.4.1.11129.2.4.2:
...l.j.w.)y...99!.Vs.c.w..W}.`
..M]&\%]......,X.......H0F.!..6m.#.u.kE.g.......S.#.!...4..h..!..Ca..B{.=f.v.W9=..j%..........b>.v.A...."FJ...:.B.^N1.....K.h..b.......,X.......G0E. ..SWQ_o..Ov....<*.....X"......le.!....~l...@[.}.E.........!<.......b,(w.J.>A....0.q.!..i..aA.M.u1XZ..,~.....*H)..~fg...!..
Signature Algorithm: sha256WithRSAEncryption
ab:5b:e0:a0:43:b5:15:26:fa:7d:b3:03:14:54:5c:6b:b4:fd:
c4:6e:35:8d:8d:1a:5c:80:09:af:48:a0:4f:cc:ef:ff:e8:c2:
c9:3d:59:a9:95:03:6c:3d:78:04:35:e8:c7:55:5e:ae:16:5a:
d6:90:3b:23:bc:25:49:7d:a6:3c:10:1d:17:2f:00:c4:07:3b:
59:15:9c:88:5c:1d:8d:8a:83:30:6a:e2:bc:99:13:3f:8b:9f:
f8:a2:99:71:ea:97:b7:fb:48:48:79:8b:e8:23:c5:c5:fc:55:
d0:8e:85:ed:95:07:af:b0:51:1e:0a:c9:0c:40:7e:fa:c6:86:
b7:30:2b:02:2c:5d:db:ba:07:73:2b:b0:95:cb:86:46:a6:60:
d7:be:10:85:55:77:ca:e9:97:84:d2:dc:00:d6:7b:97:90:06:
50:40:09:aa:68:9d:c2:29:b0:db:00:c9:1b:e4:18:06:04:cf:
38:de:dc:05:b7:b4:67:ed:15:ae:c7:b8:b0:4a:6c:12:6f:f8:
ec:6a:d9:69:57:0f:f7:99:b2:05:14:35:5c:95:f8:f9:02:0f:
ae:48:7d:5a:91:16:cd:1a:fd:a8:63:b7:97:4f:31:4d:dd:ff:
f1:b3:ea:79:32:18:44:fc:a7:37:3e:65:a3:15:4e:d4:30:39:
d3:d7:ee:83
因此,客户端必须使用CA的RSA (公共)密钥验证sha256摘要。但是为什么密码套件仍然说ECDSA在这里被使用呢?ECDSA是用来做什么的?有人能澄清吗?
发布于 2022-08-28 20:49:45
实际上,在ServerKeyExchange消息中,参数是用服务器的私钥(这里是ECDSA密钥)签名的,并且可以使用服务器的公钥进行验证。因此,这似乎是真正使用服务器的ECDSA私钥,而不是任何对称密钥派生。
发布于 2022-08-26 02:57:07
公钥确实是ECDSA,但是签名证书的ca使用RSA密钥对其进行签名。这只是表示它可以被信任的签名。这与实际签署的密钥无关。您仍然在使用ECDSA进行实际加密。
因此,澄清:
这里使用ECDSA进行公钥加密。在大多数情况下,公钥加密速度太慢,无法达到实际目的,比如使用SSL/TLS的web服务器加密。在这种情况下,web服务器和客户端使用公钥安全地传递一个更有效的对称密钥。因此,对称密钥是使用ECDSA公钥加密的。
严格地说,对称密钥可以安全地在客户端和服务器之间传递,而无需验证公钥上的签名。加密是有效和安全的。
但是,如果没有签名的公钥,就不可能信任公钥属于它所声明的服务器/组织。一般来说,信任链。证书本质上是由私钥签名的公钥。签名意味着允许您信任密钥。
CA被创建为执行公钥签名的可信第三方。签名与正在签名的实际密钥类型或密钥将使用的加密算法无关。这只是一个签名的信任(希望)第三方。第三方使用的密钥类型将决定签名的算法和类型。
希望这样更清楚。
https://stackoverflow.com/questions/73494643
复制