Replacing wildfly certificates keystore issue (ejbca ce docker container) #967
-
|
Hi, I am trying to use my own certificate for the server. It comes from a three tier hieararchy where I have added the cert, and the three CAs to a pkcs12 store. I get the certs as base64 encoded not binary, not sure if it matters when firstly adding them to the pkcs12 store. Then I tried several things: 1. mounted the store server.p12 as server.jks to /mnt/external/secrets/tls/ks and provided the password file server.storepasswd, here I get 2025-10-06 12:27:59,948+0000 INFO [/opt/keyfactor/bin/start.sh] (process:1) Importing keystore /opt/keyfactor/secrets/external/tls/ks/server.jks to /opt/keyfactor/tmp/tmp.LAUH5HjMf9/keystore.jks... so the log seems happy (I also successfuly import the truststore in /mnt/external/secrets/tls/ts with my CA chain) Though when I try to access the application I get ERR_CONNECTION_CLOSED so it seems wildfly does not let me through. (Works when I let it use the autogenerated management CA). But maybe there is an issue since i simply throw a PKCS12 container at it without any JKS conversion. 2. converted the server.p12 to jks using keytool and it seems fine, I can list the content given the password I am mounting to the container. Here I directly mount server.jks into /mnt/external/secrets/tls/ks but during startup I get 2025-10-06 12:34:58,465+0000 INFO [/opt/keyfactor/bin/start.sh] (process:1) No key password file were detected at '/opt/keyfactor/secrets/external/tls/ks/server.keypasswd'. Keystore password will also be used to access private key. I never set a specific key password during conversion it is simply: keytool -importkeystore -srckeystore server.p12 -srcstoretype PKCS12 -destkeystore server.jks -deststoretype JKS then simply answer the prompts on the new keystore password and source password. Needles to say the server does not like this configuration... Not sure where to move from here, thank you for any help. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 17 replies
-
|
You need to add you Root CA certificate to the truststore, which is a separate p12/jks file. Otherwise the TLS connection will not accept client certificates issued from that CA. The TLS connection announces something called "accepted client CAs" the the client as part of the TLS handshake. |
Beta Was this translation helpful? Give feedback.
-
|
hey, so issue was wrong signing algorithm on an intermediate, somehow I forgot to change it... All works now, though just for the reference (if you have an explanation), initially I have only used the ejbca interface to add a member based on his client cert to the superadmin group. How would wildfly know how to validate the client cert? I get how ejbca know what to match, all is in the database, but I have not updated any truststore and it all worked anyways... this suggests to me that wildfly simply accepted the client certificate without checking (as it still only had the original management CA that did NOT sign the presented client certificate) and passed it on to ejbca for authorization check. This line in the log gives a hint that the mtls is optional though if the client cert is present I would expect wildfly validates it against a chain in a truststore... Is there a deeper setting somewhere than TLS_SETUP_ENABLED=true? |
Beta Was this translation helpful? Give feedback.
-
|
There is no way to bypass TLS verification is client cert is used. The optional client cert authentication is to be able to use client cert authentication for some paths (adminweb for example), but not others (CMP endpoint and RA web for example). What may be is that you can set it to accept all CAs for client certs, in which case you could use any client cert, it will be verified by the TLS layer, and further on passed to EJBCA where it will be used for RBAC. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thank you for that. That explains the "optional" I seen in the log. Also makes sense with the DB/Truststore. Speaking of which could i use PKCS12 Truststore? If i build it using openssl as cat issuing_ca.pem intermediate_ca.pem root_ca.pem > ca_chain.pem then openssl pkcs12 -export -in ca_chain.pem -out truststore.p12 -nokeys -name ejbca-trust when i mount truststore.p12 as /mnt/external/secrets/tls/ts/truststore.jks I can see ejbca recognizes it during startup but get 0 entries imported... However if i actuall use keytool an build a jks truststore from the same certs it nicely shows 3 entries imported Is there something I am missing when building the p12? My understanding it that it shall be supported... BTW as mentioned above i mount p12 as a keystore successfully, though that one has a leaf cert and a private key so not excatly the same thing... |
Beta Was this translation helpful? Give feedback.
-
|
At the moment wildfly is configured (in standalone.xml() in the container to use JKS keystores. It will migrate to p12 in a future release. At the moment, use JKS. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
I actually recently found out that you can use P12. The file just have to be named .jks. Java auto-detects the format, so you can put your keystore.p12, named as keystore.jks. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, thats funny, I have tried that several times and it would not import anything from it (it sees it but shows 0 entries imported). How did you build your p12? I have just thrown in my CA chain as pem (base64 encoded) with -nokeys directive using openssl. openssl pkcs12 -export -in ca_chain.pem -out truststore.p12 -nokeys -name ejbca-trust and with a mount like this when i mount truststore.p12 as /mnt/external/secrets/tls/ts/truststore.jks It gets 0 entries imported so my suspicion is that it does not like the format of the p12 or simply does not like p12 without private keys. It works fine for the keystore, that one I mount directly as keystore.jks even though it is an openssl built pkcs12 and it just works. The truststore though does not... |
Beta Was this translation helpful? Give feedback.
-
|
What does openssl pkcs12 -in truststore.p12 -nodes look like? I assume that your ca_chain.pem only contain root CA certificate(s)? |
Beta Was this translation helpful? Give feedback.
At the moment wildfly is configured (in standalone.xml() in the container to use JKS keystores. It will migrate to p12 in a future release. At the moment, use JKS.