I have the following system:

  1. 2 application servers. At the beginning is installed the first server and later is installed the second one.
  2. A client access from a browser to both servers
  3. Application servers communicate between them using Client Certificate over HTTPS

enter image description here


  1. A browser should trust application server (e.g. a site should be shown by a browser without SSL warnings).
  2. One customer deployment can not access to other customer deployment

I want to use the following design:

enter image description here

  1. Before installation of servers a Custom self-signed CA is created. Custom CA will be used for signing of server certificates. Note: if a customer want to use a CA signed by trusted root authority (e.g Verisign), he will required to sign it and provide it back to our system.
  2. Custom CA Public Key is installed in the trust store of a browser.
  3. During installation of a server a server key is generated (SubjectDN is IP of the server) and installed in the key store the server. Also, Custom CA Public Key is installed in the trust store of the server.


  1. Any improvements?
  2. What is recommended valid time for created Custom CA and for server keys?
  3. When can I store Custom CA in the customer environments? I can not modify the system installation it a customer environment.

1 Answer 1


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.

  • Thank you for the detailed answer! Clarifications: 1) If in our system browsers (and other HTTPS clients) access by IP I suppose I need to put in subjectDN the server IP. Correct? 2) I consider to put CA in a dedicated key store and protect it by a good password. Then, to copy it from one server to another during installation and finally to save it in the secure place. Is it good approach?
    – Michael
    Jun 3, 2013 at 3:42
  • You need to put in the certificate (preferably in a Subject Alt Name extension, the subjectDN being only used as a fallback) exactly what the HTTPS client will expect to find. HTTPS client look for a server name, never for an IP address. You need to put the server name as it appears in the URL that the client uses.\ Jun 3, 2013 at 11:36
  • 1
    As for the CA: the private key should be kept as safe and confidential as possible, so don't copy it everywhere. The more you copy some secret data, the less secret it becomes. Servers and clients don't need the CA private key, only the CA public key (that one you want to copy everywhere: it is public). The CA private key is used to issue new certificates (for servers) and to sign the CRL. Jun 3, 2013 at 11:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .