On Sunday 06 Sep 2015 15:29:25 lee wrote: > Mick <michaelkintz...@gmail.com> writes: > > On Saturday 05 Sep 2015 17:22:24 lee wrote:
> >> Maybe that only works with firefox? > > > > Yes, it seems to be the case that SeaMonkey has some GUI differences to > > Firefox. I am on Firefox-38.2.1 at present. > > Does Firefox even have a MUA built in? IIRC it's only the web browser > part of seamonkey. No, but T'bird uses the same SSL certificate storage as the mozilla browser does. > > I can't recall if you tried this: > > > > Can you please remove it from Servers and try adding it to the > > Authorities tab? Your version may have additional verification checks > > for self-signed certificates, because they essentially acting as their > > own Root CAs. > > Yes, I tried that. Right, I saw your email. From what I can gather this is a bug impairing critical functionality of the Mozilla suite. > > The fact that it is hanging and not obtaining the certificate makes me > > wonder if you need to specify a domain name in the CN field of the > > certificate, identical to the full URI that the client is trying to > > connect to. > > That brings us back to the impractical idea of trying to bind a > certificate to a specific fqdn or IP, or to a number of those. > > 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. 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. > When creating the certificate, I have used the fqdn the host does > actually have and knows itself by (because I needed to fill in the > fields, and it seemed most reasonable to use the actual host name). > > That this host can be reached at all, via different fqdns and IPs, is a > matter of network traffic (re-)direction and of how the DNS-entries > currently happen to be. They are all transparent and irrelevant to the > user/client and subject to change. Why should they matter for a > certificate which is supposed to let me figure out whether I'm > connecting to the host I'm expecting to connect to, or to something > else? > > 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. You do not reject their call and insist > that they are not your friend because the call has been (re-)directed > over a satellite or goes through an asterisk server. You do not insist > that your friend is someone else when they show up at your door wearing > different cloths than they usually do. Instead, you figure out that the > caller, or the person at your door, is your friend by the human > equivalent of a certificate. 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. :-) 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. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
