Pantavisor used to trust only one certificate authority: Let’s Encrypt. A device could reach Pantacor Hub, but not an HTTPS server whose certificate came from another CA. meta-pantavisor now ships the root certificates of the six largest public CAs, taken from the Mozilla bundle. Most builds need to do nothing: the new roots come with the next build of meta-pantavisor master.
The change is feat(libthttp): ship the root CAs of six large public CAs by asac · Pull Request #574 · pantavisor/meta-pantavisor · GitHub.
What is in the trust store?
Pantavisor checks the TLS certificate of every server it connects to against the roots in /etc/thttp/certs on the device. That directory now holds 25 roots:
| CA | Roots |
|---|---|
| Let’s Encrypt (ISRG) | ISRG Root X1, X2 |
| DigiCert | Global Root G2, G3; TLS RSA4096 Root G5; TLS ECC P384 Root G5 |
| Sectigo | USERTrust RSA and ECC, COMODO RSA and ECC, Public Server Authentication Root R46 and E46 |
| GlobalSign | Root CA R3, R6; ECC Root CA R4, R5; Root R46, E46 |
| Google Trust Services | GTS Root R1, R3, R4 |
| Amazon | Amazon Root CA 1, 2, 3, 4 |
Every CA has RSA roots in the list, and the newest roots run until 2046.
Checking a device
ls /etc/thttp/certs
grep truststore /pv/logs/<revision>/pantavisor/pantavisor.log
The log line reads Found 25 http x509 certs in truststore.
Adding or removing a root
The list is the PV_TLS_CA_CERTS variable in recipes-pv/libthttp/libthttp_git.bb. Each entry is a file name from the Mozilla bundle in /usr/share/ca-certificates/mozilla/, without .crt. To add one, from a kas local_conf_header or a bbappend:
PV_TLS_CA_CERTS:append = " Microsoft_RSA_Root_Certificate_Authority_2017"
When Mozilla retires an old root, the build skips it with a warning, so updating ca-certificates never breaks the build.
How it was tested
Besides the usual CI and the full remote pvtest suite against Pantacor Hub, we pointed an appengine device at other servers instead of the Hub:
| Server | Root | Result |
|---|---|---|
| www.google.com | GTS Root R1 | connects |
| s3.amazonaws.com | Amazon Root CA 1 | connects |
| github.com | USERTrust RSA (Sectigo) | connects |
| www.microsoft.com | DigiCert Global Root G2 | connects |
| www.identrust.com | IdenTrust (not in the list) | refused |
| www.actalis.it | Actalis (not in the list) | refused |
Limits to know about
- Key exchange. Pantavisor’s TLS library only uses plain RSA key exchange. Servers that require ECDHE (forward secrecy) refuse the connection, whatever their CA. Many large sites still accept RSA key exchange; some, like www.digicert.com, do not. Enabling ECDHE is the next step.
- No clock checks. Devices often have no reliable clock, so Pantavisor does not check certificate dates. An expired root keeps working on the device, so roots only leave the list through a BSP update.
Older releases
The change is in the libthttp recipe only, so it can be picked onto older meta-pantavisor releases. They load the certificate directory the same way.
What’s next
A certificate denylist is in review. It will let a BSP update block a single server, intermediate or root by its public key, without needing a clock: feat(tls): block certificates listed in a denylist by asac · Pull Request #5 · pantavisor/libthttp · GitHub and feat(tls): add a certificate denylist for HTTPS connections by asac · Pull Request #864 · pantavisor/pantavisor · GitHub.