Revocation of certificate failed after upgrading to 8.2.0 - WFLYEJB0034: Jakarta Enterprise Beans Invocation failed #494
-
|
Hello Community, I am having an issue revoking some certificates after the upgrade to EJBCA 8.2.0. Trying to revoke certificate from This happens on some of the certificates, not all of them. Looking into the database, there are no obvious differences between the certificates that can be revoked, and certificates that will throw an exception when trying to revoke. Moreover, the certificate that failed to be revoked through the Does anyone have or had similar issue? Can you advise what can be an issue here? I am running with database MariaDB Server version: 10.3.39-MariaDB-0+deb10u1 Debian 10, with OpenJDK 17, and on the Wildfly 26.1.2.Final. I was trying to downgrade to OpenJDK 11, but the problem persists. With best regards, |
Beta Was this translation helpful? Give feedback.
Replies: 9 comments 17 replies
-
|
We have not heard of this before. Are you running with database.useSeparateCertificateTable=true or false (default is false)? |
Beta Was this translation helpful? Give feedback.
-
|
Default value is used, therefore I have a simple |
Beta Was this translation helpful? Give feedback.
-
|
Are any publishers used? |
Beta Was this translation helpful? Give feedback.
-
|
A debug log previous to these failed revocations may reveal some interesting information. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, there are couple of Publishers that are active, however, any of these Publishers are not selected for this particular Certificate Profile or Authority, so it should not trigger any Publisher when revoking certificate. Here is the DEBUG log before the exception: |
Beta Was this translation helpful? Give feedback.
-
|
This was an Admin UI revocation. Did you search for end entity->view certificate->Revoke? I did the same and I get this additional log line: |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it was done in the Admin UI search for end entity->view certificate->revoke, the same exception result is returned using revocation through Web Services revokeCert. The RA Web works, when I revoke in RA Web, certificate is revoked without any issue. Trying it now with the certificate that I am sure does not have any Publisher, I see the same line in the log: But the rest is the same, exception occurs: What can be different when the revocation using RA Web works, but not using the Admin UI? |
Beta Was this translation helpful? Give feedback.
-
|
I didn't have time to check the difference between RA and Admin UI yet. But thinking what's new on 8.2.0, is pre-produced OCSP responses used? You didn't enable the new functionality in EJBCA Enterprise to create OCSP responses on issuance/revocation? |
Beta Was this translation helpful? Give feedback.
-
|
No, there is no OCSP configured, no pre-produced OCSP responses. I was trying to look into the code, no idea so far, what is going on. |
Beta Was this translation helpful? Give feedback.
-
|
And no RA Peer connections I suppose. I checked the code as well in RA Web, revoking in RA web and it looks very similar to Admin UI. I can't see anything. Next step would be a trace log. Comparing revocation in Admin UI vs revocation in RA UI, it should show exact code paths that is run. |
Beta Was this translation helpful? Give feedback.
-
|
Or looking at StaleException:
Debug logging actual SQL queries in the database might also show something. This is really tricky. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Tomas, Here is the TRACE log. There is one RA Peer connection enabled, however, the revocation is done on the same CA, not through the RA Peer. I am trying to revoke in Admin UI and RA UI on the same instance that has the CA. I do not see any interesting information in the database logs. |
Beta Was this translation helpful? Give feedback.
-
|
Testing various scenarios it seems that I can revoke every certificate that was issued after upgrade to 8.2.0. The problem seems to be with certificates that were issued before upgrade to 8.2.0, but it is still undeterministic behaviour. I do not see any changes to the database or data that can cause it. Do you see any reason why this can happen? |
Beta Was this translation helpful? Give feedback.
-
|
I do not see any issue in the trace, merge will fail, but the trace looks the same as with certificate that can be revoked: 
I am out of ideas. |
Beta Was this translation helpful? Give feedback.
-
|
That's it. It's the database protection. I can reproduce it with an old certificate with full database signing enabled. |
Beta Was this translation helpful? Give feedback.
-
|
These are the changes that happened to this certificate that fails with databaseprotection and succeeds without: I suspect invalidityDate, as these is another open issue with invalidityDate and revocation. Can you move this discussion to an issue instead, as it's confirmed to be an issue. "Create issue from discussion". |
Beta Was this translation helpful? Give feedback.
-
|
I confirmed it's the invalidityDate column by having an old cert where it was null, causing the error but after (I have failOnVerify=false): |
Beta Was this translation helpful? Give feedback.
-
|
Somewhat related, but not exactly the same as: #505 |
Beta Was this translation helpful? Give feedback.
-
|
I see, and it was confirmed also on my side. Setting the So I need to change the Export and import of the database using database CLI will have no effect I think. Changing it in the database should be safe, it should not fail on verify before revocation or any other change. |
Beta Was this translation helpful? Give feedback.
-
|
By the way, what is the difference between revoking using Admin UI and RA UI. Because revocation in RA UI works also in case the |
Beta Was this translation helpful? Give feedback.
-
|
I have not been able to find that difference. |
Beta Was this translation helpful? Give feedback.
I confirmed it's the invalidityDate column by having an old cert where it was null, causing the error but after (I have failOnVerify=false):
update CertificateData set invalidityDate=-1 where fingerprint=LOWER('DF5D3D859744C0B53CC1E1C29AFF0147C399A417');
it works.