Marc Chamberlin wrote:
On 6/24/21 1:25 AM, Per Jessen wrote:
"A" is running a service using LE certificates, maybe https - "B" connects and only needs to check if the certificate presented by "A" is valid. "B" typically does not present anything.
Per - Again thanks for your reply. I will accept your explanation, mine was only an inference about what is going on when the certificate stored on Computer A is different from the one Computer B has for Computer A.
Hi Marc Yes, but the issue is that B does not have a "certificate for A" stored or cached. A presents a certificate, and B just validates it.
This doesn't really change anything about what I have reported and the behavior I seem to be seeing. The bottom line is that there is a difference, between what is presented and what is cached,
Without more information, it is difficult to say, but I don't see where anything is being cached.
and the certificate is rejected, causing the connection to fail. And some clients apparently drop the ball on this problem, don't offer a solution, and simply spit out a useless and/or bogus error message that can only be interpreted as - "I'm sorry, I can't do that". NOT helpful and sometimes the bogus error message is extremely misleading.
Yes, that is quite likely correct - I have also had to debug such issues in postfix.
Example: When your Firefox browser tries to connect to an https website and cannot validate the certificate presented by the server (expired, revoked, wrong name, unsupported TLS version), it is up to the browser to inform you.
OK, but a more unified approach to handling this error condition would provide a better user experience. Which is why I suggest that perhaps the O.S. should be more involve or a mandatory common library be used to make a secured connection between the client and the server.
It is a common library, it is called libssl, by the OpenSSL project, https://www.openssl.org
Right now it appears that the developers of each client app is handling this error condition in different ways, often badly, and I feel this model should be reconsidered.
Many apps don't even have a user interface as such - postfix, apache, dovecot, openvpn - but there is no reason why apps should not try to be more user friendly.
My guess is that when Firefox, or Thunderbird want to make a secure connection to their respective servers, when they encounter a mismatched set of certificates, or hold an out of date certificate for their server's host,
I think you misunderstand - they simply don't "cache" anything. A mail server or an https server presents them with a certificate. The client (TB or FF) validates it - checks that the name matches, that it is not expired, that it is nort revoked - if all is good, the client permits the connection. If you want to influence development, this is probably more a topic for the factory list or maybe for those individual projects. -- Per Jessen, Zürich (18.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.