Let me respond to previous posts in an attempt to explain what is happening. (I believe in knowledge as a basis for decisions.) And to propose an option to Kostya:
1. It is not the client. It is the servers. It used to be that the SSL certificates on the server were valid for 1-3 years, and they were replaced just before they were expiring. Recently Google started changing them about once a month. I agree, it's a bit annoying. (And then, you get a chance of seeing flip-flop if you happen to connect to a server with a new certificate, then to one with the old one, and then again to the one with the new one, -- could be on the same day.)
At the same time, there is a push toward moving all web traffic from http to https. For this reason, many websites who had never had SSL certificates need those. Most certificates are not free. But there is a recent provider, Let's Encrypt, that provides free SSL certificates that are only valid for 3 months:
https://letsencrypt.org/So, you may see many small providers switching to those.
And with the "Let's Encrypt", the automated renewal of certificates happens for those certificates that are less then 1-month before the expiration. That makes the actual life of a certificate to be about 2 months.
2. Before I go to what Aquamail does with the certificates, I need to mention two (or three) roles that SSL certificates play in the secure communications:
a) to encrypt the exchange of information, and
b) to authenticate that the communicating side/participant (server, client) is who it claims to be.
Actually, the latter, has two possible aspects:
i) It is verified through the "trusted authority" that they are who they are (And then there are different levels of that verification, as different Trust Authorities may require different confirmations: some just confirm that the server indeed can control the domain, while others require confirmation of the entity name used in the certificate. But we are not going to go this deep here.)
ii) It is confirmed that it is the same participant (server) as you've already communicated previously (independently of whether it may or may not be verified through a trusted authority).
Unfortunately (b.ii) is largely defeated by the frequent change of the certificates.
Moreover, unfortunately, I am not aware of any web browsers or even any other e-mail clients that inform you about change of the certificate while the new certificate is valid.
I know only two categories of software where this change is tracked: all SSH implementations [that I've seen], and Aquamail.
None of the webservers, none of the e-mail clients (of those that I've seen), none of the "MTA's" (mail transfer agents, i.e. servers transmitting e-mails between servers via SMTP protocol), none of the source control software (here my information is primarily based on my conversations with software developers who use those), or any other software that relies on certificates (SSL).
3. Aquamail behavior with respect to the certificates. I remember reading Kostya's explanation about this behavior, and while I understood (I think) his explanation, I was confused.
Here is a summary of my understanding:
a) Aquamail checks the validity of the certificate. IIRC, that includes the check of the entire chain down to the root certificate. That is done if "strict checking" enabled. (I.e. if the server has a self-signed certificate or a certificate without the root authority known to the device, Aquamail will not continue with the connection.) If the strict checking is disabled, then, essentially the certificate is used to encrypt the password exchange and the rest of the communication, and a self-signed certificate is sufficient.
Then, a separate issue is tracking if the certificate for the server is the same as the one used before. This is a defense for the man-in-the-middle (mitm) attack, where a rogue server is pretending to be the right one. As far as I understand, the logic behind this check is that the rogue server trying to impersonate the target server may have a certificate that may look valid, and might even check out to some valid (known) root CA. That's why Aquamail offers an option to accept or reject the new certificate.
This is a good functionality. But in view of the frequent rotation of the certificates, it becomes annoying, and as a result, it looses its importance, as most users just automatically click on "accept". (You might remember a period when one of the web browsers started by default confirming every cookie it was receiving - and people just turned that off.)
Now, something that I am not 100% sure:
1) I suspect that turning of "Strict checking" under server settings for the account would disable confirmation when the SSL certificate changes. Is that the case?
2) If that's the case, - I'd rather have two separate options: (A) don't be strict on verifying the certificate chain, and (B) do not ask about changing certificate if it is completely verified (probably only in the sense of "strict checking").
In this case one can choose (B) but not (A), and have strict verification without the annoyance from Gmail servers (or potentially many other providers).
(As discussed above, essentially, all email clients that I know implement (B) as the standard behavior without giving an option otherwise.)
@Kostya, I greatly appreciate the fact that the confirmation for the change of certificate exists in Aquamail. This is an indication that you are concerned about security. But it would make great sense to separate the options as proposed above. Furthermore, I'd suggest it would make sense to keep them separate for different accounts (as it is done now for the existing option).
I apologize if I misunderstood and/or missed something in the interpretation of Aquamail behavior/options.
