[BUG] exception on processing certain SCEP messages

[bkstein]

Describe the Bug

EJBCA-CE (ephemeral docker version) throws exception for a SCEP PkcsReq request.

To Reproduce

Steps to reproduce the behavior:

1. Run EJBCA-CE in a docker container as described here.
2. Configure a SCEP CA in RA mode with challenge password 1234.
3. Send a PkcsReq SCEP message (see attachment).
4. The EJBCA returns a java.lang.IllegalArgumentException (see attachment for more info).

Expected Behavior

EJBCA should return a new certificate. We tested our SCEP client with other CAs, which don't show problems.

Screenshots and Logs

If applicable, add screenshots and logs to help explain your problem.

Product Deployment

Please complete the following information:

• Deployment format: docker
• Version: latest as of 2025-07-15 (this is probably version 9.1.1, docker image digest:sha256:a7aa1e710781525444788e01b4bbbf48aac08c6262dbe7ad86b67e70cdb53843)

Desktop

Please complete the following information:

• OS: Windows 11

Additional Info

Exception in EJBCA when SCEP Request is sent

SCEP enroll message (Signed PKCS7):

-----BEGIN PKCS7-----
MIIKKAYJKoZIhvcNAQcCoIIKGTCCChUCAQExDzANBglghkgBZQMEAgEFADCCBNUG
CSqGSIb3DQEHAaCCBMYEggTCMIIEvgYJKoZIhvcNAQcDoIIErzCCBKsCAQIxggGy
MIIBrgIBAoAWBBTbMAplsvhyQrg6HF0UzmNt4NI2CTANBgkqhkiG9w0BAQEFAASC
AYBvZysBLdoLazXXEfa8Uv+Vx5Qt4VNk5U83xMGQYADNHzws7LV8RFZX/W54+3v1
bhktbbw+gd/SmGB2/OY0LxIULYmtv4b4EjnfOv8xXNyqsGtjrXjsNUdZxqIUK17W
4gOVidZtBVjDYmCWn7ql78066lNAcS72wJ8YiyjfqAK3CS2nMqxyrcLlWv1oosDY
C5k62MkQ8uByJRGu3NE2MWapS/YrV0whKTxFDPim0y5EhZ9089fP8ZQd3wNyNVBi
yb/riGUpgMPT84cyWNLtK/+JJJYV+tstXIg0WI3e4XdnpH+nF504CrQUmqDFFvVd
BRr4k+uUXpK1o3NFC2LxA8ib+jHzPqKsSFmuXpkkDqCiCQqpY3F7h0Y3U6bwISMj
fMsQ/+XLq2XT2kzn82lZpOI5pk581osZfLnJtRmfIUWaqKAxGNegwX9konn6JXgR
M3F9RJMqLUl3+CSHjJ0TfAQ4FDEusSvJ9WoeDzv8lXy8aEPxOwkjmharlQ4YrIEn
X1YwggLuBgkqhkiG9w0BBwEwHQYJYIZIAWUDBAECBBDFIcd/U81zeD7galJBTo+Z
gIICwOoOIqGTxROgmTCtjsO/w1Acym0Uri8Ao95SXyKuadUU9ibEqLD1rRhb/Evj
jx0Jmw9KohHZ8wGEbUdCBsNwsTfAPkz+SsJUIMv82glaj+0BktQksia9tPc+oLJ+
qItd3yEf+19p//nfOWY7jZN7W1gF9ZIPLMdd/gRkM9w6XTgvstsl3AyBsbhnWrxs
OtnMEbshQgPkHDSewGD6TjJxmzGfr9vLzm/fy1WDuy/rKbFbcSDTWSUtD5qP1jUt
T6dhKCpz12UUlaEZxNr9G/R9EqVKUQgcB9UlrPnLBlmGDw2TPELkbPWnvMhN76JJ
IKTB/vZPN5SvZNwIGyy3ZxSVUCaoQaRMrAWsiiNyXr6Cm1xdp4oN4z1hSwtmrlsD
Euiy38aDq9hu1CJp1F6IBXRgm39X0Y/prCB73S8Cusy3a3xiypVi1AC8UQxvndEF
lCswuMzSh120/o2BDHE8SAreAvdEZWSkybNE+IBQjAnWXo2O9d2J6NnJalF8w7IO
GQGgPglNWsMUrT/368GUMdowlpgVMy2Gu70XQAghHjpHLSUSenafIHARupv0TnXW
i/cHwNy7W6vQIVfp8ILc69+BKlaQNBs6Unk2oVO6940TxhgTEogMdlWLImWzRWro
MVOd4g/7OpvZ8O1SIo4lveHOHAAVEvCQQ/1LCtaObzUHfQmBvlOUq39XjBsXT2FE
uf0Cg4LiLqbsSV5PYGjCg6pXY2WYYMpJbhpaYCalwDCagoJGSOkBgNMUUKl9SxLZ
li7qSFCUcWd3HE5m3lUYY5i20yGUYfRVlXOtGMgKp6zE4pVNddcX1IccjgiL8kP2
s3C/OBPQkLbbXTd6IoakKbigE3Q+5WzNuMcpKzumQEyJ8J/lxjr5FWht3VeDpciB
YwbBPY1+klJIj8Ms8VQ273KS1Fye+3vjOcZG/4983i8lpXVaoIIC/DCCAvgwggHg
oAMCAQICCQC6dLMngWtOoTANBgkqhkiG9w0BAQsFADAWMRQwEgYDVQQDDAtNeVRs
c1NlcnZlcjAeFw0yNTA3MTUxMzA3MTBaFw0yNjA3MTUxMzA3MTBaMBYxFDASBgNV
BAMMC015VGxzU2VydmVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
updhETdHaG2qDWYwjY9itttfnWqsp/Q3w90Vu8f0skHpkTfj8Ip1F279Mzapa9I0
UavSgBTjTUhNtrgn8fuk4DnJQP1LyfRsKLWOkH2ReSBqaW9UEXJmzGOOQrqmMWud
+TFWsdu9F9MvVKHJNYvlK2SX1iDS4TA2PPV6W3wNs0p3jdUmanckz0ScGsLqdnre
Ac/JOZ/c4OjsLuS7IhcZCz19NeQ/P7QE2kyZp7zLFowp9H8E7f8PHh6fpOefjrks
e96C8iQZSvsc9HSx9yRVz3KyYneFbBxxveItu2TVQC0sTA90+xGumUBBiwr05I10
rt9mAtXZ86jnqwElWmO1DQIDAQABo0kwRzAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB
/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAPBgNVHREECDAGhwR/AAAB
MA0GCSqGSIb3DQEBCwUAA4IBAQBx0yCcFPYHMNnsjo6qRwUKQvvCZqKT5XcENTUu
3Wf6+iRqI02sGLruJ4Wnp2W6T96vClqCzmoCSDlvD4/TEWIzN00qLYRre8y9gAJj
AwvFqbZXBhLPSrf15w6xe5I26uW/6Nblf5368RdhK4nngISRxUHBAtc9Cq2dNkId
4rY+fnPhvoFUNt7okRNX9K1UqE2fyUnQE9A+zTxdi3XXiN9L6BUGhNb7IS8rAfrn
R70uB5rumJNzizdcKYSae7FWo8Izw/Ny/IA6bFs5CVcn9ess07ZojiKHh9MgP2sR
l4NSha/qrywwAqOjwmxiRNvZ6bpJT1HyyUgVj383p/s3jyt7MYICJDCCAiACAQEw
IzAWMRQwEgYDVQQDDAtNeVRsc1NlcnZlcgIJALp0syeBa06hMA0GCWCGSAFlAwQC
AQUAoIHTMBIGCmCGSAGG+EUBCQIxBBMCMTkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAgBgpghkgBhvhFAQkFMRIEEGRqUGZCa2l2aHp3Q2R4ViQwLwYJKoZIhvcN
AQkEMSIEIOXwO/1qiO1K9Tzt7mAJCp3giF6uPs3Mqh3RmYqrpb7HMFAGCmCGSAGG
+EUBCQcxQhNAZDUwYTFlNTA2NGM4ODZlNzhkNTJlYWMyNjc2ZmI0YjZmNDM3N2Jj
Y2VhMDA0NDYyMTViN2E3YmZkZTViOWE3OTANBgkqhkiG9w0BAQsFAASCAQCGwhVv
yz6qktRfiIvxvy20grL1Fva2umdG6IpThVGqhWh9XX+MNBQXGYEEx9X+4KOppCuI
h3haXjApSBWAA0ITOg2DuiUCxaufaADqCQ7RHPmvE/XO//tf+AGXfMsAOdqM1Hbl
pgIywDrIeLdLl7RHJz8sdBLoSiLlg6p9KWE4m8XTtrVxQnbJR3Sgpp2+Chkz93st
tl4vQLZyca3CLT7kdj9Xi+Pmi5gnNFT4RAVWv471UGVjwTGfTuXn9HKqqC9h0fnv
1eqRolOsomyhhoBoUO7c6rYEe8ORi0TCXBWa1sMxpu3uv3P+OggnNdrDm4tt1kmr
cDyRYp5//smiGgRQ
-----END PKCS7-----

Response body

00000000  3C 68 74 6D 6C 3E 3C 68 65 61 64 3E 3C 74 69 74 6C 65 3E 45 72 72 6F 72 3C 2F 74 69 74 6C 65 3E  <html><head><title>Error</title>
00000020  3C 2F 68 65 61 64 3E 3C 62 6F 64 79 3E 6A 61 76 61 2E 6C 61 6E 67 2E 49 6C 6C 65 67 61 6C 41 72  </head><body>java.lang.IllegalAr
00000040  67 75 6D 65 6E 74 45 78 63 65 70 74 69 6F 6E 3A 20 75 6E 6B 6E 6F 77 6E 20 6F 62 6A 65 63 74 20  gumentException: unknown object
00000060  69 6E 20 67 65 74 49 6E 73 74 61 6E 63 65 3A 20 6F 72 67 2E 62 6F 75 6E 63 79 63 61 73 74 6C 65  in getInstance: org.bouncycastle
00000080  2E 61 73 6E 31 2E 44 4C 54 61 67 67 65 64 4F 62 6A 65 63 74 3C 2F 62 6F 64 79 3E 3C 2F 68 74 6D  .asn1.DLTaggedObject</body></htm
000000A0  6C 3E                                                                                            l>"

Error Log in EJBCA-CE Docker

2025-07-15 11:51:48,170+0000 ERROR [org.jboss.as.ejb3.invocation] (default task-12) WFLYEJB0034: Jakarta Enterprise Beans Invocation failed on component RaMasterApiProxyBean for method public abstract byte[] org.ejbca.core.model.era.RaMasterApi.scepDispatch(org.cesecore.authentication.tokens.AuthenticationToken,java.lang.String,java.lang.String,java.lang.String) throws
java.security.cert.CertificateEncodingException,
org.ejbca.core.protocol.NoSuchAliasException,
org.cesecore.certificates.ca.CADoesntExistsException,
org.ejbca.core.ejb.ra.NoSuchEndEntityException,
org.cesecore.certificates.certificate.exception.CustomCertificateSerialNumberException,
com.keyfactor.util.keys.token.CryptoTokenOfflineException,
org.cesecore.certificates.certificate.IllegalKeyException,
org.cesecore.certificates.ca.SignRequestException,
org.cesecore.certificates.ca.SignRequestSignatureException,
org.ejbca.core.model.ca.AuthStatusException,
org.ejbca.core.model.ca.AuthLoginException,
org.cesecore.certificates.ca.IllegalNameException,
org.cesecore.certificates.certificate.CertificateCreateException,
org.cesecore.certificates.certificate.CertificateRevokeException,
org.cesecore.certificates.certificate.exception.CertificateSerialNumberException,
org.cesecore.certificates.ca.IllegalValidityException,
org.cesecore.certificates.ca.CAOfflineException,
org.cesecore.certificates.ca.InvalidAlgorithmException,
java.security.SignatureException,java.security.cert.CertificateException,
org.cesecore.authorization.AuthorizationDeniedException,
org.cesecore.certificates.certificate.certextensions.CertificateExtensionException,
org.ejbca.ui.web.protocol.CertificateRenewalException:

jakarta.ejb.EJBException: java.lang.IllegalArgumentException: unknown object in getInstance: org.bouncycastle.asn1.DLTaggedObject

[primetomas]

The log is cut just where the interesting part starts. It would be better if you store the log for the whole request as a file and attach it here

[primetomas]

Also, can you say how you submit the SCEP request, is it some SCEP client like sscep or you own code?

[primetomas]

Oh, and even better, configure with application debug logging (see the dockerhub documentation) enabled, it will tell you a lot more.

[bkstein]

The log was truncated, but I will try to configure debug logging in docker.

[bkstein]

This all I could get with docker run ... -e LOG_LEVEL_APP=DEBUG ...

2025-07-15_EJBCA-Exception-Trace.txt

[bkstein]

Also, can you say how you submit the SCEP request, is it some SCEP client like sscep or you own code?

We have our own application, which implements a SCEP client.

[bkstein]

@primetomas I can provide a commandline version of our software including some python scripts and a README.md (!) for easily reproducing the problem. The tool is a binary, is that a problem? (We have it for Linux and Windows).

[primetomas]

Sorry, I'm on vacation and can't debug your tool. Can you use one of the existing tools, jSCEP (as referenced as sample implementation by the SCEP spec) or sscep, which we know works (or Microsoft, Cisco, and other tested clients from https://docs.keyfactor.com/ejbca/latest/scep#id-(9.3.3)SCEP-Interoperability/TestedLibrariesandDevices. And see what's the difference in your client.

Looking at the error it fails to decode a definite length encoded ASN.1 sequence. Can it be that you use indefinite length encoding on your CMS message somewhere?

[bkstein]

I'd like to point out, that I did not want you to debug our tool. This should only help you to reproduce the problem with minimal effort. (And of course, I don't expect you to do this in your vacation 🙂)
The bug is definitely in EJBCA. It responds with an HTML message containing the Java exception info, when SCEP specifies a CMS/PKCS#7 message. This may never happen, regardless of any unusual tags, or settings in the SCEP message. And the stack trace shows, that our SCEP message is already dispatched internally by EJBCA. Which means, we use the correct URL.
Finally, we encode everything in DER - no indefinite lengths (though CMS permits BER for most parts of the messages, but EJBCA is the only CA I know, that uses BER instead of DER).

[primetomas]

Sorry it was bad stated by me, I didn’t think to debug your tool. What would be interesting is to see the difference between older working tools and this one to pinpoint what encoding difference you tool does.

[bkstein]

Sorry it was bad stated by me, I didn’t think to debug your tool. What would be interesting is to see the difference between older working tools and this one to pinpoint what encoding difference you tool does.

I tried to do this this morning using (micromdm's scepclient), but I ran into a problem with EJBCA-CE: I set up the SCEP CA as RA, but I see an error in EJBCA's log:

2025-07-16 10:40:11,930+0000 WARN  [org.ejbca.core.protocol.scep.ScepMessageDispatcherSessionBean] (default task-9) SCEP RA mode is enabled, but not included in the community version of EJBCA. Unable to continue.

When I configure the SCEP CA in CA mode, get this error:

2025-07-16 10:43:31,942+0000 INFO  [org.ejbca.ui.web.protocol.ScepServlet] (default task-9) SCEP cert request for unknown CA ''.: The SCEP alias sceptest is in CA mode, the message parameter in the GET request is empty, and no default CA has been defined for SCEP. Either switch to RA mode, provide the name of the CA in the message, use an alias name mapping to a CA name, or specify the default CA using the scep.defaultca property.

What should I do?

[primetomas]

Since EJBCA is multitennant that command need to indicate which CA cert chain is requested. This is done with ?message=caname (as optional in the spec). You can also rename the alias to be the same as the CA you want to return the chain for. There are some other options that I don’t remember right now. It’s documented here, https://docs.keyfactor.com/ejbca/latest/scep
I see that the documentation doesn’t mention the alias name option, that the error message does. It’s a miss in the doc.

[primetomas]

PS: I guess you don’t have any other option than to use SCEP? It’s very legacy and lack many options of better protocols (like decent EC support or future PQC support).

[bkstein]

PS: I guess you don’t have any other option than to use SCEP? It’s very legacy and lack many options of better protocols (like decent EC support or future PQC support).

Right! We have implemented a service, that gets certificates from CAs and speaks ACME and SCEP. I need a SCEP reply sample from EJBCA for testing purposes. We want to make sure, we support EJBCA.