ISRG Root X1 certificate fails to parse

[jeremyherbert]

Hi,

I have a root certificate that is used by the popular TLS certificate service Let's Encrypt that fails to parse in NCS 2.6.0 on the nrf9160dk. You can find the certificate here: https://letsencrypt.org/certs/isrgrootx1.pem.txt (I also exported this certificate from my browser, and it matches exactly).

To test this, I started with the https_client example (which works fine) and made the following changes:

1. Added the certificate to the certs folder
2. Updated the CMakeLists.txt file to generate the inc file for the new certificate instead of the example one
3. Changed the HTTPS_HOSTNAME define in main.c to "letsencrypt.org"

The build is happening through vscode, but the build command it reports is (I am adding both .conf overlays): 

west build --build-dir /home/jeremy/Desktop/https_client_isrg/build_1 /home/jeremy/Desktop/https_client_isrg --pristine --board nrf9160dk_nrf9160_ns --no-sysbuild -- -DNCS_TOOLCHAIN_VERSION=NONE -DEXTRA_CONF_FILE=overlay-pdn-nrf91-ipv4.conf;overlay-tfm-nrf91.conf -DBOARD_ROOT=/home/jeremy/Desktop/https_client_isrg

The serial terminal output is (connection fails):

*** Booting nRF Connect SDK d96769faceca ***
HTTPS client sample started
Bringing network interface up
Provisioning certificate
Connecting to the network
+CEREG: 2,"0001","01A2D101",7
+CSCON: 1
+CGEV: ME PDN ACT 0
+CEREG: 1,"0001","01A2D101",7,,,"11100000","11100000"
Network connectivity established and IP address assigned
Looking up letsencrypt.org
Resolved 54.66.176.79 (AF_INET)
Connecting to letsencrypt.org:443
connect() failed, err: 22
+CGEV: ME PDN DEACT 0
+CEREG: 0
+CGEV: ME DETACH
+CSCON: 0
Network connectivity lost
Disconnected from the network

I tried enabling all sorts of DEBUG log levels but I couldn't get any more useful error logs to show up in the serial printout. Perhaps I didn't find the right one.

Running Ozone to debug further, the failure seems to be inside the function mbedtls_pk_parse_subpubkey, which is called from line 1224 of x509_crt.c. The failing condition is on line 941 of pkparse.c:

if (ret == 0 && *p != end) {
    ret = MBEDTLS_ERROR_ADD(MBEDTLS_ERR_PK_INVALID_PUBKEY,
                            MBEDTLS_ERR_ASN1_LENGTH_MISMATCH);
}

Since this certificate is fine in my browser, I am not sure why it is failing to parse (also, I'm unsure why this error doesn't show up in the serial log, as it is a critical failure - perhaps this is a separate bug?). The certificate parses OK with OpenSSL:

$ openssl x509 -in 'isrgrootx1.pem' --text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Validity
            Not Before: Jun  4 11:04:38 2015 GMT
            Not After : Jun  4 11:04:38 2035 GMT
        Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:ad:e8:24:73:f4:14:37:f3:9b:9e:2b:57:28:1c:
                    87:be:dc:b7:df:38:90:8c:6e:3c:e6:57:a0:78:f7:
                    75:c2:a2:fe:f5:6a:6e:f6:00:4f:28:db:de:68:86:
                    6c:44:93:b6:b1:63:fd:14:12:6b:bf:1f:d2:ea:31:
                    9b:21:7e:d1:33:3c:ba:48:f5:dd:79:df:b3:b8:ff:
                    12:f1:21:9a:4b:c1:8a:86:71:69:4a:66:66:6c:8f:
                    7e:3c:70:bf:ad:29:22:06:f3:e4:c0:e6:80:ae:e2:
                    4b:8f:b7:99:7e:94:03:9f:d3:47:97:7c:99:48:23:
                    53:e8:38:ae:4f:0a:6f:83:2e:d1:49:57:8c:80:74:
                    b6:da:2f:d0:38:8d:7b:03:70:21:1b:75:f2:30:3c:
                    fa:8f:ae:dd:da:63:ab:eb:16:4f:c2:8e:11:4b:7e:
                    cf:0b:e8:ff:b5:77:2e:f4:b2:7b:4a:e0:4c:12:25:
                    0c:70:8d:03:29:a0:e1:53:24:ec:13:d9:ee:19:bf:
                    10:b3:4a:8c:3f:89:a3:61:51:de:ac:87:07:94:f4:
                    63:71:ec:2e:e2:6f:5b:98:81:e1:89:5c:34:79:6c:
                    76:ef:3b:90:62:79:e6:db:a4:9a:2f:26:c5:d0:10:
                    e1:0e:de:d9:10:8e:16:fb:b7:f7:a8:f7:c7:e5:02:
                    07:98:8f:36:08:95:e7:e2:37:96:0d:36:75:9e:fb:
                    0e:72:b1:1d:9b:bc:03:f9:49:05:d8:81:dd:05:b4:
                    2a:d6:41:e9:ac:01:76:95:0a:0f:d8:df:d5:bd:12:
                    1f:35:2f:28:17:6c:d2:98:c1:a8:09:64:77:6e:47:
                    37:ba:ce:ac:59:5e:68:9d:7f:72:d6:89:c5:06:41:
                    29:3e:59:3e:dd:26:f5:24:c9:11:a7:5a:a3:4c:40:
                    1f:46:a1:99:b5:a7:3a:51:6e:86:3b:9e:7d:72:a7:
                    12:05:78:59:ed:3e:51:78:15:0b:03:8f:8d:d0:2f:
                    05:b2:3e:7b:4a:1c:4b:73:05:12:fc:c6:ea:e0:50:
                    13:7c:43:93:74:b3:ca:74:e7:8e:1f:01:08:d0:30:
                    d4:5b:71:36:b4:07:ba:c1:30:30:5c:48:b7:82:3b:
                    98:a6:7d:60:8a:a2:a3:29:82:cc:ba:bd:83:04:1b:
                    a2:83:03:41:a1:d6:05:f1:1b:c2:b6:f0:a8:7c:86:
                    3b:46:a8:48:2a:88:dc:76:9a:76:bf:1f:6a:a5:3d:
                    19:8f:eb:38:f3:64:de:c8:2b:0d:0a:28:ff:f7:db:
                    e2:15:42:d4:22:d0:27:5d:e1:79:fe:18:e7:70:88:
                    ad:4e:e6:d9:8b:3a:c6:dd:27:51:6e:ff:bc:64:f5:
                    33:43:4f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        55:1f:58:a9:bc:b2:a8:50:d0:0c:b1:d8:1a:69:20:27:29:08:
        ac:61:75:5c:8a:6e:f8:82:e5:69:2f:d5:f6:56:4b:b9:b8:73:
        10:59:d3:21:97:7e:e7:4c:71:fb:b2:d2:60:ad:39:a8:0b:ea:
        17:21:56:85:f1:50:0e:59:eb:ce:e0:59:e9:ba:c9:15:ef:86:
        9d:8f:84:80:f6:e4:e9:91:90:dc:17:9b:62:1b:45:f0:66:95:
        d2:7c:6f:c2:ea:3b:ef:1f:cf:cb:d6:ae:27:f1:a9:b0:c8:ae:
        fd:7d:7e:9a:fa:22:04:eb:ff:d9:7f:ea:91:2b:22:b1:17:0e:
        8f:f2:8a:34:5b:58:d8:fc:01:c9:54:b9:b8:26:cc:8a:88:33:
        89:4c:2d:84:3c:82:df:ee:96:57:05:ba:2c:bb:f7:c4:b7:c7:
        4e:3b:82:be:31:c8:22:73:73:92:d1:c2:80:a4:39:39:10:33:
        23:82:4c:3c:9f:86:b2:55:98:1d:be:29:86:8c:22:9b:9e:e2:
        6b:3b:57:3a:82:70:4d:dc:09:c7:89:cb:0a:07:4d:6c:e8:5d:
        8e:c9:ef:ce:ab:c7:bb:b5:2b:4e:45:d6:4a:d0:26:cc:e5:72:
        ca:08:6a:a5:95:e3:15:a1:f7:a4:ed:c9:2c:5f:a5:fb:ff:ac:
        28:02:2e:be:d7:7b:bb:e3:71:7b:90:16:d3:07:5e:46:53:7c:
        37:07:42:8c:d3:c4:96:9c:d5:99:b5:2a:e0:95:1a:80:48:ae:
        4c:39:07:ce:cc:47:a4:52:95:2b:ba:b8:fb:ad:d2:33:53:7d:
        e5:1d:4d:6d:d5:a1:b1:c7:42:6f:e6:40:27:35:5c:a3:28:b7:
        07:8d:e7:8d:33:90:e7:23:9f:fb:50:9c:79:6c:46:d5:b4:15:
        b3:96:6e:7e:9b:0c:96:3a:b8:52:2d:3f:d6:5b:e1:fb:08:c2:
        84:fe:24:a8:a3:89:da:ac:6a:e1:18:2a:b1:a8:43:61:5b:d3:
        1f:dc:3b:8d:76:f2:2d:e8:8d:75:df:17:33:6c:3d:53:fb:7b:
        cb:41:5f:ff:dc:a2:d0:61:38:e1:96:b8:ac:5d:8b:37:d7:75:
        d5:33:c0:99:11:ae:9d:41:c1:72:75:84:be:02:41:42:5f:67:
        24:48:94:d1:9b:27:be:07:3f:b9:b8:4f:81:74:51:e1:7a:b7:
        ed:9d:23:e2:be:e0:d5:28:04:13:3c:31:03:9e:dd:7a:6c:8f:
        c6:07:18:c6:7f:de:47:8e:3f:28:9e:04:06:cf:a5:54:34:77:
        bd:ec:89:9b:e9:17:43:df:5b:db:5f:fe:8e:1e:57:a2:cd:40:
        9d:7e:62:22:da:de:18:27
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTUwNjA0MTEwNDM4
WhcNMzUwNjA0MTEwNDM4WjBPMQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJu
ZXQgU2VjdXJpdHkgUmVzZWFyY2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBY
MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK3oJHP0FDfzm54rVygc
h77ct984kIxuPOZXoHj3dcKi/vVqbvYATyjb3miGbESTtrFj/RQSa78f0uoxmyF+
0TM8ukj13Xnfs7j/EvEhmkvBioZxaUpmZmyPfjxwv60pIgbz5MDmgK7iS4+3mX6U
A5/TR5d8mUgjU+g4rk8Kb4Mu0UlXjIB0ttov0DiNewNwIRt18jA8+o+u3dpjq+sW
T8KOEUt+zwvo/7V3LvSye0rgTBIlDHCNAymg4VMk7BPZ7hm/ELNKjD+Jo2FR3qyH
B5T0Y3HsLuJvW5iB4YlcNHlsdu87kGJ55tukmi8mxdAQ4Q7e2RCOFvu396j3x+UC
B5iPNgiV5+I3lg02dZ77DnKxHZu8A/lJBdiB3QW0KtZB6awBdpUKD9jf1b0SHzUv
KBds0pjBqAlkd25HN7rOrFleaJ1/ctaJxQZBKT5ZPt0m9STJEadao0xAH0ahmbWn
OlFuhjuefXKnEgV4We0+UXgVCwOPjdAvBbI+e0ocS3MFEvzG6uBQE3xDk3SzynTn
jh8BCNAw1FtxNrQHusEwMFxIt4I7mKZ9YIqioymCzLq9gwQbooMDQaHWBfEbwrbw
qHyGO0aoSCqI3Haadr8faqU9GY/rOPNk3sgrDQoo//fb4hVC1CLQJ13hef4Y53CI
rU7m2Ys6xt0nUW7/vGT1M0NPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR5tFnme7bl5AFzgAiIyBpY9umbbjANBgkq
hkiG9w0BAQsFAAOCAgEAVR9YqbyyqFDQDLHYGmkgJykIrGF1XIpu+ILlaS/V9lZL
ubhzEFnTIZd+50xx+7LSYK05qAvqFyFWhfFQDlnrzuBZ6brJFe+GnY+EgPbk6ZGQ
3BebYhtF8GaV0nxvwuo77x/Py9auJ/GpsMiu/X1+mvoiBOv/2X/qkSsisRcOj/KK
NFtY2PwByVS5uCbMiogziUwthDyC3+6WVwW6LLv3xLfHTjuCvjHIInNzktHCgKQ5
ORAzI4JMPJ+GslWYHb4phowim57iaztXOoJwTdwJx4nLCgdNbOhdjsnvzqvHu7Ur
TkXWStAmzOVyyghqpZXjFaH3pO3JLF+l+/+sKAIuvtd7u+Nxe5AW0wdeRlN8NwdC
jNPElpzVmbUq4JUagEiuTDkHzsxHpFKVK7q4+63SM1N95R1NbdWhscdCb+ZAJzVc
oyi3B43njTOQ5yOf+1CceWxG1bQVs5ZufpsMljq4Ui0/1lvh+wjChP4kqKOJ2qxq
4RgqsahDYVvTH9w7jXbyLeiNdd8XM2w9U/t7y0Ff/9yi0GE44Za4rF2LN9d11TPA
mRGunUHBcnWEvgJBQl9nJEiU0Zsnvgc/ubhPgXRR4Xq37Z0j4r7g1SgEEzwxA57d
emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
-----END CERTIFICATE-----

Could you please help me understand what I have done wrong here?

My code is attached below.

0636.https_client_isrg.zip

[Michal]

Hello,

Did you convert the certificate properly? Remember that you have to escape the newlines in the certificate file to be able to include it directly in C.

Please take a look at the example certificate in the sample code for how it is done.

Best regards,

Michal

[jeremyherbert]

Hi Michal,

in NCS 2.6 you do not need to manually convert the certificate to a C string - this happens via a script in the CMakeLists file. You just pass in the raw PEM file (this is how the example now works by default).

Thanks,

Jeremy

[jeremyherbert]

Just to add to this, I have built mbedtls on my host machine (mac, x86) and it is able to parse the certificate with no problems:

$ ./ssl_client2 server_name=letsencrypt.org server_port=443 ca_file=isrgrootx1.pem debug_level=1
build version: Mbed TLS 3.5.2 (build 50659840)

  . Seeding the random number generator... ok
  . Loading the CA root certificate ... ok (0 skipped)
  . Loading the client cert. and key... ok (key type: RSA)
  . Setting up the SSL/TLS structure... ok
  . Connecting to tcp/letsencrypt.org/443... ok
  . Performing the SSL/TLS handshake...
Verify requested for (Depth 2):
cert. version     : 3
serial number     : 82:10:CF:B0:D2:40:E3:59:44:63:E0:BB:63:82:8B:00
issuer name       : C=US, O=Internet Security Research Group, CN=ISRG Root X1
subject name      : C=US, O=Internet Security Research Group, CN=ISRG Root X1
issued  on        : 2015-06-04 11:04:38
expires on        : 2035-06-04 11:04:38
signed using      : RSA with SHA-256
RSA key size      : 4096 bits
basic constraints : CA=true
key usage         : Key Cert Sign, CRL Sign
  This certificate has no flags

Verify requested for (Depth 1):
cert. version     : 3
serial number     : 91:2B:08:4A:CF:0C:18:A7:53:F6:D6:2E:25:A7:5F:5A
issuer name       : C=US, O=Internet Security Research Group, CN=ISRG Root X1
subject name      : C=US, O=Let's Encrypt, CN=R3
issued  on        : 2020-09-04 00:00:00
expires on        : 2025-09-15 16:00:00
signed using      : RSA with SHA-256
RSA key size      : 2048 bits
basic constraints : CA=true, max_pathlen=0
key usage         : Digital Signature, Key Cert Sign, CRL Sign
ext key usage     : TLS Web Client Authentication, TLS Web Server Authentication
certificate policies : ???, ???
  This certificate has no flags

Verify requested for (Depth 0):
cert. version     : 3
serial number     : 04:A7:BD:BA:BE:69:67:7A:A5:DF:42:99:AB:F6:E7:F8:DD:3B
issuer name       : C=US, O=Let's Encrypt, CN=R3
subject name      : CN=lencr.org
issued  on        : 2024-01-27 21:30:22
expires on        : 2024-04-26 21:30:21
signed using      : RSA with SHA-256
EC key size       : 256 bits
basic constraints : CA=false
subject alt name  :
    dNSName : lencr.org
    dNSName : letsencrypt.com
    dNSName : letsencrypt.org
    dNSName : www.lencr.org
    dNSName : www.letsencrypt.com
    dNSName : www.letsencrypt.org
key usage         : Digital Signature
ext key usage     : TLS Web Server Authentication, TLS Web Client Authentication
certificate policies : ???
  This certificate has no flags
 ok
    [ Protocol is TLSv1.2 ]
    [ Ciphersuite is TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 ]
    [ Key size is 256 ]
    [ Record expansion is 21 ]
    [ Maximum incoming record payload length is 16384 ]
    [ Maximum outgoing record payload length is 16384 ]
  . Verifying peer X.509 certificate... ok
  . Peer certificate information    ...
cert. version     : 3
serial number     : 04:A7:BD:BA:BE:69:67:7A:A5:DF:42:99:AB:F6:E7:F8:DD:3B
issuer name       : C=US, O=Let's Encrypt, CN=R3
subject name      : CN=lencr.org
issued  on        : 2024-01-27 21:30:22
expires on        : 2024-04-26 21:30:21
signed using      : RSA with SHA-256
EC key size       : 256 bits
basic constraints : CA=false
subject alt name  :
    dNSName : lencr.org
    dNSName : letsencrypt.com
    dNSName : letsencrypt.org
    dNSName : www.lencr.org
    dNSName : www.letsencrypt.com
    dNSName : www.letsencrypt.org
key usage         : Digital Signature
ext key usage     : TLS Web Server Authentication, TLS Web Client Authentication
certificate policies : ???

  > Write to server: 34 bytes written in 1 fragments

GET / HTTP/1.0
Extra-header:


  < Read from server: 146 bytes read

HTTP/1.0 400 Bad Request
Date: Mon, 25 Mar 2024 22:25:35 GMT
Server: Netlify
X-Nf-Request-Id: 01HSVVG474RHM9C83RK7FFN5PJ
Content-Length: 0

  . Closing the connection... done

[jeremyherbert]

I ended up finding the problem - by default, mbedtls is built with MPI_MAX_SIZE=256 which means that the largest RSA key size supported is 2048 bits. Instead, you need to build with CONFIG_MBEDTLS_MPI_MAX_SIZE=512 to support 4096 bit keys. It would be helpful if there was a more useful error in this case. 

I would suggest at least adding to the readme here that 4096 bit keys are not supported by default: https://github.com/nrfconnect/sdk-nrf/tree/main/samples/net/https_client - otherwise it is very non-obvious what needs doing. Can I also suggest adding some documentation somewhere about what the maximum RSA/ECDSA key sizes are too? There are a lot of places that mention that the certificate size can't be over 4kB, but the certificate in this case is well under this limit.

Note that the TLS offload system also only supports a maximum of 2048 bit keys, though I haven't found a place where this is documented (and neither for the maximum ECDSA key size).

In my case, the ISRG root certificate is 4096 bits so it can't be used with TLS offloading or the default mbedtls configuration. The solution with Let's Encrypt is to use an intermediate certificate as the CA certificate which is 2048 bits: https://letsencrypt.org/certificates/ - at this point in time, the "R3" certificate is 2048 bits so that is the one that should be used. However, the expiry time is much shorter than the root certificate (intermediate is 2025 vs 2035 for the root certificate) so that becomes a problem in itself.

Also please note that this unsolved issue may be related: devzone.nordicsemi.com/.../nrf9160-native-tls-with-offload-sockets-and-mqtt-client

[MarkoSagadin]

Hello Jeremy!

Thank you very much for providing this answer. Adding CONFIG_MBEDTLS_MPI_MAX_SIZE=512 to my prj.conf made it possible to connect to a different public broker (broker.emqx.io).

Provide some context for anybody coming from the internet:

I had a similar issue on NCS v2.7.0 with the mqtt sample. I could connect via TLS to the sample's default mqtt broker (mosquitto) without a problem, however I couldn't connect to the broker.emqx.io.

The annoying thing about this was that I made a successfully connection with the emqx broker, a year ago, with the NCS v.2.5.2.

The logs themselves were pretty much not useful:

*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
[00:00:00.539,855] <inf> network: Bringing network interface up and connecting to the network
[00:00:00.540,374] <dbg> mqtt_helper: mqtt_state_set: State transition: MQTT_STATE_UNINIT --> MQTT_STATE_DISCONNECTED
[00:00:00.542,419] <dbg> mqtt_helper: mqtt_helper_poll_loop: Waiting for connection_poll_sem
[00:00:02.109,527] <inf> wifi_mgmt_ext: Connection requested
[00:00:06.183,624] <inf> net_dhcpv4: Received: 192.168.76.247
[00:00:06.183,898] <inf> network: Network connectivity established
[00:00:11.185,821] <dbg> mqtt_helper: broker_init: Resolving IP address for broker.emqx.io
[00:00:11.202,972] <err> net_dns_resolve: DNS recv error (-103)
[00:00:11.730,163] <dbg> mqtt_helper: broker_init: IPv4 Address found 34.243.217.54 (AF_INET)
[00:00:11.730,194] <dbg> mqtt_helper: certificates_provision: CA certificate already exists, sec tag: 955
[00:00:11.730,255] <dbg> mqtt_helper: mqtt_state_set: State transition: MQTT_STATE_DISCONNECTED --> MQTT_STATE_TRANSPORT_CONNECTING
[00:00:11.730,957] <dbg> net_mqtt_sock_tls: mqtt_client_tls_connect: (): Created socket 14
[00:00:11.732,666] <err> net_dns_resolve: DNS recv error (-4)
[00:00:12.072,814] <err> net_sock_tls: TLS handshake error: -0x3b00
[00:00:12.080,200] <err> mqtt_helper: mqtt_connect, error: -113
[00:00:12.080,261] <dbg> mqtt_helper: mqtt_state_set: State transition: MQTT_STATE_TRANSPORT_CONNECTING --> MQTT_STATE_DISCONNECTED
[00:00:12.080,261] <err> transport: Failed connecting to MQTT, error code: -113
uart:~$

Even when I enabled mbedtls logs (check this Devzone post on how to do that) I wouldn't get any hint to what was happening:

*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
[00:00:00.585,388] <inf> network: Bringing network interface up and connecting to the network
[00:00:00.585,876] <dbg> mqtt_helper: mqtt_state_set: State transition: MQTT_STATE_UNINIT --> MQTT_STATE_DISCONNECTED
[00:00:00.587,921] <dbg> mqtt_helper: mqtt_helper_poll_loop: Waiting for connection_poll_sem
[00:00:02.150,543] <inf> wifi_mgmt_ext: Connection requested
[00:00:06.226,562] <inf> net_dhcpv4: Received: 192.168.76.247
[00:00:06.226,867] <inf> network: Network connectivity established
--- 144 messages dropped ---
[00:00:11.963,592] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3037: 0110:  97 f9 b2 62 3c ce aa 31 42 6f bc 00 0b 7a cd da  ...b<..1Bo...z..
[00:00:11.963,836] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3037: 0120:  c2 72 ed 00 ba 25 c0 51 37 9b 62 5e ed 23 b2 b9  .r...%.Q7.b^.#..
[00:00:11.964,080] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3037: 0130:  9f 09 c0 25 24 18 ef d2 52 41 ec 60 59 eb e4 d0  ...%$...RA.`Y...
--- 72 messages dropped ---
[00:00:11.964,324] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3037: 0140:  ed 3d af a9 20 0d 9e ec 61 37 ce d1 a1 b1 4d 09  .=.. ...a7....M.
[00:00:11.964,569] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3037: 0150:  d8 2f 30 9c c1 eb 31 fc ff 54 f6 d8 b0 66 ff 2f  ./0...1..T...f./
--- 33 messages dropped ---
[00:00:11.964,813] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3037: 0160:  2c 11 aa 25 e1 41 04 98 7f e2 29 10 e8 32 aa 2f  ,..%.A....)..2./
[00:00:11.965,026] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3037: 0170:  fc e7 94 54 62 fe bf dc cf bb 79 bc 66 fa b6 8d  ...Tb.....y.f...
--- 257 messages dropped ---
[00:00:12.033,752] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls12_client.c:1662: <= parse server hello
[00:00:12.033,813] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2358: => flush output
[00:00:12.041,015] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2323: ssl->f_recv(_timeout)() returned 768 (-0xfffffd00)
[00:00:12.041,107] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2320: in_left: 1439, nb_want: 3437
[00:00:12.041,198] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:3925: <= handshake
[00:00:12.090,881] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:3914: => handshake
[00:00:12.191,650] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0cc0:  03 02 48 a8 e5 5e 9d 1d d7 b7 24 36 55 1f 36 aa  ..H..^....$6U.6.
[00:00:12.191,894] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0cd0:  10 ba c6 c9 71 b4 d7 fb 7f 63 5d c7 61 bb 31 e9  ....q....c].a.1.
[00:00:12.192,138] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0ce0:  b8 c2 91 61 c8 f0 d3 d8 fe 94 27 63 27 ac 3f 85  ...a......'c'.?.
[00:00:12.192,352] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0cf0:  0b ff d9 28 7e 7f 11 1a 3d ea 08 73 f1 5a 8d 96  ...(~...=..s.Z..
[00:00:12.192,596] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0d00:  62 f9 45 7a 3c 2a cf 6b 32 bf c0 77 dc 70 63 88  b.Ez<*.k2..w.pc.
[00:00:12.192,840] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0d10:  72 46 f0 33 e7 dd b4 9b 25 1f 7f 07 54 a9 cd 12  rF.3....%...T...
[00:00:12.193,084] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0d20:  bc f9 45 9d a8 6c 66 0d 79 b9 3e 47 90 ae 3c b4  ..E..lf.y.>G..<.
[00:00:12.193,328] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0d30:  74 74 4c bb 8b 1f c6 91 a7 38 78 28 9f d8 a7 4b  ttL......8x(...K
[00:00:12.193,572] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0d40:  00 44 d6 fe f6 2d 51 e0 58 39 cc f3 6f 1e cd 81  .D...-Q.X9..o...
[00:00:12.193,786] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0d50:  6c 8b de d2 f9 30 c4 0c be 47 8e f6 ee a6 33 97  l....0...G....3.
[00:00:12.194,030] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3976: 0d60:  7d 36 ef 0f 63 10 50 ba 1c c5 d1 68 37           }6..c.P....h7
[00:00:12.194,152] <inf> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3242: handshake message: msglen = 3432, type = 11, hslen = 3432
[00:00:12.201,965] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:4194: <= read record
[00:00:12.203,765] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:5103: => send alert message
[00:00:12.203,857] <inf> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:5104: send alert level=2 message=42
[00:00:12.203,918] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2948: => write record
[00:00:12.204,040] <inf> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3032: output record: msgtype = 21, version = [3:3], msglen = 2
[00:00:12.204,132] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3037: dumping 'output record sent to network' (7 bytes)
[00:00:12.204,315] <dbg> mbedtls: zephyr_mbedtls_debug: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3037: 0000:  15 03 03 00 02 02 2a                             ......*
[00:00:12.204,376] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2358: => flush output
[00:00:12.204,467] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2372: message length: 7, out_left: 7
[00:00:12.204,864] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2379: ssl->f_send() returned 7 (-0xfffffff9)
[00:00:12.204,925] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:2406: <= flush output
[00:00:12.204,986] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:3085: <= write record
[00:00:12.205,047] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:5115: <= send alert message
[00:00:12.205,139] <err> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:7192:  mbedtls_x509_crt_parse_der() returned -15104 (-0x3b00)
[00:00:12.205,505] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_tls.c:3925: <= handshake
[00:00:12.205,535] <err> net_sock_tls: TLS handshake error: -0x3b00
[00:00:12.209,228] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:5974: => write close notify
[00:00:12.209,289] <wrn> mbedtls: WEST_TOPDIR/modules/crypto/mbedtls/library/ssl_msg.c:5985: <= write close notify
[00:00:12.213,043] <err> mqtt_helper: mqtt_connect, error: -113
[00:00:12.213,104] <dbg> mqtt_helper: mqtt_state_set: State transition: MQTT_STATE_TRANSPORT_CONNECTING --> MQTT_STATE_DISCONNECTED
[00:00:12.213,104] <err> transport: Failed connecting to MQTT, error code: -113
uart:~$

So the der parser failed above. Running gdb through the mbedtls code to figue why is not fun...

So yes, for me the mentioned config worked. Thank you again!