1 |
On Sunday 06 Sep 2015 03:45:26 lee wrote: |
2 |
> Mick <michaelkintzios@×××××.com> writes: |
3 |
> > On Saturday 05 Sep 2015 14:06:27 lee wrote: |
4 |
|
5 |
> >> What's the solution for a server which can be reached by different fqdns |
6 |
> >> and IPs? What if the fqdns and IPs it can be reached by change over the |
7 |
> >> lifetime of the certificates? |
8 |
> > |
9 |
> > If we are talking about changing subdomains, e.g. |
10 |
> > mailserver1.mydomain.com and mailserver2.mydomain.com then you could use |
11 |
> > a wildcard CN field descriptor in your certificate: *.mydomain.com |
12 |
> |
13 |
> just different fqdns and IPs with which the server can be reached during |
14 |
> the lifetime of the certificate (which is only 10 years) |
15 |
> |
16 |
> Can you foresee all possible fqdns and IPs it might have in the next 10 |
17 |
> years? |
18 |
|
19 |
OK, 10 years is rather long for a common certificate. In this case you should |
20 |
consider setting up your own CA key and CA certificate, with which you sign |
21 |
the server certificates. Server certificates can expire and/or be revoked, |
22 |
you can update and publish a CRL, but the CA certificate will remain valid for |
23 |
10 years. |
24 |
|
25 |
As long as the new server certificate is signed by the same CA certificate, |
26 |
the clients should not mind provided: |
27 |
|
28 |
1. The client has accepted the CA certificate in its Authorities store and set |
29 |
up an exception to mark it as trusted. |
30 |
2. The CN of the new certificate contains the URI that the client is trying to |
31 |
connect to. |
32 |
3. The expiry date has not arrived yet. |
33 |
4. The CRL does not contain the certificate (yet). |
34 |
|
35 |
|
36 |
> I think it would be retarded to bind a certificate to a fqdn or IP. Both |
37 |
> can change at any time. It's the certificate that counts and which can |
38 |
> be verified by a fingerprint before accepting it. The host name and IP |
39 |
> are entirely irrelevant for this. In some cases, you can even say that |
40 |
> the certificate is for an organization, not for a particular host or |
41 |
> device (operated by or being operated on behalf of the organization). |
42 |
|
43 |
When you change the domain or IP address on a server you typically change its |
44 |
certificate to reflect this too. You do not need to change the CA |
45 |
certificate. |
46 |
|
47 |
If you change the contents of the certificate then the fingerprint will change |
48 |
too. Certificate verification tests include more than just the fingerprint. |
49 |
|
50 |
|
51 |
> Or think of gpg: Binding a certificate to fqdn/IP would be like binding |
52 |
> my gpg public key to the place (like my postal address) I am at so that |
53 |
> I can decrypt something only when I happen to be at the right |
54 |
> place. Then give me an option to add multiple places to my pubkey when |
55 |
> creating it, and as soon as I'm at another place about which I haven't |
56 |
> foreseen that I might be there some time, I will have a problem. For |
57 |
> all I know, I could be travelling in a car or a train or an air plane. |
58 |
> |
59 |
> It's impractical. Change is a constant. |
60 |
|
61 |
Sure, but (although you could) gpg is not usually used to secure the |
62 |
connection to a server. A server's identity is interlinked with its domain |
63 |
name, or IP address. The identity for gpg is linked to the email address of |
64 |
its owner. You wouldn't sign/encrypt your work's email with the gpg key for |
65 |
your private email address. |
66 |
|
67 |
|
68 |
> > If we are talking about a multidomain certificate, then you would have |
69 |
> > the main domain name in CN and add all the remaining domain names in the |
70 |
> > subjectAltName field. |
71 |
> > |
72 |
> > For example: |
73 |
> > |
74 |
> > [req] |
75 |
> > req_extensions = v3_req |
76 |
> > |
77 |
> > [ v3_req ] |
78 |
> > |
79 |
> > # Extensions to add to a certificate request |
80 |
> > [snip...] |
81 |
> > |
82 |
> > subjectAltName = @alt_names |
83 |
> > |
84 |
> > [alt_names] |
85 |
> > DNS.1 = mydomain.com |
86 |
> > DNS.2 = mydomain.net |
87 |
> > DNS.3 = www.mydomain.com |
88 |
> > DNS.4 = mx.sub.mydomain.com |
89 |
> > DNS.5 = mx.someotherdomain.com |
90 |
> > IP.1 = 123.456.78.9 |
91 |
> > IP.2 = 987.654.32.1 |
92 |
> > |
93 |
> > You could specify the same on the CLI when you are generating the self |
94 |
> > signed certificate. |
95 |
> |
96 |
> At least that's possible. How would I add that without changing the |
97 |
> existing certificate? I don't want to irritate the users, don't want to |
98 |
> have the phone calls about it and don't want trouble with the odd client |
99 |
> which happens to have been updated and refuses to accept the certificate |
100 |
> ... |
101 |
> |
102 |
> See what I mean? It's impractical. |
103 |
|
104 |
Yes. It could be impractical at this stage, because the architecture of your |
105 |
PKI has to change. |
106 |
|
107 |
However, you can treat your existent self-signed certificate as a CA and use |
108 |
it to sign other certificates which contain different IP addresses, fqdns, |
109 |
etc. depending on the server(s) in question. |
110 |
|
111 |
If your clients have accepted your self-signed certificate as a CA, then it |
112 |
should not cause a problem. |
113 |
|
114 |
-- |
115 |
Regards, |
116 |
Mick |