First let's note that each of your servers will nominally have two keys and corresponding certificates. One is for use as a server in the SSL sense (when the browser, or another server, connects to the machine), and the other is for use as a client (when the machine itself connects to another server). You can arrange for both keys (and certificate) to be the same, but this can add a few constraints. An asymmetric key pair can be used for key exchange or for digital signatures, but not all algorithms support both; also, the certificate itself can further restrain usage to only signature, or only key exchange, through its
Key Usage extension. In SSL, when using one of the basic RSA-based cipher suites (e.g. the very common
TLS_RSA_WITH_AES_128_CBC_SHA), the server key is used for key exchange (i.e. asymmetric encryption of a secret key randomly generated on the client side), but certificate-based client authentication necessarily uses a signature.
Therefore, if you want to have one private key per server, then you must arrange for either of the following:
- The server key has type RSA and the certificate allows for both encryption and signatures.
- The certificate allows for (at least) signatures, and you configure the servers to use only the "DHE" cipher suites (the key exchange part is then done with an ephemeral Diffie-Hellman key pair which the server generates on-the-fly, and the server key is used only for signatures).
The DHE cipher suites are, generally speaking, recommended because they offer Perfect Forward Secrecy: data exchanged over the wire cannot be decrypted afterwards, even if the attacker steals a copy of the server private key.
If you do not want browser warnings, then you should not put the server IP address in the subjectDN but the server DNS name. Browsers (and, more generally, all HTTPS clients), when they connect to a server, want to find in the server certificate the expected server name, i.e. the one which appears in the URL. They want to find it in a
Subject Alt Name extension (with type
dNSName) or, if such an extension is altogether lacking, in the Common Name of the subject DN. This lookup is for the name only, not for the IP address. This is described in section 3.1 of RFC 2818.
There is no conceptual problem in looking up IP addresses in certificates; it is just that existing browsers don't do that. So stick to names. Besides, names are handy when infrastructures migrate (the IP can change, but the names will remain the same, thus not requiring a new certificate issuance).
That being said, for your exact questions:
Certificate validity can be as long as you are comfortable with, with the following caveats:
Technology progresses over time, so what is thought as a robust key may turn out not to be that robust after a while. So you may want to limit key lifetime so that some operation will be needed, forcing you to reconsider your key size choices regularly. If you use 2048-bit RSA you ought to be good for the foreseeable future, i.e. for the next 20 years or so (further than that, there is no foreseeing, only speculation).
The year 2038 problem may imply some interoperability issues if you choose an end of validity date beyond January 18th, 2038.
You want a handy procedure to cover the case of key compromise (e.g. a purloined backup tape), and "waiting for the certificate to expire" is not very workable if the certificate lifetime is beyond, say, one week. See below.
The CA is crucial for security, so a prudent deployment would be to put it on an offline machine. No network at all means no possible remote hacking, and that's a good thing. However, as explained above, you need "something" to cope with compromise situations, which can be one of the two following things:
You issue only very short-lived certificates, e.g. every week a new certificate good only for one 10 days. Each server receives a new certificate every week. If a private key is stolen, the thief only has ten days to play with it, because afterwards you will not issue new certificates for that specific key.
You use certificate revocation lists: the CA regularly publishes (e.g. each week) a new signed CRL, which contains the serial numbers of the revoked certificates. Clients (browsers and other servers) will download that CRL to check that the server certificate is still good. This is mathematically equivalent to the scenario with the short-lived certificates.
Short-lived certificates have the advantage of keeping browsers out of the loop (only servers will need to be aware of it), but CRL are more likely to be supported out-of-the-box by SSL implementations. To support CRL, you need to put a
CRL Distribution Point extension in the certificates.
Either way, your CA will have to push some data elements to remote servers on a regular basis, be they renewed certificates or CRL. This is at odds with the concept of an offline CA. Some solutions imply a physically one-way link (some people use 10baseT ethernet with only one pair of wires connected; I have also, once, deployed a system where CRL are encoded over an audio link, because the line out audio jack is electronically one-way).
I expect most of your customers to put the CA on the same machine than their first server, then forget about it, and be very sorry when their server gets hacked into.