Univention Bugzilla – Bug 54416
ID in CA common name not unique
Last modified: 2022-02-22 10:49:42 CET
ID in CA common name not unique We add a random id to the common name of the CA created during setup to differentiate between CAs for different domains. https://git.knut.univention.de/univention/ucs/-/commit/4a6127a2666295a34033a5d0e43bd7e62a7f4b6d One of our tests running on ec2 just created the same ID for two domains. The keys itself are still different but firefox doesn't like that (SEC_ERROR_REUSED_ISSUER_AND_SERIAL). This is probably a very specific problem to our tests and low entropy on ec2. But I still wouldn't have expected this to happen. I think we need a more robust solution here. Bug 34547 would probably solve this as well.
A school customer run in this issue after renewing his CA Certificate. Now he gets the Firefox message SEC_ERROR_REUSED_ISSUER_AND_SERIAL and what makes this more unattractive and critical, that the Apple school clients reject the new certificate. UCS: 4.4-8 errata1174 Installed: samba4=4.10 self-service=4.0 self-service-backend=4.0 ucsschool=4.4 v9 Ticket will follow
(In reply to Christina Scheinig from comment #1) > A school customer run in this issue after renewing his CA Certificate. Now > he gets the Firefox message SEC_ERROR_REUSED_ISSUER_AND_SERIAL and what > makes this more unattractive and critical, that the Apple school clients > reject the new certificate. > > UCS: 4.4-8 errata1174 > Installed: samba4=4.10 self-service=4.0 self-service-backend=4.0 > ucsschool=4.4 v9 > > Ticket will follow This sounds like a different problem. I think they created a new CA? If their private key for the root CA isn't compromised, they could instead just renew the old CA certificate. The help article https://help.univention.com/t/renewing-the-ssl-certificates/37#u-renew-the-root-certificate-u-2 does it that way. This is further discussed in bug 51749. But imho it boils to that we need a better way to manage certificates.
The customer renewed the certificate with our article https://help.univention.com/t/renewing-the-ssl-certificates/37 So they did not create a new CA.
BUT, the customer mentioned a little faux pas. During copy paste of the command openssl x509 -in CAcert.pem -out NewCAcert.pem -days "$(ucr get ssl/default/days)" -passin file:/etc/univention/ssl/password -signkey private/CAkey.pem -sha256 he missed to copy this part: "-signkey private/CAkey.pem -sha256" Some days later, he recognized the mistake and renewed the CA again, but not with the backuped CA. Could this the root cause? Would be a workaround to renew the CA again, but with the backup of the CA?
Yes "-signkey private/CAkey.pem -sha256" is an import part of that command :) Using the old CA with the right command should indeed solve the problem. You can check that by comparing the old backed up certificate with the renewed one. "openssl x509 -in CAcert.pem -noout -text" Only "Not Before", "Not After", and the signature (last part of the certificate) should differ.
(In reply to Jürn Brodersen from comment #5) > Yes "-signkey private/CAkey.pem -sha256" is an import part of that command > :) Using the old CA with the right command should indeed solve the problem. > > You can check that by comparing the old backed up certificate with the > renewed one. > > "openssl x509 -in CAcert.pem -noout -text" > > Only "Not Before", "Not After", and the signature (last part of the > certificate) should differ. Yes we tried this to diff the certificates, but we did not know, what we are looking for. So many thanks to make this clear and for the quick response here
The problem is that certificates have the same serial number despite different expiration dates. Certificates from the same issuer must have a different have a different serial number. https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.2<https://ldapwiki.com/wiki/Certificate%20Serial%20Number> The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. ---------------
(In reply to Jürn Brodersen from comment #5) > Yes "-signkey private/CAkey.pem -sha256" is an import part of that command > :) Using the old CA with the right command should indeed solve the problem. > > You can check that by comparing the old backed up certificate with the > renewed one. > > "openssl x509 -in CAcert.pem -noout -text" > > Only "Not Before", "Not After", and the signature (last part of the > certificate) should differ. In the new certificate and also in the "old" one only these three parts differ. So looks good, but is not working