Generating a CRL in 2.5.0 throws error about xca HOT 3 CLOSED

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!

from xca.

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

from xca.

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 (d32ab2e) and will keep it for a while.
XCA now also automatically transforms legacy keys (6d01928) if it finds them.

from xca.