Ich habe einKette.pem
-----BEGIN CERTIFICATE-----
// My server cert signed by intemediate CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
// My intermediate cert signed by root CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
// My self signed root cert
-----END CERTIFICATE-----
sowie einserver.key.pem
-----BEGIN RSA PRIVATE KEY-----
// Private key for server cert
-----END RSA PRIVATE KEY-----
Als nächstes hoste ich einen Server, der die Kette mit dem privaten Schlüssel des Blattzertifikats bedient
openssl s_server -accept 1443 -cert chain.pem -key server.key.pem
Aber wenn ich versuche, die Kette von OpenSSL aus zu überprüfen, schlägt dies fehl
openssl s_client -connect 127.0.0.1:1443 -CAfile ca.cert.pem
CONNECTED(00000005)
depth=0 CN = SERVER
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = SERVER
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:CN = SERVER
i:CN = Intermediate
---
Server certificate
-----BEGIN CERTIFICATE-----
// My self signed root cert
-----END CERTIFICATE-----
subject=CN = SERVER
issuer=CN = Intermediate
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1445 bytes and written 391 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 96CDD51B8E373535061D0338B6F748A77C5EB08DDCF3BDE07B56B2B9A4C93D55
Session-ID-ctx:
Resumption PSK: AC94F87D8723F065E7F0C7379CB090CD4987ECCD1B799ED0218855888015C0E077595450F87421CC7B4DF334165A2581
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - fa bf fa df 9a 14 c9 f9-84 03 f5 ea ea 4b c9 36 .............K.6
0010 - 5a dc df 25 b2 73 9e 51-31 95 33 75 c6 cb 8e 00 Z..%.s.Q1.3u....
0020 - 96 52 aa 6a 90 1d f3 ba-c4 ef c1 e8 e1 c2 91 9b .R.j............
0030 - e2 50 d8 a1 4e 54 95 fa-e8 39 8b 5c 08 8a c0 22 .P..NT...9.\..."
0040 - 98 d3 21 3e 9f d7 2b b8-9c 5a a3 e1 5a d3 1b 43 ..!>..+..Z..Z..C
0050 - fa f0 f1 0a 3d 9b 68 1c-04 d6 0e 6e 29 da ea f6 ....=.h....n)...
0060 - ba a0 7d c4 c0 cb d6 ab-b5 63 fe 96 a3 75 0a 81 ..}......c...u..
0070 - b9 88 05 f2 fe 92 0f 8d-05 9e d1 ea cb e7 da ba ................
0080 - b1 61 08 30 bd 92 6b 92-e7 5d 61 33 db cc a9 21 .a.0..k..]a3...!
0090 - e9 a9 b3 86 59 39 13 8b-07 1c d8 9a a0 d1 0c 1e ....Y9..........
00a0 - 02 55 2a 5c 1b 18 a8 d0-77 d8 a2 a8 cc b0 14 16 .U*\....w.......
00b0 - c7 a6 42 9b 16 bf 2d 37-fa b3 df 23 f6 c5 21 c6 ..B...-7...#..!.
00c0 - 44 7a c5 fb f1 60 26 f6-36 2d 52 9d 19 e9 cb e6 Dz...`&.6-R.....
Start Time: 1566570240
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: D6B1480A83B746E076B63E2164F60A2803E03020F766555B77D328D481BA3F30
Session-ID-ctx:
Resumption PSK: C2422E09D6BBB9FDEC99A61E3CB80D662D8437B2F0FFACDC079D75BC8B65E1E9739D473D0959938CBDB926258ADCF4C7
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - fa bf fa df 9a 14 c9 f9-84 03 f5 ea ea 4b c9 36 .............K.6
0010 - 87 ac dc 50 d8 d8 62 65-5b 36 e8 de 9e 95 f0 97 ...P..be[6......
0020 - 9f b6 00 96 a4 fb d0 74-45 6c ef 25 b2 ab aa 18 .......tEl.%....
0030 - b4 2c 8a c8 3d 7f 2b 79-ae da de 61 3f 48 fb 71 .,..=.+y...a?H.q
0040 - 9e 4d c1 82 14 0e 7f 47-60 76 ff 83 7e 67 0a 25 .M.....G`v..~g.%
0050 - 5d 17 74 a3 8b e7 31 54-62 58 40 70 a3 51 fb d0 ][email protected]..
0060 - 97 de a2 7a 7c 68 d2 c8-69 60 29 f5 90 cb be 51 ...z|h..i`)....Q
0070 - 6c d6 c1 54 e2 68 bb 43-4c b4 1f 7d 9c 5c d7 34 l..T.h.CL..}.\.4
0080 - ae b4 ce 20 3d 69 cf dc-80 1f 10 b9 6c 9e ff f5 ... =i......l...
0090 - 00 80 05 6f ee 2f 7b c0-aa 8c c4 8c 3f 30 3c d3 ...o./{.....?0<.
00a0 - 0e 37 ec db 4b 69 20 63-12 05 dd 03 86 2a 22 26 .7..Ki c.....*"&
00b0 - 68 7b 0f f3 18 f0 20 35-0b fb 04 f4 3e 03 e3 2c h{.... 5....>..,
Start Time: 1566570240
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
Es scheint nicht so, als ob es das Zwischen- oder Stammzertifikat vorlegt, damit es die Kette überprüfen kann. Was übersehe ich hier?
In meinem Szenario würde der Client dem öffentlichen Schlüssel des Stammzertifikats vertrauen. Ich verstehe vielleicht einige Konzepte falsch, ich bin neu auf diesem Gebiet.
Antwort1
Das -cert cert.pemArgument von openssl s_serverwird verwendet, um dienur Blattzertifikat. Wenn Sie stattdessen mehrere Zertifikate angeben, wird (normalerweise?) das erste verwendet. Wenn Sie Kettenzertifikate haben, müssen Sie diese -cert_chain chain.pemstattdessen mit der Option angeben.
Beachten Sie, dass der Server die Stammzertifizierungsstelle überhaupt nicht bereitstellen sollte. Diese Zertifizierungsstelle muss sich stattdessen im Vertrauensspeicher des Clients befinden, d. h. Sie müssen sie stattdessen bereitstellen, -CAfile ca.cert.pemwie openssl s_clientSie es bereits tun. Wenn das Stammzertifikat auch vom Server bereitgestellt wird, wird es einfach ignoriert, da der Vertrauensanker lokal beim Client vorhanden sein muss.