EC200U-CN question on TLS server-certificate validation with AT+QSSLCFG="cacert" — does the modem use a built-in CA trust store in addition to the user-uploaded CA?

IoT Modules LTE Standard Module
1

We have a specific TLS-validation question that the SSL Application Note V1.2 does not address explicitly, and we would appreciate authoritative clarification.

Setup

  • EC200U-CN, firmware EC200UCNAAR03A03M08

  • Customer-uploaded CA via AT+QFUPL="UFS:cacert_<hash>.pem", ...

  • AT+QSSLCFG="cacert",1,"UFS:cacert_<hash>.pem" to bind the uploaded CA to SSL context 1

  • AT+QSSLCFG="seclevel",1,1 for server-only authentication

  • AT+QSSLCFG="sslversion",1,3 (TLS 1.2)

  • AT+QSSLCFG="ciphersuite",1,0XFFFF

  • Following parameters explicitly set to strict values: ignorecertitem=0, ignoreinvalidcertsign=0, ignoremulticertchainverify=0, sni=1

  • AT+QMTCFG="ssl",1,1,1 then AT+QMTOPEN=1,"<broker>",8883

Observations from our bench testing

  1. Connecting to broker.hivemq.com:8883 (a public broker whose server certificate chains to Amazon Root CA 1) succeeds even when we deliberately upload a wrong CA — ISRG Root X1 (Let’s Encrypt’s root, which does not appear anywhere in HiveMQ’s certificate chain). +QMTOPEN: 1,0 and +QMTCONN: 1,0,0 complete normally, the broker accepts our CONNECT, publishes succeed. The behaviour is identical whether the strict knobs are set or not.

  2. Connecting to a private TLS broker (Mosquitto behind an ngrok TCP tunnel, with a server certificate chained to a throwaway CA generated on our laptop that exists in no public trust store) fails deterministically with +QMTOPEN: 1,4 even when we upload that throwaway CA to the modem. The same broker accepts plain TCP from the modem (with TLS disabled, we observe +QMTOPEN: 1,0), confirming the underlying carrier/DNS/TCP path is healthy. The TLS handshake itself never reaches our broker side.

  3. From a normal desktop TLS client (openssl s_client) using the same throwaway CA as the trust anchor, the handshake to the same broker through the same tunnel succeeds and Verify return code: 0 (ok). So the certificate chain itself is valid; the modem is rejecting it where a spec-compliant client accepts it.

Question

Does the EC200U-CN firmware ship with a built-in / pre-loaded CA trust store of well-known public root CAs that supplements (or overrides) the user-uploaded CA referenced via AT+QSSLCFG="cacert"?

In particular:

  • When seclevel=1, does the modem validate the server certificate ONLY against the uploaded CA, OR against the union of (uploaded CA, built-in trust store)?

  • Are self-signed root CAs uploaded by the user accepted as valid trust anchors? If not, what additional requirement must they meet (key size, extension flags, signature algorithm, etc.)?

  • Is there a documented difference between the EC200U “CN” (China) variant and other regional variants on TLS trust-anchor behaviour?

  • Is there a way to disable the built-in trust store (if it exists) so that only the uploaded CA is used — for customers running their own private CA infrastructure?

We want to document accurate TLS behaviour in our product specification so customers with private brokers and private CAs can deploy with confidence (or know in advance that this configuration is unsupported by the EC200U).

2

Hi Sanjay,

Based on the currently available documentation and observed module behaviour, please find the clarifications below.

  1. Does the EC200U-CN firmware ship with a built-in / pre-loaded CA trust store of well-known public root CAs that supplements (or overrides) the user-uploaded CA referenced via AT+QSSLCFG="cacert"?

Based on the current EC200U-CN documentation and observed behaviour, the module does not appear to use a built-in/public CA trust store in addition to the CA configured via:

AT+QSSLCFG="cacert",<ctx>,"UFS:cacert.pem"

TLS server verification appears to rely primarily on the user-uploaded CA/certificate bundle bound to the SSL context. At present, there is no documented evidence of automatic fallback, merging, or override behaviour using internally stored public root CAs.

  1. When seclevel=1, does the modem validate the server certificate ONLY against the uploaded CA, OR against the union of (uploaded CA, built-in trust store)?

Per documentation, when seclevel=1 or 2 is configured, a trusted CA certificate should be uploaded to the module.

However, based on practical test observations, the module appears capable of validating the server certificate against both:

  • the user-uploaded CA configured through AT+QSSLCFG="cacert"
  • internally available trusted root certificates present within the firmware

This may explain scenarios where HiveMQ connections succeed despite the uploaded CA not directly matching the broker certificate chain.

  1. Are self-signed root CAs uploaded by the user accepted as valid trust anchors? If not, what additional requirements must they meet (key size, extension flags, signature algorithm, etc.)?

User-uploaded root CAs are supported as trust anchors.

For private CA deployments, please additionally verify the following:

  • Module RTC/local time is valid (AT+CCLK?)

  • Certificate is uploaded in proper PEM format using AT+QFUPL

  • The self-signed root certificate contains proper CA extensions such as:

    • Basic Constraints: CA=TRUE
    • appropriate Key Usage attributes for certificate signing

With strict verification enabled (ignorecertitem=0), certificates missing the required CA attributes may be rejected.

For testing purposes, local time verification may be bypassed temporarily using:

AT+QSSLCFG="ignorelocaltime",1,1
  1. Is there a documented difference between the EC200U “CN” (China) variant and other regional variants regarding TLS trust-anchor behaviour?

Currently, there is no documented difference between EC200U-CN and other EC200U regional variants regarding TLS trust-anchor logic or SSL certificate validation behaviour.

Most documented regional differences relate to hardware or network capabilities rather than TLS stack implementation.

  1. Is there a way to disable the built-in trust store (if it exists) so that only the uploaded CA is used for customers running their own private CA infrastructure?

At present, there is no documented AT command available to disable internally available trust anchors or force validation exclusively against the uploaded CA certificate.

The SSL stack appears designed to establish a valid trust path using any trusted anchor recognized by the firmware.

Please let me know if any additional clarification is required.

3

Thanks for your response