CA upgrade in several aspects

[egoitz at ramattack.net]

Good afternoon, 

I'm running a CA, for generating the certificates for the backup clients
of my network and for the backup servers too. The certificates are used
for encrypting the backups stored in the servers and too, for
comunicating over TLS between severs and clients. 

This CA has some years now and the certificates I generate for new
clients, are not working (directly) in new machines. The reason for that
is that new operating systems, are requiring stronger signing
algorithms. When you try to start the service using that certificates
(bacula file daemon) in a fresh new Debian for instance, systemd throws
the following error : 

_OPENSSL.C:68 ERROR LOADING CERTIFICATE FILE: ERR=ERROR:140AB18E:SSL
ROUTINES:SSL_CTX_USE_CERTIFICATE:CA MD TOO WEAK_ 

I know you can fix that with the following change in openssl.conf : 

_####CIPHERSTRING = DEFAULT at SECLEVEL=2_ 

_CIPHERSTRING = DEFAULT at SECLEVEL=1_ 

But this last way, does not convince me... so I have started debugging
what exactly was causing the the problem. I saw, that sha1 is not
allowed as a signing valid algorithm for SECLEVEL 2. So, I tried moving
the CA to a more recent testing machine (with a newer OpenSSL
1.1.1l-freebsd), and I modified too in the openssl.conf of the CA (The
openssl.conf existing in the CA dir for generating certs and so...) : 

I have attached the old version. The new using version in the testing
machine, is the old one plus the below changes : 

- Added the line : "signer_digest  = sha256" 

- Modified the line : "digests        = md5, sha1" by "digests         =
sha1, sha256, sha384, sha512" 

- Added the line : "ess_cert_id_alg        = sha1" 

Now... I have generated a new certificate by following the normal
procedure... generate the key and csr... later sing new cert... etc
etc..... 

This new generated certificate (signed with sha256WithRSAEncryption
algorithm), has worked with a newer version of the Bacula client and in
a almost new Debian system. So it seems, just by generating new
certificates, using them in that new machines, with a newer os and
keeping the old ca certificate, at least the service has started. We
have too, another master public key for encrypting content (which is an
oldly generated certificate signed with sha1WithRSAEncryption) that we
keep in case a customer looses it's keys for avoiding a possible
disaster. 

I was wondering if some sort of problem could exist, by using those old
two certificates (the master public key and the old ca certifcate) with
the new generated certificate. 

Now, that I have that CA, for whose purpose seems to be working, I have
started thinking... some more... I have noticed that the CA certificate
will expire in 2024. I assume that what I would have to do before that
CA cert expires could be : 

- Generate a second ca cert for the CA. 

- Change the ca certificate to be used (for signing and issuing new
certs) in openssl.conf : 

_CERTIFICATE    = $DIR/CACERT-NEW.PEM     # THE CA CERTIFICATE_ 

- Sign again all the certificates in the CA... 

- Change, all certificates in the CA (except the own ca cert which is
already changed). 

- Finally replace in each servers and clients certs. 

Is this a correct procedure for upgrading a CA?. I assume it can be
correct. Isn't it?. I think this procedure shouldn't break nothing
related to serials of certificates and so in the own ca. Am I wrong?. 

Best regards, 

+are causing to set a special config in /etc/ssl/openssl.conf saying : "
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220512/d198b06c/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssl.conf
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220512/d198b06c/attachment.ksh>