Marc Chamberlin wrote:
Anywise from what I am observing, let's say Computer A is running some services and it also has some security certificates from LetsEncrpyt that gets automatically updated. Right. A perfectly straight forward setup.
There is no problem as far as Computer A is concerned. Now Computer B comes along and has a client that wants to connect to a service on computer A. In order to establish a secure connection to Computer A, Computer B's client presents a cached copy of the certificate that Computer B has for Computer A, to Computer A. But the certificate from Computer B is now out of date and Computer A refuses it. "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. 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, 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.
So my question is, who should have the responsibility for presenting a decent error message, the O.S. itself, or each client/server app? The latter. The operating system is not in charge.
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
On 6/24/21 1:25 AM, Per Jessen wrote: 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. 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.
In other words who do I belly ache to? BTW IMHO the error message from the ssh client is pretty decent and I got no complaints with it! This is where I get lost - what has ssh got to with your LE certificates ?
Ssh is simply another client application (of sshd) and handles the condition of certificate rejection far better that most other types of clients. I like it's handling of a certificate rejection because it actually presents a guide to a solution for the user, i.e. it tells the user on Computer B that he/she has to delete the cached version of the certificate for Computer A, and how to do it. Here is an example - marc@bigbang:~/bin> ssh marc@nova @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:85Nz/w0T9weHNksY7etRqmV5Fmmctxt1p8U4cZ4yFuE. Please contact your system administrator. Add correct host key in /home/marc/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/marc/.ssh/known_hosts:9 You can use following command to remove the offending key: ssh-keygen -R nova -f /home/marc/.ssh/known_hosts I simply have to follow the directions for removing the offending key and the next time I use ssh I get this - marc@bigbang:~/bin> ssh marc@nova The authenticity of host 'nova (192.168.10.10)' can't be established. ECDSA key fingerprint is SHA256:85Nz/w0T9weHNksY7etRqmV5Fmmctxt1p8U4cZ4yFuE. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'nova,192.168.10.10' (ECDSA) to the list of known hosts. Password: Last login: Wed Jun 23 21:24:14 2021 from 192.168.10.100 Have a lot of fun... and VIOLA! I have been guided to the solution, by ssh, and am a happy camper on my way! Now if only all client apps wanting to make a secure connection to their server could handle this rejection of a certificate in a similar fashion, instead of presenting crap for an error message, wouldn't that be nice? Which is why I feel that normalizing connection requests, in either the O.S. itself, or in a required common library would be a wonderful OOD solution. Just an idea/thought. 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, they simply first assume the user wants to update their cached version of the certificate. So they simply attempt to go ahead and do so with minimal interactions with the user. If necessary, and I have seen Firefox do this, they too will pop up a dialog explaining the problem and guide the user to a solution. Also not a bad solution, IMHO of course. 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./)