Best practice and functioning inquiries

[aleloco09]

Hello,
I am back again, I am almost ending my thesis project, finally, and I have some questions about best practices and how the framework works:

1. For security reasons my idea is to revoke ManagementCA and use a custom RootCA to manage the administrators and the server certificate. This would allow me to create and store my own private keys more safely and without depending on the default settings of the EJBCA Container Quickstart. Do you think that this migration actually makes sense? In case, any hint on the steps to perform to achieve this?
2. If I have a Crypto Token associated to a HSM, like SoftHSM, who creates the keypairs? the HSM or EJBCA?

That's all for the moment, whenever I have other generic questions I will post them here.
Thanks.

[primetomas]

1. Also in the quick-start the keys for the Management CA are your own. It's not shared or anything but uniquely generated for you in your installation. Anyhow to switch to another CA is easy. Create a new CA, issue certificates, and the new certificates to Roles and Access Rules in EJBCA. Once you are happy, revoke and delete the old ones.
2. When an HSM is used key pairs are generated by the HSM.

[primetomas]

And can you show certificate attributes for the Polito Super Admin for example?

[aleloco09]

Then you should be more or less "home". What does your superadmin role look like?

It is exactly the Super Administrator Role described in step 7 of the Tutorial - Start out with EJBCA Docker container.

And can you show certificate attributes for the Polito Super Admin for example?

Those two are my certificates:

And I cannot really find any relevant difference with the SuperAdmin one:

For your information this is the role page, I have also tried without success to match with the serial number instead of the CN:

[primetomas]

Are you sure the client and server supports SHA3? I do not recommend using that. Publicly trusted TLS CAs do not use SHA3 and to my knowledge no-one recommends using it today. I would revert to SHA2 and test that.

[primetomas]

In addition, you are using EC, but have KeyEncipherment as KeyUsage. This is also not allowed. If you use EC you must remove KeyEncipherment. For TLS certificates in general, only use DigitalSignature.

[aleloco09]

I do not recommend using that. Publicly trusted TLS CAs do not use SHA3 and to my knowledge no-one recommends using it today. I would revert to SHA2 and test that.

Oh that was my mistake, I must have configured the CA putting SHA3-512 instead of SHA512. I have created a new CA using the correct signature algorithm and now it works! Thanks.

Now I have a more theoretical question about what you said here:

In addition, you are using EC, but have KeyEncipherment as KeyUsage. This is also not allowed. If you use EC you must remove KeyEncipherment. For TLS certificates in general, only use DigitalSignature.

Actually I just followed your video tutorials on how to create a TLS Server/Client certificate, where you use EC and do not clear KeyEncipherment in the KU of the certificate profile. Can you tell me why EC is not recommended for KeyEncipherment?

[aleloco09]

I have another question that links to discussion #416. I have set an external VA following the steps in the tutorial but I have problems issuing the requests from the VA.
If I send the request directly to the CA (whose server is mapped in port 80 of the host) i get this kind of response:

[user@PC192 containersVA]$ openssl ocsp -issuer ./PoliTOSubCA.pem -CAfile ./PoliTOSubCA-chain.pem -cert ./s292486.pem -req_text -url http://localhost:80/ejbca/publicweb/status/ocsp
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: F01B192F14B9EBA651009948E18354A6D3569E5B
          Issuer Key Hash: 85BF3EF18D60480E0EE7D7453C8E4BAB4E4F944F
          Serial Number: 7BD72345DBE1153339E93E277273698F9771F65B
    Request Extensions:
        OCSP Nonce: 
            0410E509BF8FEF27463834371CECA7C8A0D0
Response verify OK
./certificates/EndEntities/TLS_client_first/s292486.pem: good
	This Update: Mar  6 17:42:59 2024 GMT

While if I send to the VA (mapped to port 81) i get an error:

[user@PC192 containersVA]$ openssl ocsp -issuer ./PoliTOSubCA.pem -CAfile ./PoliTOSubCA-chain.pem -cert ./s292486.pem -req_text -url http://localhost:81/ejbca/publicweb/status/ocsp
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: F01B192F14B9EBA651009948E18354A6D3569E5B
          Issuer Key Hash: 85BF3EF18D60480E0EE7D7453C8E4BAB4E4F944F
          Serial Number: 7BD72345DBE1153339E93E277273698F9771F65B
    Request Extensions:
        OCSP Nonce: 
            04107303B67F05E47BACA4192A1126456D8B
Responder Error: unauthorized (6)

What is wrong with the request?

[primetomas]

EJBCA does not read the CRL when answering OCSP queries, but CertificateData entries. So certificate entries must be in the database.
You can find this in the documentation if you really read everything in detail, admittedly not trivial :-).

So if you are coming from a CRL you need to unpack the CRL to populate the OCSP database with the entries from it. There are many ways to do that.

• script and SQL...
• CRL download and update service: https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/services/crl-download-and-crl-update-service
• CLI command "bin/ejbca.sh ca importcrl --help"
• probably more...

[aleloco09]

Ok this confuses me more. Actually my VA database is populated Using the CRL Download Service.
Also, if I enable OCSP protocol in the CA and make an OCSP request directly to the CA (where CertificateData entries are present) the repsonse is the same, the certificate seems to be revoked (which is right) but the reason is UNKNOWN(expected: Privilege Withdrawn).
I don't know if am losing any detail from the documentation, but I am pretty sure I have followed the guide.

[primetomas]

OCSP can only answer OK, REVOKED or UNKNOWN (see RFC6960). The reason code is something else. But you expect REVOKED instead of UNKNOWN.
There can be several reasons for this. If you enable DEBUG logging in EJBCA you will be able to see the description of why a specific answer is returned.

[aleloco09]

Ok, no so everything is fine because as you can see here it says revoked

Response verify OK
./certificates/EndEntities/TLS_client_first/revoked_cert.pem: revoked
	This Update: Mar  8 11:37:48 2024 GMT
	Reason: (UNKNOWN)
	Revocation Time: Mar  8 11:16:13 2024 GMT 

But since it reports also a Reason field I thought I should expect the reason as well. Sorry

[primetomas]

Ah, ok so generally ok. But I guess reason code could be analyzed more. If OCSP reports reason code, it should be the one reflected in the database row in CertificateData for the certificate.

[aleloco09]

I have a new question. Is it possible to "migrate" the keys from a Soft Crypto Token to an HSM token, like SoftHSM?

[primetomas]

That is possible. Then you use HSM tools to import keys into the HSM. See you HSMs documentation. Note that all objects needed for Java PKCS#11 provider needs to be created. See the HSM documentation in EJBCA for details on that.

Doing so is however NOT best practice. Since your keys were generated outside an HSM there is not guarantee that they are not copied around. So putting these keys inside an HSM gives a false sense of security as they may already be copied. I.e. the purpose of an HSM is to make it hard to copy the private key.