Please ignore the line below I said regards in my previous mail... it's there by error...
cheers! El 2022-05-12 17:38, ego...@ramattack.net escribió: > 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@SECLEVEL=2_ > > _CIPHERSTRING = DEFAULT@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 : "
