> From: openssl-users <openssl-users-boun...@openssl.org> On Behalf Of > egoitz--- via openssl-users > Sent: Thursday, 17 March, 2022 12:52
> 1 - Is it possible to update a whole CA with 2048 bit public and private keys > (I used in req section of openssl.conf, the default_bits to 2048) to a > Signature > algorithm that don't bother the SECLEVEL 2?. I mean to have two versions of > the > same certificate. One for SECLEVEL1 and one for SECLEVEL2?. I preserve all > csr and > so.... It's not clear to me exactly what you're thinking of doing here. Usually what I'd do is create a new intermediate signing certificate with a modern signing algorithm, such as sha256WithRSAEncryption or an ECC equivalent, and a suitably strong key (I use a 4096-bit RSA key even for my RSA testing, to catch out implementations that don't support adequately-strong keys). Then I'd use that to generate entity certificates. Presumably your client systems already trust your existing root, so replacing that is extra work. If you've been signing entity certificates with the root, then 1) stop doing that, and 2) create a new root with a different Subject CN and suitable parameters. You'll need to distribute that new root to your client systems. > 2 - I was wondering too another question... although this is not urgent now. > If the CA key pair, is almost expiring what's the proper process of doing what > is supposed to be done? Keys don't expire. That is, PKIX separates private keys from certificates; the latter expire, but the former do not. You can issue a new certificate that contains the same public key as an expired certificate. That said, many people do periodically rotate keys. There is a great deal of (often tiresome and unenlightening) debate on this question, so I'm not going to express an opinion on whether you should do this, particularly if this is not a public CA, where key rotation would appear to be of minimal benefit. (Whoops.) Also, CAs normally don't have a single keypair. They have one for the root certificate, which should only be used to sign intermediate signing certificates; and one for each intermediate. Again, if you're signing entity certificates with the CA root, don't do that. Why not? - If this is a real CA, i.e. the certificates it issues are used to protect anything of value, then you want to strongly protect the root's private key (preferable don't have it online at all, but on removable media or in an HSM). You want to be able to revoke a signing certificate if its key is compromised, and that's a lot less distruptive if an intermediate is used to sign, particularly if your entities send complete chains (or at least the signing intermediates), because then peers don't have to include the intermediates in their trust stores. Using intermediates also lets you partition your signing: intermediate X to sign this type of certificate, intermediate Y to sign this other type (or X to sign servers in this part of the organization, or whatever). - If this is a test CA, it's better to test with a realistic PKIX hierarchy, and real hierarchies use intermediates. If the CA root certificate is about to expire, then you'll need to create a new root. You can do that using the same Subject DN (if you revoke the old root) and Subject Key Identifier (SKID), which means your client systems can just update their trust stores with the new certificate and your server certificates should continue to work (until they expire). -- Michael Wojcik
