CA upgrade in several aspects

[Mark Hack]

NIST-800-131a deprecated SHA1 signatures in January of 2013 along with
RSA1024 bit keys. You should be issuing certificates with at least
RSA2048 with SHA2 signatures, and preferably at least RSA3072 with SHA-
384 signatures and if you are re-issuing CA certs more bits is better.
Nothing was said about CA certificates with SHA1 signatures and some
implementations will now reject these as non-compliant even if they
were issued before 2013.

On Thu, 2022-05-12 at 17:40 +0200, egoitz--- via openssl-users wrote:
> Please ignore the line below I said regards in my previous mail...
> it's there by error...
> 
> 
> cheers!
>  
> 
> 
> El 2022-05-12 17:38, egoitz at 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 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/9bebb890/attachment.htm>