Gude - TLS and the CA certificate
The certificate a Gude Expert Power Control unit needs so it can verify Neowit's MQTT broker, and how to confirm you have the right one. For whoever configures the hardware.
The broker is served behind a Google-managed certificate, so units that verify the server need Google's root in their trust store. Upload GTS Root R1:
| Download | https://pki.goog/repo/certs/gtsr1.pem |
| Subject | C=US, O=Google Trust Services LLC, CN=GTS Root R1 |
| Valid until | 22 June 2036 |
| SHA-256 fingerprint | D9:47:43:2A:BD:E7:B7:FA:90:FC:2E:6B:59:10:1B:12:80:E0:E1:C7:E4:E4:0F:A3:C6:88:7F:FF:57:A7:F4:CF |
This one file is all a unit needs. mqtt.neowit.io and mqtt.dev.neow.it present the same chain, so the same certificate covers production and development.
Two things worth knowing before you pick a file:
- Take the self-signed GTS Root R1, the one above. A second certificate with the same name exists, cross-signed by GlobalSign, and the broker sends it as part of its chain — but it expires in January 2028. Trusting that one instead would quietly stop every unit working on that date. Check the fingerprint against the table.
- Never pin the server's own certificate. It is reissued roughly every 90 days. Only the root belongs in the unit's trust store.
Your unit needs ECDHE key exchange, which anything current supports. TLS 1.2 and 1.3 both work; older key exchange without ECDHE is refused by the broker.
To check a certificate you already have, compare its fingerprint:
openssl x509 -in gtsr1.pem -noout -subject -dates -fingerprint -sha256 And to confirm the broker accepts it as the only trust anchor:
openssl s_client -connect mqtt.neowit.io:8883 -servername mqtt.neowit.io \ -CAfile gtsr1.pem -verify_return_error -verify_hostname mqtt.neowit.io </dev/null The last line should read Verify return code: 0 (ok).
Related
- Gude setup — the rest of the unit configuration.