Mick <michaelkintz...@gmail.com> writes: > On Sunday 06 Sep 2015 15:29:25 lee wrote:
> [...] >> >> Is it possible to create a certificate that doesn't use either but a >> wildcard only? I don't understand why or how an fqdn/IP in a >> certificate could or should be relevant at all. > > It is relevant because Mozilla will read the CN and or subjectAltName fields > for DNS/IP to match against the URL the client is trying to connect to. It > will also read any additional fields for OCSP and CRL URIs and try to connect > to those too to retrieve relevant files (e.g. of revocation lists). These > would be contained in the certificate's X509v3 extensions. The browser does > not extrapolate from what is contained in those fields, but treats their > contents literally. If the CN field contains 'example.com' but the client is > trying to connect to 'www.example.com' (or the server redirects to the > latter) > the browser's verification engine could throw its arms up and say STOP! This > is not the address specified on the certificate, therefore you could be > inadvertently trying to connect to a malicious server impersonating your > server. The browser is warning about a Man In The Middle attack. This is > fine and as it should be. Thank you for the explanation. I'm like entirely omitting this part because when I do accept a certificate (i. e. add an exception), I have done so. That's all there is to it. Actually, I'm doing it on a LAN. I can look at the certificate and see if it looks ok. If there was someone in between me and the server, I'd be having far more serious problems than not being able to add an exception. So the part I'm omitting isn't relevant as long as a warning comes up when the certificate I previously accepted suddenly doesn't match anymore. But having that said, I probably need to change my way of thinking: If a user goes somewhere with their laptop and gets that warning, chances are that they will add an exception, and bad things might happen. Using a CA certificate won't stop them, though. Now what? > What is not at all fine is that it stops you connecting AND it does > not allow you to acknowledge as acceptable whatever it is that it > doesn't like about your certificate. Indeed --- fortunately, this problem is solved with seamonkey 2.35. > [...] >> When a friend calls you on the phone, you do not insist that they are >> not your friend and reject their call just because they're calling you >> from a different phone number. > [...] > > Well, in the UK we have a feature called 'Caller ID'. You will be surprised > at the number of voice mails I have to leave when I call from a 'caller ID > witheld' phone. People will NOT answer unless they recognise the number of > the caller. :-) Some people do that here, too. It's their problem, not mine. Besides, I was told that the caller number is easy to fake, which people found relevant with faxes. > With a server the FQDN is much more important, as it can impersonate e.g. you > Bank and steal login information about your login details. Still I have no way to verify whether I'm connected to the server I think I'm connected to or not (i. e. the bank or someone else). Sure, I might be asked to add an exception and thus be alarmed --- but unable to verify. So turning this the other way round: Can I *prevent* users from being able to add an exception (at least by making it rather difficult for them)? Assuming that I would create a CA certificate and import it for each user, and use certificates signed with it, I'd like to have some way to prevent them from adding exceptions. -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
