Univention Bugzilla – Bug 42494
Add Subordinate CA to univention-ssl
Last modified: 2016-09-26 10:17:16 CEST
Currently we create a root certificate for our own CA and use this root certificate to sign all the host certificates. Imho, it would be better to do the following: 1. Create a root certificate for a Root-CA that is valid for a long time 2. Create a subordinate certificate for a Sub-CA (or Intermediate-CA) that is valid for a shorter time 3. Sign all the host certificates with the subordinate certificate This would give customers more flexibility when renewing or replacing host certificates: Imagine that certain circumstances demand that all new certificates comply to a new standard (e.g. there's a policy for 'upgrading' the hashing algorithm or the key bit length). Currently, such a scenario might require to create a new root certificate which would lead to renewing the complete chain including all host certificates - and this is quite painful if you have several hundred clients or so (e.g. not all clients can be updated in a short time frame). With the proposed addition of a subordinate layer, it would be possible to create a new/second subordinate CA with the required settings. This new/second intermediate CA is then used to sign all new host certificates. The old/first subordinate CA would still be valid and could be faded out gently.
(In reply to Michael Grandjean from comment #0) > 1. Create a root certificate for a Root-CA that is valid for a long time ... > Imagine that certain circumstances demand that all new certificates comply > to a new standard (e.g. there's a policy for 'upgrading' the hashing > algorithm or the key bit length). > Currently, such a scenario might require to create a new root certificate > which would lead to renewing the complete chain including all host > certificates ... > With the proposed addition of a subordinate layer, it would be possible to > create a new/second subordinate CA with the required settings. The chain is as strong as its weakest link: If you created your root CA with the wrong algorithms/key sizes, you still have the original problem. Your proposed scheme doesn't give you anything except added complexity. (If you really wan't to start improving security, you should stop generating ALL certificates on the DC master and keeping the private key there UNENCRYPTED. Only the root CA private key is secured with a password, which itself is stored UNENCRYPTED next to is. All DC Backup also have a COMPLETE copy. Don't tell that any auditor, as that is against ANY best practice known to me)