nRF91 How to use Google's primary and backup root CA on the modem?

[PopradiArpad]

Hi,

I want to connect to Google Cloud IoT with a modified asset_tracker and want the TLS done by the modem like in asset_tracker.

Google has a primary and a backup root CA for IoT and they may switch between the primary and backup certificates at any time without notice

See here cloud.google.com/.../mqtt-bridge

Is it enough to install these certificates (in the right converted form) as type 0 with different sec_tags on the modem?

I hope :)

With kind regards,

Árpád

[Didrik Rokhaug]

mike-at-currant said:

I have tried and have been unsuccessful, and was suspecting that the modem firmware doesn't support the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.

Google Cloud recently changed their list of supported cipher suites. As their new list of supported suites aren't supported by our older modem firmware versions, they can no longer be used together with Google Cloud.

However, we have added support for some GCM cipher suites in modem firmware 1.3.1.

[mike-at-currant]

Great news - thanks for the update, it's much appreciated!  I did set CONFIG_MBEDTLS_CIPHER_GCM_ENABLED=y in the config, and noticed that TLS_PEER_VERIFY_REQUIRED still didn't work.

We'll set TLS_PEER_VERIFY_NONE until we can update to firmware 1.3.1.

[Jeffrey Urban]

Has anyone got modem-based certs (the primary and backup minimal set, or the complete set) working with Google Cloud IoT Core on nRF91 (Asset Tracker v2 or otherwise)? It's unclear from this discussion if anyone was successful. It's also unclear what is the proper converted form, and which sets of certs (device and server) should be combined into separate sec_tags. I've tried several combinations and can't get it working.

I'm also modifying the Asset Tracker v2 example, and using the nRF9160 DK with nRF Connect SDK v1.7.1.

[Rokk Research]

I am successfully using Google IoT Core for a project on the nRF91 - I'm using the minimal root CA set described here for mqtt.2030.ltsapis.goog:
https://cloud.google.com/iot/docs/how-tos/mqtt-bridge#downloading_mqtt_server_certificates

I used the modem_key_mgmt_write() method to write the PEM encoded certs during provisioning, then reference the tag list in the TLS config via sec_tag_list.

Note that I had to set TLS_PEER_VERIFY_NONE with modem firmware prior to 1.3.1, I haven't yet tested with MFW1.3.1 to see if I can change it back to TLS_PEER_VERIFY_REQUIRED.

[Jeffrey Urban]

Hi Rokk Research,

Thanks for confirming that you've gotten it to work. Can you clarify if you've put 3 certs (both of the minimal root CA set certs + the device cert) and the client private key into a single sec_tag? 

I converted each of the Google minimal certs like this: 

openssl x509 -inform DER -outform PEM -in gtsltsr.crt -out gtsltsr.pem

I programmed the certs using the nRF91 device cred utility:

python3 cred.py \
    --CA_cert gtsltsr.pem \
    --CA_cert GSR4.pem \
    --client_cert my_device-cert.pem \
    --client_private_key my_device-private.pem \
    --sec_tag 202 \
    --program_app <path-to-my-app>/build/zephyr/merged.hex

I'm running the code from the google_iot_mqtt sample, called after the modem comes up. I removed the added globalsign.inc cert from the example code. SNTP is successful. DNS resolve for mqtt.2030.ltsapis.goog:8883 is successful.

If I include both Google minimal CA certs (plus the device cert and key) in one sec_tag, I get `could not connect, error -111`.

If I include only the primary cert `gtsltsr.pem` (plus the device cert and key) in one sec_tag, then I get `MQTT connect failed 5`.

If I create separate sec_tags for each of the minimal certs, and another sec_tag for the device cert + key, and reference all 3 sec_tags, I also get `MQTT connect failed 5`.

Thanks,
Jeffrey