Mick <michaelkintz...@gmail.com> writes: > 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.
I made it 10 years because you have to set a duration, and I didn't want to be bothered with certificates expiring. But I understand that I've been doing it kinda wrong because it would have been better to make a CA certificate which could be valid for a long time and sign certificates with it which don't last that long. Can I somehow deploy some sort of centralized infrastructure for clients to automatically get the CA certificates from? Otherwise, I would need to import the CA certificate for every user manually. > [...] > >> 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 > [...] > > 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. With gpg, the linkage to an email address was introduced a long time ago to make it easy to determine from an email address which key to use. Back then, people usually did have no more than one email address, perhaps another one at their work place, and most people didn't have any email addresses at all. That has changed. However, even back then, the email address wasn't used to identify a person. You could only know that, with a great deal of likelyness, an email --- sent from whatever email address --- was sent by a particular person when it was signed or encrypted with the key you definitely knew was that particular person's key. That has *not* changed. The same principle applies to certificates. So what sense does it make for a certificate to be linked to an FQDN or IP? None of those necessarily identify a particular server. If they did, the only purpose of certificates would be to assist encryption, and they wouldn't have anything to do with identification. --- You're using gmail (which I won't because of privacy concerns): Can you be sure that you connect to the same server every time you receive or send your emails? You probably don't. The underlying idea is trust. If you trust a CA --- and I don't see any particular reason to trust any of the CAs seamonkey knows by default and most, if not all of which, I've never even heard about --- a certificate signed by it is accepted without asking you. Is that good or bad? Back then, when I used gpg, I had my key signed by people I met personally and signed theirs. We would know by the fact that the key was used, not by any particular email address. So the identity for gpg is *not* linked to the email address of its owner. Nobody prevents you from encrypting or signing an email with your key and sending it from an arbitrary email address. Recipients may only conclude that it was you who sent the email by verifying that your key was used, and first they have to trust that this key is actually yours. You may need to explicitly specify the key-ID or an email address to tell gpg which key to use when you do that. Same goes for certificates, and there's no point in linking them to FQDNs/IPs. If they are linked for the practical reason to figure out which certificate to use, like gpg can use an email address to figure out which key to use, then I'd say that a better way needs to be found to do that. Similar to a key-ID specific to a key, certificates could have a certificate-ID --- perhaps they already do. >> > 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. When I look at one of the CA certificates seamonkey shows me, I don't see any specific FQDN or IP involved. Am I to understand that a CA certificate is like what I kinda wanted in the first place, i. e. something like a certificate which identifies an organization (rather than a device operated by the organization)? And that the CA certificate can be used (by the organization) to, well, certify that a particular device it operates is operated by the organisation by creating a certificate for the device and signing it with the CA certificate? If that is so, then why should I need or use one certificate for each device --- or for each service? I'm certifying myself that this is the particular organisation and that everything is fine, one way or another. So far, the true and only purpose of these certificates is to assist encryption. Unless I am able to give users, in a secure way, some means of verifying that a certificate they accept is actually from the organization, the certificates cannot be used for identification anyway. -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
