Univention Bugzilla – Bug 51749
Instead of renewing CA just renew their certificate
Last modified: 2020-07-30 21:19:23 CEST
Following https://help.univention.com/t/renewing-the-ssl-certificates/37 customer have to renew the CA which leads to a new certificate for the CA but with the same serial #. Standard does not allow multiple serial# within the same CA but we build a new CA so having the same serial# is allowed. The process of creating new certificates and distributing them to the other UCS hosts takes some time. In the meantime browsers are still accessing the hosts- getting a host certificate signed by the old CA or host certificates signed by the new CA. To prevent browser error about "self-signed" certificate Firefox (I assume other browsers might have the same issue) FF should know the old AND the new CA's certificate. This will break functionality in Firefox as it does not allow to have multiple certificates for the same CA with same serial numbers. So for the transition time users will get errors which is unwanted (and unneeded). So question arise: why do we re-deploy the full CA when creating a new certificate with a new serial # would be sufficient?
(In reply to Christian Völker from comment #0) > Following https://help.univention.com/t/renewing-the-ssl-certificates/37 > customer have to renew the CA which leads to a new certificate for the CA > but with the same serial #. You don't have to re-new the CA if you only want to do that for a singel host: By default our self-created CA certificate is valid openssl x509 -noout -text -in /etc/univention/ssl/ucsCA/CAcert.pem -certopt no_header,no_version,no_serial,no_signame,no_subject,no_issuer,no_pubkey,no_sigdump,no_aux,no_extensions > Validity > Not Before: May 2 10:33:58 2019 GMT > Not After : Apr 30 10:33:58 2024 GMT Host certificates are valid for 5 years by default: > ssl/default/days: 1825 > So question arise: why do we re-deploy the full CA when creating a new > certificate with a new serial # would be sufficient? Please also note the other two articles: - <https://help.univention.com/t/renewing-the-complete-ssl-certificate-chain/36> renew everything - <https://help.univention.com/t/how-to-extend-the-end-date-of-the-ucs-ca-root-certificate/974> extend live-time similar to 37 The problem here is our host certificates are directly created by the ucsCA: The issuer of the host certificates contains the serial number of the ucsCA! So when you create a completely *new* ucsCA, it gets a completely new serial# and thus has no reference to the already existing host-certificates. If on the other hand you *extend* the live-time of your ucsCA, it will keep the serial# and thus all host-certificate will also stay valid. You should do this way *before* the ucsCA expires and is still valid. (I don't remember right now if the ucsCA.notBefore < host.notBefore must be met) If you want to create a completely new CA you normally insert a intermediate CA, which creates the host certificates. The rootCA is only there to sign the intermediateCA. For key-rollover the newRootCA re-signed the intermadiateCA and oldRootCA, but oldRootCA also signs newRootCA, so that you always have a valid path from rootCa to hostCert: oldRootCA -> intermadiateCA -> hostCert oldRootCA -> newRootCA -> intermediateCA -> hostCert newRootCA -> oldRootCA -> intermediateCA -> hostCert newRoot -> intermediateCA -> hostCert So by the time oldRootCA expired you will still have the last path to hostCert. The same applies to key-rollover of the intermediateCA: in that case you have to re-sign all hostCerts and distribute them to the hosts. Because of that hostCerts are only valid for a short time (~1y, LetsEncrypt: 90d) so you're forced to do that on a regular basis anyway. (and commercial CAs can bill you more often). rootCA and intermediateCA on the other hand a valid for a long time (10-20y) by default, as it is painful to do those cross-signs on a regular basis. There even is a RFC for that: <https://tools.ietf.org/html/rfc6489> A good enterprise OS would re-new the hosts certificates on a regular basis and even would allow services to use two certificates at the key-roll-over-period.