0

I have a chain.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-----

as well as a server.key.pem

-----BEGIN RSA PRIVATE KEY-----
// Private key for server cert
-----END RSA PRIVATE KEY-----

Next I host a server serving the chain with the leaf cert's private key

openssl s_server -accept 1443 -cert chain.pem -key server.key.pem

But when I try to check the chain from openssl, it fails

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   ].t...1TbX@p.Q..
    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

I doesn't seem as though it is presenting the intermediate or the root certificate so that it can verify the chain. What am I missing here?

In my scenario, the client would have the root certificate public key trusted. I might be misunderstanding a bunch of concepts, I am new to this.

migrated from security.stackexchange.com Aug 26 at 19:39

This question came from our site for information security professionals.

  • 1
    This seems to be related to the order of certificates in the chain. While host, then intermediate, then root seems fine, it could be that your actual file looks different. However, this seems only tangentially related to security, and I'm sure the fine folks over at Super User will most likely be of more help. – MechMK1 Aug 23 at 14:36
  • I don't see the intermediate cert being passed, only referenced. Add -showcerts to your command line to see exactly which certificates the server is passing along. – gowenfawr Aug 23 at 14:46
3

The -cert cert.pem argument of openssl s_server is used to give the leaf certificate only. If you provide multiple certificates instead it will (usually?) take the first one. If you have chain certificates you have to provide these using the -cert_chain chain.pem option instead.

Note that the server should not provide the root CA at all. This CA has to be in the clients trust store instead, i.e. you need to provide it with -CAfile ca.cert.pem in openssl s_client instead as you already do. If the root certificate is also provided by the server it will be simply ignored since the trust anchor must be local to the client.

  • 1
    Only 1.1.0 up; earlier you had to 'fake' s_server by giving it a truststore (-CAfile and/or -CApath) which even with no client cert to validate was undocumentedly used to build out its own chain(!). – dave_thompson_085 Aug 24 at 6:03
  • @dave_thompson_085: Kind of. According to the source code of OpenSSL the option was there since 1.0.2 (and it worked there) but did not show up in -help until 1.1.0 and did not show up in the man page for s_server until 1.1.1. Quality products ... – Steffen Ullrich Aug 24 at 6:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.