Is it possible to deliver a chain certificate in the SSL handshake?

[jcorporation]

• In my local setup I use a Root CA certificate that is trusted by all my local clients.
• This certificate signs only other intermediate CA certificates.
• This intermediate CA certificates signs server certificates.

For struct mg_tls_opts I can only declare a server certificate and no chain certificate(s). I tried to append the Intermediate CA certificate to the server certificate, but Mongoose only delivers the server certificate and not the intermediate. I checked this with the openssl s_client command.

In other webserver implementation it is possible to add a separate chain file or/and append the intermediate to the server certificate.

I use the OpenSSL backend. Is this a bug or simply not implemented? If not implemented do you consider to implement this feature? I think it is a very common setup and best practice for CA's.

[scaprile]

Hi Jürgen,
in my understanding, you should add your intermediate certificate to the CA chain, not the server chain.
Let me know, and we'll see how to follow.

[jcorporation]

I think it is exactly the opposite. Clients have only the Root CA certificates in there trusts stores and the server is responsible to deliver the chain of trust from the certificate to the Root CA certificate with all intermediate certificates.

For example yout mongoose.ws site does this:

openssl s_client -connect mongoose.ws:443 -showcerts
Connecting to 176.9.217.245
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E8
verify return:1
depth=0 CN=mongoose.ws
verify return:1
---
Certificate chain
 0 s:CN=mongoose.ws
   i:C=US, O=Let's Encrypt, CN=E8
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Oct 26 08:10:17 2025 GMT; NotAfter: Jan 24 08:10:16 2026 GMT
-----BEGIN CERTIFICATE-----
MIIDrDCCAzGgAwIBAgISBdj17YuiWeSWcgvqDvULDxRTMAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
ODAeFw0yNTEwMjYwODEwMTdaFw0yNjAxMjQwODEwMTZaMBYxFDASBgNVBAMTC21v
bmdvb3NlLndzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEszLfci8Fib/q1+WL
nm2jmud+RP4PJ51Qeej+2cpa/H0WTATyy+1YWysv1bkJICkzDlN5eWgSwFpA2Ebj
eMFXyKOCAkEwggI9MA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAUBggrBgEFBQcD
AQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUA2BkM12wSubz9IsC
5qpUOutAhJYwHwYDVR0jBBgwFoAUjw0TovYuftFQbDMYOF1ZjiNykcowMgYIKwYB
BQUHAQEEJjAkMCIGCCsGAQUFBzAChhZodHRwOi8vZTguaS5sZW5jci5vcmcvMD4G
A1UdEQQ3MDWCFWRhc2hib2FyZC5tb25nb29zZS53c4ILbW9uZ29vc2Uud3OCD3d3
dy5tb25nb29zZS53czATBgNVHSAEDDAKMAgGBmeBDAECATAtBgNVHR8EJjAkMCKg
IKAehhxodHRwOi8vZTguYy5sZW5jci5vcmcvODQuY3JsMIIBBAYKKwYBBAHWeQIE
AgSB9QSB8gDwAHYAGYbUxyiqb/66A294Kk0BkarOLXIxD67OXXBBLSVMx9QAAAGa
H8cCjQAABAMARzBFAiBqofSyA5AGSLxqp/KKUw0L3YDJ/VUfrXwZXrWxGB+KDgIh
APQlyEfZdU5goi3RbTRWVmH3e41pbrWhGMVowWerCVkpAHYAlpdkv1VYl633Q4do
NwhCd+nwOtX2pPM2bkakPw/KqcYAAAGaH8cCwgAABAMARzBFAiBJumtP3Kw9+r+x
luReSCABS70L3ftWSaGjTlYip4EsnQIhAM+GO6SSbGAgmQxcadJa99qT7CkDwzup
WtxslNRCO6D+MAoGCCqGSM49BAMDA2kAMGYCMQCSFM7O6+envItJQF1rjOKcKbBu
UuGAUoTXTBdIt2NpLP3GNKGqPmkvBEktkwG+MAsCMQC7WJS4VcsnzH36dl6MlP4L
GoOBUcilb5Ulb6roFeG1iRkfGIshrasd6P+AmZBscas=
-----END CERTIFICATE-----
 1 s:C=US, O=Let's Encrypt, CN=E8
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: EC, (secp384r1); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
-----BEGIN CERTIFICATE-----
MIIEVjCCAj6gAwIBAgIQY5WTY8JOcIJxWRi/w9ftVjANBgkqhkiG9w0BAQsFADBP
MQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJuZXQgU2VjdXJpdHkgUmVzZWFy
Y2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBYMTAeFw0yNDAzMTMwMDAwMDBa
Fw0yNzAzMTIyMzU5NTlaMDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBF
bmNyeXB0MQswCQYDVQQDEwJFODB2MBAGByqGSM49AgEGBSuBBAAiA2IABNFl8l7c
S7QMApzSsvru6WyrOq44ofTUOTIzxULUzDMMNMchIJBwXOhiLxxxs0LXeb5GDcHb
R6EToMffgSZjO9SNHfY9gjMy9vQr5/WWOrQTZxh7az6NSNnq3u2ubT6HTKOB+DCB
9TAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMB
MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFI8NE6L2Ln7RUGwzGDhdWY4j
cpHKMB8GA1UdIwQYMBaAFHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEB
BCYwJDAiBggrBgEFBQcwAoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzATBgNVHSAE
DDAKMAgGBmeBDAECATAnBgNVHR8EIDAeMBygGqAYhhZodHRwOi8veDEuYy5sZW5j
ci5vcmcvMA0GCSqGSIb3DQEBCwUAA4ICAQBnE0hGINKsCYWi0Xx1ygxD5qihEjZ0
RI3tTZz1wuATH3ZwYPIp97kWEayanD1j0cDhIYzy4CkDo2jB8D5t0a6zZWzlr98d
AQFNh8uKJkIHdLShy+nUyeZxc5bNeMp1Lu0gSzE4McqfmNMvIpeiwWSYO9w82Ob8
otvXcO2JUYi3svHIWRm3+707DUbL51XMcY2iZdlCq4Wa9nbuk3WTU4gr6LY8MzVA
aDQG2+4U3eJ6qUF10bBnR1uuVyDYs9RhrwucRVnfuDj29CMLTsplM5f5wSV5hUpm
Uwp/vV7M4w4aGunt74koX71n4EdagCsL/Yk5+mAQU0+tue0JOfAV/R6t1k+Xk9s2
HMQFeoxppfzAVC04FdG9M+AC2JWxmFSt6BCuh3CEey3fE52Qrj9YM75rtvIjsm/1
Hl+u//Wqxnu1ZQ4jpa+VpuZiGOlWrqSP9eogdOhCGisnyewWJwRQOqK16wiGyZeR
xs/Bekw65vwSIaVkBruPiTfMOo0Zh4gVa8/qJgMbJbyrwwG97z/PRgmLKCDl8z3d
tA0Z7qq7fta0Gl24uyuB05dqI5J1LvAzKuWdIjT1tP8qCoxSE/xpix8hX2dt3h+/
jujUgFPFZ0EVZ0xSyBNRF3MboGZnYXFUxpNjTWPKpagDHJQmqrAcDmWJnMsFY3jS
u1igv3OefnWjSQ==
-----END CERTIFICATE-----
---
Server certificate
subject=CN=mongoose.ws
issuer=C=US, O=Let's Encrypt, CN=E8
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ecdsa_secp256r1_sha256
Peer Temp Key: X25519, 253 bits
---
SSL handshake has read 2437 bytes and written 1633 bytes
Verification: OK
---

[scaprile]

Well, my suggestion was based on the hope that the client would get one and then the other, out of the CA chain... AFAIK we currently do not send more than one server or client cert (but I have to check, we support four different TLS libraries) and it was more likely that the whole CA chain was sent.
If my suggestion does not help, then we can mark this as a TODO()

[jcorporation]

It would be great if mongoose support sending a chain. This will improve compatibility and such a chain is very common and considered as best practice.

Importing the intermediate certificate is not a good solution, as they are rotatet more frequent than the root ca.