On Sunday 06 Sep 2015 03:45:26 lee wrote: > Mick <michaelkintz...@gmail.com> writes: > > On Saturday 05 Sep 2015 14:06:27 lee wrote:
> >> 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 > > just different fqdns and IPs with which the server can be reached during > the lifetime of the certificate (which is only 10 years) > > Can you foresee all possible fqdns and IPs it might have in the next 10 > years? OK, 10 years is rather long for a common certificate. In this case you should consider setting up your own CA key and CA certificate, with which you sign the server certificates. Server certificates can expire and/or be revoked, you can update and publish a CRL, but the CA certificate will remain valid for 10 years. As long as the new server certificate is signed by the same CA certificate, the clients should not mind provided: 1. The client has accepted the CA certificate in its Authorities store and set up an exception to mark it as trusted. 2. The CN of the new certificate contains the URI that the client is trying to connect to. 3. The expiry date has not arrived yet. 4. The CRL does not contain the certificate (yet). > I think it would be retarded to bind a certificate to a fqdn or IP. Both > can change at any time. It's the certificate that counts and which can > be verified by a fingerprint before accepting it. The host name and IP > are entirely irrelevant for this. In some cases, you can even say that > the certificate is for an organization, not for a particular host or > device (operated by or being operated on behalf of the organization). When you change the domain or IP address on a server you typically change its certificate to reflect this too. You do not need to change the CA certificate. If you change the contents of the certificate then the fingerprint will change too. Certificate verification tests include more than just the fingerprint. > Or think of gpg: Binding a certificate to fqdn/IP would be like binding > my gpg public key to the place (like my postal address) I am at so that > I can decrypt something only when I happen to be at the right > place. Then give me an option to add multiple places to my pubkey when > creating it, and as soon as I'm at another place about which I haven't > foreseen that I might be there some time, I will have a problem. For > all I know, I could be travelling in a car or a train or an air plane. > > It's impractical. Change is a constant. Sure, but (although you could) gpg is not usually used to secure the connection to a server. A server's identity is interlinked with its domain name, or IP address. The identity for gpg is linked to the email address of its owner. You wouldn't sign/encrypt your work's email with the gpg key for your private email address. > > 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. > > At least that's possible. How would I add that without changing the > existing certificate? I don't want to irritate the users, don't want to > have the phone calls about it and don't want trouble with the odd client > which happens to have been updated and refuses to accept the certificate > ... > > See what I mean? It's impractical. Yes. It could be impractical at this stage, because the architecture of your PKI has to change. However, you can treat your existent self-signed certificate as a CA and use it to sign other certificates which contain different IP addresses, fqdns, etc. depending on the server(s) in question. If your clients have accepted your self-signed certificate as a CA, then it should not cause a problem. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
