On 6/24/21 10:30 AM, Per Jessen wrote:
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. Hi Pers, and thanks again for your responses. OK I will accept your explanation, for the moment, but then I have to ask what is ssh doing? The ssh client clearly understands when a certificate from it's server (sshd) has changed and it will definitely whine about it. To me the only way the ssh client "knows" this is that it must have something to compare the new certificate against. I am going to continue this line of questions below because you have explained something I was unaware of.....
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 Now this makes sense and is exactly what I was asking for, a common library that servers and clients can use to establish a secure connection. So the remaining question is why doesn't it handle the error conditions and do the presentation of the error and solutions on how to handle the errors.
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. These are not client apps, rather these are services running on a server. I would not expect these to have a user interface, but I would expect client apps connecting to these services to have a user interface, or a way to communicate to a user when things go wrong, and supply the user with a way to fix the sort of problem like this one, a connection failure due to having a cached version of an invalid/out of date certificate.
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. I disagree, while TB and FF don't cache certificates directly (I am not sure about this) I strongly suspect that they use libssl to establish a secure connection. And from the behavior of the ssh client, I strongly suspect that libssl IS caching certificates from servers that it was requested to make a secure connection to, in the past.
So I am going to hypothesize that automount/autofs, for example, is using libssl to establish a secure connection, which would explain why automount starts working after I use ssh to update the "cached copy" of the certificate for the host that the sshd service is running on. Automount is interesting in that I guess/suspect it is both a client and a service. As a client it can connect to file services, such as NFS or NMB/SMB etc., running on other machines, and uses libssl to create a secure connection that allows the transfer of data to/from mount points, and vice versa. And as a client it badly handles a connection error caused by invalid/out of date certificates, and just reports a bad generic error message in the system log files.
If you want to influence development, this is probably more a topic for the factory list or maybe for those individual projects.
Which brings us back to my original question, who SHOULD have the responsibility for reporting connection errors caused by an invalid/out of date certificate? I guess I can ask on the factory list also, assuming I can join that list. Marc....
-- *"The Truth is out there" - Spooky* *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed. My public key for sending encrypted email to me can be found at - https://keys.openpgp.org/search?q=marc@marcchamberlin.com or just ask me for it and I will send it to you as an attachment. If you don't understand, no worries, just ignore it and/or ask me to explain it further./)