Does user need to keep updated with the certificates locally when using TLS with smtp?

Question

https://wjianz.wordpress.com/2014/09/03/howto-installconfigure-msmtp-and-mutt-on-ubuntu/

I got GTS CA 1O1 as the common name instead of Google Internet Authority G2. What is the difference between the two.

So GTS CA 1O1 refers to the one listed here https://pki.goog/?

I see GTS CA 1O1 valid until Dec 15, 2021. So by Dec 15, 2021, I should regenerate the local crt file by openssl x509 -inform DER -in GTS1O1.crt -outform PEM -out gmail-smtp.crt

$ msmtp --serverinfo --tls=on --tls-starttls=off --host=smtp.gmail.com
SMTP server at smtp.gmail.com ([172.217.195.108]), port 465:
    smtp.gmail.com ESMTP a10sm3703146oic.46 - gsmtp
TLS session parameters:
    (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
TLS certificate information:
    Owner:
        Common Name: smtp.gmail.com
        Organization: Google LLC
        Locality: Mountain View
        State or Province: California
        Country: US
    Issuer:
        Common Name: GTS CA 1O1
        Organization: Google Trust Services
        Country: US
    Validity:
        Activation time: Tue Nov  5 15:45:23 2019
        Expiration time: Tue Jan 28 15:45:23 2020
    Fingerprints:
        SHA256: 50:E7:13:03:7B:A8:D8:28:3C:D2:66:AC:58:E3:76:6D:BB:DB:E2:9D:B6:8F:54:38:10:BC:A5:93:67:25:7D:4D
        SHA1 (deprecated): F4:D9:49:8F:FA:F0:06:D1:B8:D7:AE:A8:56:A3:36:B4:FB:76:3E:32
Capabilities:
    SIZE 35882577:
        Maximum message size is 35882577 bytes = 34.22 MiB
    PIPELINING:
        Support for command grouping for faster transmission
    AUTH:
        Supported authentication methods:
        PLAIN LOGIN OAUTHBEARER 

Answer 1

I see GTS CA 1O1 valid until Dec 15, 2021. So by Dec 15, 2021, I should regenerate the local crt file by openssl x509 -inform DER -in GTS1O1.crt -outform PEM -out gmail-smtp.crt

If google at any point changes their certificate, and you statically trust only a single certificate, you will have to refresh it, yes.

The proper way to do this would probably be to use your OS' set of trusted certificates. On Debian they're by default located in /etc/ssl/certs, and google uses certificates that's trusted by almost all operating systems. This would avoid any manual work on your part, but reduce security slightly. The guide you follow tells you how to do this:

tls_trust_file /etc/ssl/certs/ca-certificates.crt

This will make it trust all certificates that your distribution (Ubuntu) includes as trusted.

I would suspect that you have no guarantee that google will return identical certificates on all connections, nor that they won't change them well ahead of expiry time.

Answer 2

To add to vidarlo's answer, you don't generally want to trust specific certificates unless you need extremely high levels of security and are willing to deal with a lot of maintenance and potential breakage. Trusting only a single certificate is an extreme form of what's called "certificate pinning", and is almost always a bad idea when you don't control both ends of the connection (which you don't, here, unless you're secretly a Gmail server admin). Any time the certificate expires, gets re-issued for any reason (such as to update alternative domain names or change its permitted usage), or gets actively revoked (hopefully never needed), your email will break. What's more, you have only limited knowledge of when that will happen, and no ability to tell precisely.

Potentially worse still, if you aren't manually verifying the cert Google provides then you're just blindly trusting whatever certificate you get, which could be from anybody. Normally certs are verified by checking their "chain of trust" - the issuer is either in your root CAs, or is issued by a CA in your root CAs, or... until you establish a full chain from a root CA to the server cert - but in order to do that your software needs a list of trusted root CA certs (this is what the file /etc/ssl/certs/ca-certificates.crt typically contains). If I manage to get a man-in-the-middle position between you and Google at the time that you're regenerating your .CRT file, I could give you a fake Google cert, and you'd probably trust it and then send your password and emails to me.

---

Generally speaking, it's just fine to use the /etc/ssl/certs/ca-certificates.crt list. It's what most or all of the other TLS-supporting software on your system uses anyhow (Mozilla has their own trust store, separate from the system one, but pretty much everything else uses that). If you want to be extra paranoid, though, you could use a customized list of CA certificates that excludes ones which seem "sketchy" (such as from CAs controlled by governments that you don't trust). You could even restrict the list of trusted CAs down to just the one that Google's certs chain to (hoping that Google won't decide to switch root CAs, which is possible but way less likely than re-issuing their "leaf" certificate all the time). This is a much less fragile sort of certificate pinning, though it's still got some risk.