Generating a CRL in 2.5.0 throws error

[stclj]

Hello,

in XCA 2.5.0 we get an error when trying to generate a Certificate Revocation List (CRL). The error message is the same on MacOS and Windows:

(7pki_crl[]:Name of CA)
error:0300009C:digital envelope routines::unsupported algorithm
error:068C0100:asn1 encoding routines::malloc failure
error:068C0100:asn1 encoding routines::malloc failure
(pki_crl.cpp:250)

With XCA 2.4.0 it worked fine.

Tested on MacOS 12.x and 13.x as well as Windows Server 2019.

It would be great, if it could be fixed. Thanks in advance, Steffen

[stclj]

Obviously this issue is related to issue #468

The cause of the issue is a database that was created with XCA before 2.0.0. In 2.5.0 the support for database encryption with the old method used before 2.0.0 was removed. The XCA versions 2.0.0 to 2.4.0 can read the old encrypted databases but write only with the new method.

The "solution" is to go back to XCA 2.4.0 open the database and set a new database password - it can be the same. That way the news encryption is used and XCA 2.5.0 can use the keys again that are stored in the database.

@chris2511 it would have been nice, if you and incorporate a deprecation waring in XCA 2.0.0 - 2.4.0, if a database with old encryption is opened and suggest the user to set or reset the database password. For this issue it is too late 😕, but maybe in the feature if you plan to deprecate something a warning would be nice. (The developers of Ansible for example make an excellent job related to deprecation and warnings.)

But, Chris, thanks for your great work anyway. XCA is very helpful!

[combatlord]

Thank you for the very useful tip. Had the same problem. Your solution of just changing or re-entering the database password in this case works great.

Regards Chris

[chris2511]

it would have been nice, if you and incorporate a deprecation waring in XCA 2.0.0 - 2.4.0, if a database with old encryption is opened and suggest the user to set or reset the database password. For this issue it is too late 😕, but maybe in the feature if you plan to deprecate something a warning would be nice. (The developers of Ansible for example make an excellent job related to deprecation and warnings.)

This is usually what I do if I change things in an incompatible way. This issue just slipped through unnoticed by me. Anyway. I re-added the support for the the legacy keys (d32ab2e0d429d0a6fcfa088affcf825abc798a04) and will keep it for a while. XCA now also automatically transforms legacy keys (6d01928d5d74d9ceffd3665ae3a4d3629004a6f5) if it finds them.