[BUG] Can't export CA keys after chaning keyEncryptKey from EC to RSA

[mwllgr]

Describe the Bug

I'm trying to export a secp384r1 CA key which has an RSA-4096 keyEncryptionKey set.
Upon entering the SoftToken password in the "CA export requires the token authentication code" field, I only get the following error:

org.bouncycastle.operator.OperatorCreationException: cannot create signer: can't identify EC private key.

To Reproduce

Steps to reproduce the behavior:

1. Create secp384r1 CA with RSA-4096 KEK
2. Try to export the keys

Expected Behavior

I should get the .p12 file with private key.

Screenshots and Logs

Log export: https://p.kll.li/?7c9917406abc71ee#GDW2VT5TPhvMDeU1P5vngBASKhuwxoeQ3H87ogiri2Lb
(Docker container)

Product Deployment

Please complete the following information:

• Deployment format: Docker
• Version 9.3.7 Community

[primetomas]

I can not reproduce this. I:

• started an instance of the latest container (9.3.7)
• went into the Management CA crypto token and generated a P384 key
• edited the crypto token to allow export of keys
• created a CA using the newly generated P384 key and SHA384WithECDSA
• went into edit CA and exported keys on the bottom of the page
• received a p12 file

[mwllgr]

Hi @primetomas and thanks for the quick response. I think I found a way to reproduce it.

My CAs started with four keys in the respective crypto token (Allow export set to true):

1. ct_ic-private-clt_default / ECDSA / P-384 (used as defaultKey in CA)
2. ct_ic-private-clt_kek / ECDSA / P-384 (used as keyEncryptKey in CA)
3. ct_ic-private-clt_sign / ECDSA / P-384 (used as certSignKey in CA)
4. ct_ic-private-clt_test / ECDSA / P-384 (used as testKey in CA)

Upon trying to export the keys on bottom of CA page, I got the following error:

Key encryption key must be set to RSA key to allow key export.

So, I decided to delete key #2 from the crypto token and generate a new one as RSA 4096:

2. ct_ic-private-clt_kek / RSA / 4096

When trying to export the key now, the error appears:

org.bouncycastle.operator.OperatorCreationException: cannot create signer: can't identify EC private key.

However, when I create a CA which starts out with the keyEncryptKey already being RSA, the export works flawlessly. So the bug seems to be when changing the keyEncryptKey from P384 to RSA4096 after the CA has already been created (which I thought I could do, as I don't use key recovery).

I don't really understand how you're able to export the keys with the KEK being set to a P384 key at all - because this always returns the error that it has to be an RSA key for me.

[primetomas]

How did you change the key encrypt key? Using the CLI?
Using an EC keyEncrypt key is no longer supported btw, EC works horribly for that using HSMs, too varying functions in different HSMs.

[mwllgr]

I basically just deleted the old keyEncryptKey from the crypto token and generated a new one with the same name but in RSA-4096. I thought that'd be fine because I did not enable key recovery. All using the web interface.

[primetomas]

There is a CLI command to switch a CA to use different keys. If you use "bin/ejbca.sh ca changecatoken" instead, changing to a new key. Does that work? It would be the official way to do it.

[mwllgr]

I found that command but was unsure on how to change only the keyEncryptKey used. Could you give me an example on how to execute the command? (Which params?). Otherwise I'd somehow have to clone the existing soft token to make sure to use the existing signing keys after changing the CA token.

And as to why I want to export the keys at all: I want to import them into a PKCS#11 HSM (NitroKey 2)

[primetomas]

"bin/ejbca.sh ca changecatoken --help" gives a decent overview I think.

bin/ejbca.sh ca changecatoken --caname myca --cryptotoken --tokenprop myproperties.txt

There is example properties file content if you run with --help.

[primetomas]

Oh, I wouldn't be responsible if I didn't say that taking keys that has been in pure software storage and importing into a hardware module is bad practice. The keys have been exposed outside the hardware already so the hardware module can't guarantee that your keys haven't already been exposed. Best practice is to generate keys in the hardware token, create a new CA, and migrate users/devices to trust that new CA instead.

[mwllgr]

Sure thing! Don't worry, this is only in a lab environment - so it's all testing. Appreciate the advice tho :)
Got the same error after changing the keyEncryptKey using this method, sadly.

My token.properties (called test.properties):

defaultKey ct_ic-private-clt_default
certSignKey ct_ic-private-clt_sign
crlSignKey ct_ic-private-clt_sign
keyEncryptKey ct_ic-private-clt_kek_rsa

The command I executed:

./ejbca.sh ca changecatoken --tokenprop test.properties --caname ca_ic-private_clt --cryptotoken ct_ic-private_clt --execute

The output:

2026-04-08 15:07:50,740+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) CA 'ca_ic-private_clt' references crypto token 'ct_ic-private_clt'
2026-04-08 15:07:50,740+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) New crypto token: ct_ic-private_clt
2026-04-08 15:07:50,740+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) CA token properties: test.properties
2026-04-08 15:07:50,740+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) 
2026-04-08 15:07:50,744+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) Current crypto token and new crypto token are the same, continuing in order to update CA token properties.
2026-04-08 15:07:50,763+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) Changing  CA 'ca_ic-private_clt' that currently references crypto token 'ct_ic-private_clt' to instead reference 'ct_ic-private_clt'.
2026-04-08 15:07:50,764+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main)  CA token properties that will be updated: {certSignKey=ct_ic-private-clt_sign, keyEncryptKey=ct_ic-private-clt_kek_rsa, crlSignKey=ct_ic-private-clt_sign, testKey=ct_ic-private-clt_test, defaultKey=ct_ic-private-clt_default}
2026-04-08 15:07:50,833+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main)  Merged.
2026-04-08 15:07:50,834+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) 
2026-04-08 15:07:50,834+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) Modified referenced Crypto Token for CA.
2026-04-08 15:07:50,877+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) CA 'ca_ic-private_clt' now references crypto token 'ct_ic-private_clt'
2026-04-08 15:07:50,877+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) New CA token properties: {certSignKey=ct_ic-private-clt_sign, keyEncryptKey=ct_ic-private-clt_kek_rsa, crlSignKey=ct_ic-private-clt_sign, testKey=ct_ic-private-clt_test, defaultKey=ct_ic-private-clt_default}
2026-04-08 15:07:50,877+0000 INFO  [org.ejbca.ui.cli.ca.CaChangeCryptoTokenCommand] (main) 

[primetomas]

Aha, you are right. It's hidden inside the 'catoken' data in the CAData. There is a field there 'encryptionalgorithm'.
You can see it with "select data from CAData where name='ManagementCA';". There is currently no way to change that with a command as far as I can see.
We're working on making it possible to use ML-KEM (PQC) for encrypting key recovery data however, so we'll have to implement a way to change from RSA to ML-KEM anyhow so it should come.

In the meantime the only way to edit it seems to be to go into the database.