On Sunday, September 06, 2015 3:03:12 PM lee wrote: > Fernando Rodriguez <frodriguez.develo...@outlook.com> writes: > > > On Saturday, September 05, 2015 6:09:36 PM Mick wrote: > >> 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? > >> > > [...] > > > > Wildcards should do it. The browser will give you a warning but you don't > > care since all you want is encryption and your users already trust you. > > True --- and the problem will be back again when seamonkey etc. decide > not to accept certificates with wildcards anymore. > > > The only thing that matters about that article is that you'll be signing your > > certificate with the CA ones so you get two certificates when you run the > > openssl command, the last one is the CA certificate. If you, or your users add > > trust to that one, anything you sign with it will be trusted. > > > > I only tried it with a windows server issued certificate which does all that by > > default. > > Changing the key would be a last resort. > > If I do that, should I use a SHA-3 key? Would that work, or is SHA-3 > too new?
You don't need to change the private key, you'll just have another CA cert and private key that you can use to sign your existing certificate (and generate a signed one). I suppose you may even be able to use the same key for both. > > Since it lets you open the exception dialog but just hangs when downloading > > the certificate I wonder if it has something to do with your OCSP settings. > > Check that they match mine: > > > > security.OCSP.GET.enabled false > > security.OCSP.enabled 1 > > security.OCSP.require false > > > > everything else is true. > > I checked, and we have the same settings. It doesn't really hang, it > does nothing when I try to get the certificate. Does it do something > when you try? It downloads the cert as expected. When I do it from the error page I don't even have to do that because it's already downloaded. What does it says under "Technical Details" on the error page? -- Fernando Rodriguez
