On Saturday 05 Sep 2015 14:06:27 lee wrote: > Fernando Rodriguez <frodriguez.develo...@outlook.com> writes: > > On Saturday, September 05, 2015 1:05:06 AM lee wrote: > >> In this case, I happen to have full physical access to the server and > >> thus to the certificate stored on it. This is not the case for, let's > >> say, an employee checking his work-email from home whom I might give the > >> login-data on the phone and instruct to add an exception when the dialog > >> to do so pops up when they are trying to connect. > > > > As a workaround you can create your own CA cert. I tested with a windows > > self- signed cert (I guess the correct term is self-issued) and the > > openssl command will show two certs. The second is the CA. > > > > http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certifica > > te-authority/ > > They're saying: > > > "Whatever you see in the address field in your browser when you go to > your device must be what you put under common name, even if it’s an IP > address. [...] If it doesn’t match, even a properly signed certificate > will not validate correctly and you’ll get the “cannot verify > authenticity” error." > > > What's the solution for a server which can be reached by different fqdns > and IPs? What if the fqdns and IPs it can be reached by change over the > lifetime of the certificates?
If we are talking about changing subdomains, e.g. mailserver1.mydomain.com and mailserver2.mydomain.com then you could use a wildcard CN field descriptor in your certificate: *.mydomain.com If we are talking about a multidomain certificate, then you would have the main domain name in CN and add all the remaining domain names in the subjectAltName field. For example: [req] req_extensions = v3_req [ v3_req ] # Extensions to add to a certificate request [snip...] subjectAltName = @alt_names [alt_names] DNS.1 = mydomain.com DNS.2 = mydomain.net DNS.3 = www.mydomain.com DNS.4 = mx.sub.mydomain.com DNS.5 = mx.someotherdomain.com IP.1 = 123.456.78.9 IP.2 = 987.654.32.1 You could specify the same on the CLI when you are generating the self signed certificate. > How do I deploy some sort of central infrastructure all clients on the > LAN and anywhere on the world will automatically use to do the simple > thing of adding an exception (or whatever is required for that) so that > seamonkey and relatives can be used to access email? > > That's letting aside that it's ridiculous to deploy such an > infrastructure when the same thing could be achieved by the user > clicking a button once to add an exception, as it used to be. This I think is primarily a problem of the latest version of SeaMonkey. I suspect they have inadvertently added a regression bug. > Seriously? The result is currently a version freeze; the alternative is > using unencrypted connections. After some time, the version freeze > cannot be kept up. Since there are no alternative MUAs, we can only go > back to unencrypted connections when that happens. And that's something > I don't even want to do on the LAN. > > > Well, I've made a bug report about this: > https://bugzilla.mozilla.org/show_bug.cgi?id=1202128 Also have a look at this bug, in case it is related: https://bugzilla.mozilla.org/show_bug.cgi?id=1036338 -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
