1 |
On Saturday 05 Sep 2015 14:06:27 lee wrote: |
2 |
> Fernando Rodriguez <frodriguez.developer@×××××××.com> writes: |
3 |
> > On Saturday, September 05, 2015 1:05:06 AM lee wrote: |
4 |
> >> In this case, I happen to have full physical access to the server and |
5 |
> >> thus to the certificate stored on it. This is not the case for, let's |
6 |
> >> say, an employee checking his work-email from home whom I might give the |
7 |
> >> login-data on the phone and instruct to add an exception when the dialog |
8 |
> >> to do so pops up when they are trying to connect. |
9 |
> > |
10 |
> > As a workaround you can create your own CA cert. I tested with a windows |
11 |
> > self- signed cert (I guess the correct term is self-issued) and the |
12 |
> > openssl command will show two certs. The second is the CA. |
13 |
> > |
14 |
> > http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certifica |
15 |
> > te-authority/ |
16 |
> |
17 |
> They're saying: |
18 |
> |
19 |
> |
20 |
> "Whatever you see in the address field in your browser when you go to |
21 |
> your device must be what you put under common name, even if it’s an IP |
22 |
> address. [...] If it doesn’t match, even a properly signed certificate |
23 |
> will not validate correctly and you’ll get the “cannot verify |
24 |
> authenticity” error." |
25 |
> |
26 |
> |
27 |
> What's the solution for a server which can be reached by different fqdns |
28 |
> and IPs? What if the fqdns and IPs it can be reached by change over the |
29 |
> lifetime of the certificates? |
30 |
|
31 |
If we are talking about changing subdomains, e.g. mailserver1.mydomain.com and |
32 |
mailserver2.mydomain.com then you could use a wildcard CN field descriptor in |
33 |
your certificate: *.mydomain.com |
34 |
|
35 |
If we are talking about a multidomain certificate, then you would have the |
36 |
main domain name in CN and add all the remaining domain names in the |
37 |
subjectAltName field. |
38 |
|
39 |
For example: |
40 |
|
41 |
[req] |
42 |
req_extensions = v3_req |
43 |
|
44 |
[ v3_req ] |
45 |
|
46 |
# Extensions to add to a certificate request |
47 |
[snip...] |
48 |
|
49 |
subjectAltName = @alt_names |
50 |
|
51 |
[alt_names] |
52 |
DNS.1 = mydomain.com |
53 |
DNS.2 = mydomain.net |
54 |
DNS.3 = www.mydomain.com |
55 |
DNS.4 = mx.sub.mydomain.com |
56 |
DNS.5 = mx.someotherdomain.com |
57 |
IP.1 = 123.456.78.9 |
58 |
IP.2 = 987.654.32.1 |
59 |
|
60 |
You could specify the same on the CLI when you are generating the self signed |
61 |
certificate. |
62 |
|
63 |
|
64 |
> How do I deploy some sort of central infrastructure all clients on the |
65 |
> LAN and anywhere on the world will automatically use to do the simple |
66 |
> thing of adding an exception (or whatever is required for that) so that |
67 |
> seamonkey and relatives can be used to access email? |
68 |
> |
69 |
> That's letting aside that it's ridiculous to deploy such an |
70 |
> infrastructure when the same thing could be achieved by the user |
71 |
> clicking a button once to add an exception, as it used to be. |
72 |
|
73 |
This I think is primarily a problem of the latest version of SeaMonkey. I |
74 |
suspect they have inadvertently added a regression bug. |
75 |
|
76 |
|
77 |
> Seriously? The result is currently a version freeze; the alternative is |
78 |
> using unencrypted connections. After some time, the version freeze |
79 |
> cannot be kept up. Since there are no alternative MUAs, we can only go |
80 |
> back to unencrypted connections when that happens. And that's something |
81 |
> I don't even want to do on the LAN. |
82 |
> |
83 |
> |
84 |
> Well, I've made a bug report about this: |
85 |
> https://bugzilla.mozilla.org/show_bug.cgi?id=1202128 |
86 |
|
87 |
Also have a look at this bug, in case it is related: |
88 |
|
89 |
https://bugzilla.mozilla.org/show_bug.cgi?id=1036338 |
90 |
|
91 |
-- |
92 |
Regards, |
93 |
Mick |