DTLS Client Certificate Chain not sent

Currently we are implementing client/server DTLS communication with Leshan for an IoT project. Unfortunately, the handshake fails because the Leshan client just sends a single certificate to the Leshan Server (recorded with Wireshark) instead of the whole chain (Root CA -> Intermediate CA -> Client Cert):

13:44:43.387 [DTLS-Retransmit-Task-1] DEBUG org.eclipse.californium.scandium.dtls.CertificateMessage - created CERTIFICATE message with certificate chain [length: 1]

The server’s certificate message contains the expected chain, so there is no problem with the LeshanServerBuilder.

We definitely set the chain in the DTLS client config:

private val builder: LeshanClientBuilder = LeshanClientBuilder("1122334455667788990")
val leshanClient: LeshanClient
// ...

val dtlsConfig = DtlsConnectorConfig.Builder()
dtlsConfig.setIdentity(
            clientPrivateKey,
            arrayOf(
                clientCert,
                intermediateCAcert,
                rootCAcert
            )
)
builder.setDtlsConfig(dtlsConfig)

// ...
leshanClient = builder.build()
leshanClient.start()

In the createEndpoint(ServerInfo serverInfo) method of CaliforniumEndpointsManager I noticed the following:

newBuilder.setIdentity(serverInfo.privateKey, new Certificate[] { serverInfo.clientCertificate }); is called. This call overwrites the chain of certificates. So a single certificate (the client certificate) is written to the DTLS config, instead of the whole certificate chain. After that createSecuredEndpoint is called with an invalid certificate chain based on the DTLS config builder, called newBuilder.

Is this a bug or should I check other parameters of my LeshanClient?

[sbernard31]

Only the client certificate chain is not clear in LWM2M specification. For server, I don’t see any issue. 🙂

[sbernard31]

Following https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/502#issuecomment-763698433, the lwm2m specification clarify that client certificate chain is limited to only 1 certificate. At least this is my understanding. 😕

I close this issue, but it could be related in a way to #1135…