Closed ja-mescher closed 5 years ago
The mqtt.googleapis.com endpoint may rotate certificates frequently due to standard Google Cloud Endpoint maintenance. While the domain is consistent today, the signing certificate may change when the domain authentication certificate expires.
Most domain authentication certificates last a year. When they're replaced it's common practice for Google administrators to choose from one of ~100 different certificates to sign the new one, so the endpoint root certificate may not be consistent over time. The standard Google roots.pem file is provided for most applications for use in authenticating all of these certificates.
Unfortunately this roots.pem file is quite large (75k) and isn't well suited for embedded devices. Therefore, for IoT Core, we've created Long Term Service Domains. These domains will use a consistent signing certificate on their endpoint until the endpoint's expiration.
The two certificates provided in the Embedded C Client can be used to validate certs served by this LTS domain "mqtt.2030.ltsapis.goog"
Some more notes:
we include two certs as one serves a fallback.
the header src/libiotc/iotc_config.h defines this domain as the default for iotc_connect to use.
the current LTS domain will expire in 2030.
I hope this helps.
Thanks for the clarification! The reference to Long Term Service Domains is exactly what I was missing.
The list of features from "Using a long-term MQTT domain" is ideal for embedded devices (two short ECC certs and support for TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256)
I am running into issues in practice however.
When I test the "mqtt.2030.ltsapis.goog" URL I find the same ciphers are supported as "mqtt.googleapis.com":
and ECDHE-ECDSA-AES128-GCM-SHA256 isn't accepted by the server during the TLS handshake despite what the documentation on 'Using a long-term MQTT domain' says.
I am testing this by running the following command: openssl s_client -connect mqtt.2030.ltsapis.goog:8883 -cipher ECDHE-ECDSA-AES128-GCM-SHA256
I also tested the two root CA certs without success using the following command: openssl s_client -connect mqtt.2030.ltsapis.goog:8883 -CAfile gtsltsr.pem and openssl s_client -connect mqtt.2030.ltsapis.goog:8883 -CAfile GSR4.pem
I am also testing with WolfSSL in my project but openssl is more simple for testing/explanation.
Am I missing something?
Thank you for your help with this.
I hope it's ok to jump in here.
You need to use SNI to access the LTS TLS configuration. All devices moving forward must use SNI.
For example, this worked for me openssl s_client -connect mqtt.2030.ltsapis.goog:443 -servername mqtt.2030.ltsapis.goog -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -CAfile iot_rootCAs.pem
Also, CAfile must specify/include the GlobalSign root as that is the issuer of the intermediate cert currently sent by the server.
@csgcp I was indeed missing SNI. I applied SNI to both OpenSSL and my project and have them both using ECDHE-ECDSA-AES128-GCM-SHA256 and the TLS connections authenticating with the GSR4 cert.
SNI makes a lot of sense, sorry I missed that requirement as it was clearly noted in the LTS documentation. Thank you for the help!
From the README in res/trusted_RootCA_certs/ two root CA certs are included in the project.
From testing I found that 'mqtt.googleapis.com' only supportes the following TLS ciphers:
And when initiating a TLS handshake the only root CA that validates the server cert is:
This cert has an RSA 2048 public key.
Will someone clarify how the project's included certs were chosen from the list of possible certs?
Both of the project's included certs have ECC 256 public keys; will these certs validate the server cert since only RSA authentication algorithms are supported and not ECDSA?