Leshan server demo DTLS x.509 mode

[mehdi-chelouah]

I'm currently working on an IoT Project with NRF9160 MCU. It works fine with no security mode and PSK mode. Now, i would like to add x509 security but i'm completely lost. I don't know what i have to do with the certificate provided by the server at der format. When I provide a self signed certificate to the NRF9160, i get a "Connection refused".

I'd like to know what

If you want to connect a client using DTLS with certificate(x509) mode, your client need to trust this certificate to accept DTLS connection with this server.

means exactly.

Thanks

[sbernard31]

Could you say us what are you using as LWM2M server and what are you using as LWM2M client ?

[boaks]

stackoverflow.

I just not longer common to the intended credentials management of the leshan demo server. I guess, there is a Wiki page or other instructions, how to create a client certificate.

nRF9160 is usually using a zephyr lwm2m client or the one from the modem itself. How certificates are handled for that modem, is then more a question to the manufacturer or the zephyr project.

[sbernard31]

Could you also precise which version of LWM2M 1.0 or 1.1 ?

I just not longer common to the intended credentials management of the leshan demo server. I guess, there is a Wiki page or other instructions, how to create a client certificate.

https://github.com/eclipse/leshan/wiki/Credential-files-format

[mehdi-chelouah]

Could you say us what are you using as LWM2M server and what are you using as LWM2M client ?

I'm using a leshan demo server hosted by OVH, my LWM2M client is a Zephyr lwm2m client project. I added self signed certificate with CN=Client_NAME but it didn't work as expected as i get a "Connection refused by the leshan server"

[sbernard31]

Which version of LWM2M ? which version of Leshan ?

[mehdi-chelouah]

Which version of LWM2M ? which version of Leshan ?

2.0.0-SNAPSHOT

[sbernard31]

OK so we still don't know which LWM2M version is used at client side
and 2.0.0-SNAPSHOT does not really helps, it could be anything since we start to work on 2.0.0 like 2 years ago , anyway I give up to try to get this simple information.

For current 2.0.0-SNAPSHOT (corresponding to master), to use x509 you need to add a security info to let Leshan know that your device with endpoint name "Client_NAME" must connect using x509. For leshan-server-demo, you can do that using the UI => Security Tab.

By default leshan-server-demo, trust any certificate, see -ts option :

X509 Options

By default Leshan demo uses an embedded self-signed certificate and trusts any 
client certificates allowing to use RPK or X509 at client side.
To use X509 with your own server key, certificate and truststore : 
     [-xcert, -xprik], [-truststore] should be used together.
To get helps about files format and how to generate it, see : 
See https://github.com/eclipse/leshan/wiki/Credential-files-format

      -xcert, --x509-certificate-chain=<certChain>
                        The path to your server certificate or certificate
                          chain file.
                        The certificate Common Name (CN) should generally be
                          equal to the server hostname.
                        The certificate should be in X509v3 format (DER or PEM
                          encoding).
                        The certificate chain should be in X509v3 format (PEM
                          encoding).
      -xprik, --x509-private-key=<prik>
                        The path to your server private key file
                        The private key should be in PKCS#8 format (DER
                          encoding).
      -ts, --truststore=<truststore>
                        The path to  :
                         - a root certificate file to trust,
                         - OR a folder containing trusted certificates,
                         - OR trust store URI.

                        Certificates must be in in X509v3 format (DER encoding)

                        URI format:
                          file://<path-to-store>#<password>#<alias-pattern>
                        Where :
                        - path-to-store is path to pkcs12 trust store file
                        - password is HEX formatted password for store
                        - alias-pattern can be used to filter trusted
                          certificates and can also be empty to get all

                        Default: trust all certificates (only OK for demos).

Client certificate must respect some basic rules :

• its CN must be equal to client endpoint name
• we are using default StaticNewAdvancedCertificateVerifier (from californium by default) and so Certificate should respect basic x509 rules (e.g. if key usage or extended key usage is used it must allow client authentication).

Maybe you can share your client certificate and we will see if there is something wrong ?
Do you try to first make it works with leshan-client-demo ?

[mehdi-chelouah]

https://drive.google.com/uc?export=download&id=1ECVYlSx0Fao4WCvQG1iyj1RkJEH9f5Ld

[sbernard31]

At first sight, I see nothing wrong with your certiticate :

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            31:4e:d1:28:c5:e0:f7:7e:ce:5d:e1:2e:73:36:aa:dd:7d:96:7c:9a
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = IRIS_A
        Validity
            Not Before: Mar 25 12:41:04 2022 GMT
            Not After : Mar  1 12:41:04 2122 GMT
        Subject: CN = IRIS_A
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:cc:3e:1e:a8:de:fb:66:6c:3d:44:3f:53:5c:c0:
                    83:b1:f2:b4:d5:a4:f8:96:99:52:29:bb:4d:c6:7a:
                    8b:21:d8:62:d5:5b:1b:ad:cd:7b:e9:f7:f4:65:48:
                    d8:35:c1:ba:51:36:02:a5:66:9c:65:7c:4f:4c:bf:
                    0c:0e:78:bc:02
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                5A:8B:1F:22:97:39:53:7A:BF:8D:04:C1:E2:46:4E:24:32:67:27:B5
            X509v3 Authority Key Identifier: 
                keyid:5A:8B:1F:22:97:39:53:7A:BF:8D:04:C1:E2:46:4E:24:32:67:27:B5

            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:3f:97:b0:e2:98:65:fc:5a:c6:63:e0:fe:0b:49:
         b5:0e:89:1f:10:46:44:57:60:55:e3:b7:c6:94:f1:57:26:f1:
         02:20:7c:14:94:c6:fc:e8:c8:e5:59:1c:11:b0:d7:7e:bc:c9:
         d0:01:e0:7c:1b:d3:42:08:30:9e:8b:5f:84:ce:c4:3c

I tried to connect to https://leshan.eclipseprojects.io using leshan-client-demo with a very similar certificate :

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            5a:a7:75:35:9b:06:62:95:fe:80:a9:43:9c:64:35:20:fd:52:c5:bc
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = FR, ST = Some-State, O = Internet Widgits Pty Ltd, CN = mooky-x509
        Validity
            Not Before: May  5 15:07:17 2020 GMT
            Not After : Apr 11 15:07:17 2120 GMT
        Subject: C = FR, ST = Some-State, O = Internet Widgits Pty Ltd, CN = mooky-x509
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:0d:58:81:85:a0:8d:60:e9:d9:01:c2:86:b3:11:
                    7d:66:2b:2f:b8:9d:ad:70:be:7d:37:84:0e:45:02:
                    72:8d:01:e7:5c:65:f4:6d:f6:41:2c:5f:60:50:21:
                    04:58:05:b3:54:55:0d:96:64:95:22:cc:7c:c6:a3:
                    ee:e5:58:ee:ca
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                0D:0C:FF:DA:BC:AC:B0:11:94:DF:2B:CC:2E:A2:EC:AD:9E:F5:D5:B4
            X509v3 Authority Key Identifier: 
                keyid:0D:0C:FF:DA:BC:AC:B0:11:94:DF:2B:CC:2E:A2:EC:AD:9E:F5:D5:B4

            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:21:00:d0:a8:c7:b2:6a:2d:9c:98:4f:09:f6:34:1d:
         3a:4e:f1:e8:01:b1:75:79:cc:a6:51:76:46:60:70:22:ae:d0:
         f8:02:20:62:aa:d2:aa:8c:9d:a0:7a:39:cb:c0:90:11:74:6a:
         97:09:2b:ae:dd:5f:bb:ca:ac:12:d9:aa:0c:2e:93:71:ca

and it works for me.

Do you succeed to make it work with leshan-client-demo ?

[mmazu]

Hi,
I'm not sure should I join to this issue or start new one but problem is same though root of cause maybe other.

I wrote own lwm2m client and test it with your leshan.eclipseprojects.io with no problems (noSec, psk, x509).
Than I build your demo from commit 55ee6b2 (HEAD -> master, origin/master, origin/HEAD) and run java -jar leshan-server-demo/target/leshan-server-demo-*-SNAPSHOT-jar-with-dependencies.jar -vvv

It works fine for noSec, psk but not with x509.
I try x509 with leshan-client-demo and your leshan-server-demo and it also doesn't work, from same build.

From log I see it finished with
2022-03-30 07:27:24,520 DTLSConnector [TRACE] Processing FATAL ALERT from [172.31.0.164:52442]: BAD_CERTIFICATE

I wonder about
2022-03-30 07:27:24,132 CipherSuite [TRACE] Cannot resolve cipher suite code [a3] etc....

Could you please advice what could be a reason that it works with your leshan.eclipseprojects.io and it doesn't with build one.

I swap server certificate respectively.

I am running it on Linux yocto-ubuntu-18 5.4.0-105-generic #119~18.04.1-Ubuntu SMP Tue Mar 8 11:21:24 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
and java -version
openjdk version "11.0.14" 2022-01-18
OpenJDK Runtime Environment (build 11.0.14+9-Ubuntu-0ubuntu2.18.04)
OpenJDK 64-Bit Server VM (build 11.0.14+9-Ubuntu-0ubuntu2.18.04, mixed mode, sharing)

Regards
Marek,
leshanServerLog.txt

Logs included.

[boaks]

I wonder about
2022-03-30 07:27:24,132 CipherSuite [TRACE] Cannot resolve cipher suite code [a3] etc....

And you use which dtls implementation on the client-side? openssl?
According your log, you use Californium on the server-side, and that supports currently only this cipher suites. The DTLS handshake is commonly used to negotiate a "common set" of cryptographic parameters, including the cipher suite. If the client propose cipher suites unknown to the server, that doesn't harm too much, as long as there is a common set. You waste you bandwidth, but that's your decision, either to dig into configure your dtls-library or not.

From your log:

provided cookie must 343E26254CEB match 0FD89E8DE6E3

That's strange, maybe you can provide a capture of your client side?

(I guess, your device sends not only DTLS records ...)

Anyway,

Processing FATAL ALERT from [172.31.0.164:52442]: BAD_CERTIFICATE

indicates, that you client doesn't accept your "self-signed" certificate. You may check your client's truststore, if that self-signed is trusted at all. or you need to debug your client, in order to see, why your certificate is BAD for your client.

[mmazu]

Thanks for tips,
Looks like they guide me to solution, I will confirm after tests.
Regards
Marek

[sbernard31]

@mehdi-chelouah did you finally succeed ? should we close this issue ?

[mehdi-chelouah]

You can close the issue, thanks again for your help ! @sbernard31

[sbernard31]

No problem 😉