OpenSsl and self-signed certificates - verifying a chain

Question

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   ][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

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.

Answer 1

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.