I had follow the guide to set up jboss and ejbca without error
i run following commands without any error:
=> ant -q clean deployear
=> $ ant runinstall
=>$ ant deploy-keystore
I restart service and everything ok , ManagementCA created as well.
when i browse / access to https://xxx.xx.xx.xx:8443/ejbca/adminweb it return SSL_ERROR_HANDSHAKE_FAILURE_ALERT error
I also checked that, /opt/wildfly/standalone/configuration/keystore/ contain keystore.jks and truststore.jks
=> keytool -list -keystore truststore.jks
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
managementca, May 16, 2023, trustedCertEntry,
Certificate fingerprint (SHA-256): C7:83:96:3C:9E:B0:93:0D:D2:41:00:7C:F3:54:EA:6C:7D:C0:9D:24:D7:FD:E1:5D:7B:6E:BF:AB:5F:44:8E:82
keytool -list -keystore keystore.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
192.168.33.211, May 15, 2023, PrivateKeyEntry,
Certificate fingerprint (SHA-256): 11:06:9A:97:E5:87:27:8B:FF:71:15:7D:FE:D5:33:68:A7:1A:32:C7:F6:E2:83:D5:BE:3A:D4:8D:E0:C0:28:30
cacert, May 15, 2023, trustedCertEntry,
Certificate fingerprint (SHA-256): C7:83:96:3C:9E:B0:93:0D:D2:41:00:7C:F3:54:EA:6C:7D:C0:9D:24:D7:FD:E1:5D:7B:6E:BF:AB:5F:44:8E:82
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12".
and i imported superadmin.p12 to browser cert. store.
So which step i missed? Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OMG, Thank you for coming back to post the fix!!!
I created this account just to be able to thank you!!!
I am a first time EJBCA user and went through the lengthy manual install guide rather than spin up a docker image and it was a long painful journey only to be met with the error described by OP, it was looking like I had wasted 2 days of my life on this until i stumbled on your post.
To elaborate on the fix, I used this command to convert both keystores (change the filename to keystore.jks for the other one) :
I left the old jks files inplace (unsure if nessecary), but upon restarting the wildfly service I noted in the logs /opt/wildfly/standalone/log/server.log that it could not read the new p12 files as the owner was root:root. I changed this to wildfly:wildfly (chmod 700) and restarted the service and voila, no errors in the log and https://localhost:8443/ejbca/adminweb/ is now accessable.
No idea why this is required and not documented, did I make mistake and this is the fix? Maybe, but I was using the newest EJBCA 8.0 and the installation documention has some configuration items that are not present in the XXX.properties.sample files. Over all the documentation is quite comprehensive but has some areas where it presumes too much and give you nothing to work with as a total beginner.
One other tip I'll leave you with is if you have fapolicyd performing application control on your system like I did, it will deny allot of actions throughout this process. I found the audit.log not as useful so putting fapolicyd into debug mode helps allot:
In a couple of instances rather than trust files a directories I created a rule to allow the excuting binary and the MIME file type incase hashes change:
I had follow the guide to set up jboss and ejbca without error
i run following commands without any error:
=> ant -q clean deployear
=> $ ant runinstall
=>$ ant deploy-keystore
I restart service and everything ok , ManagementCA created as well.
when i browse / access to https://xxx.xx.xx.xx:8443/ejbca/adminweb it return SSL_ERROR_HANDSHAKE_FAILURE_ALERT error
I also checked that, /opt/wildfly/standalone/configuration/keystore/ contain keystore.jks and truststore.jks
=> keytool -list -keystore truststore.jks
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
managementca, May 16, 2023, trustedCertEntry,
Certificate fingerprint (SHA-256): C7:83:96:3C:9E:B0:93:0D:D2:41:00:7C:F3:54:EA:6C:7D:C0:9D:24:D7:FD:E1:5D:7B:6E:BF:AB:5F:44:8E:82
keytool -list -keystore keystore.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
192.168.33.211, May 15, 2023, PrivateKeyEntry,
Certificate fingerprint (SHA-256): 11:06:9A:97:E5:87:27:8B:FF:71:15:7D:FE:D5:33:68:A7:1A:32:C7:F6:E2:83:D5:BE:3A:D4:8D:E0:C0:28:30
cacert, May 15, 2023, trustedCertEntry,
Certificate fingerprint (SHA-256): C7:83:96:3C:9E:B0:93:0D:D2:41:00:7C:F3:54:EA:6C:7D:C0:9D:24:D7:FD:E1:5D:7B:6E:BF:AB:5F:44:8E:82
Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12".
and i imported superadmin.p12 to browser cert. store.
So which step i missed? Thanks.
I think what I'm wrong now.
Its ok after I convert the keystore.jks and truststore.jks to PKCS12 format.
Thanks.
OMG, Thank you for coming back to post the fix!!!
I created this account just to be able to thank you!!!
I am a first time EJBCA user and went through the lengthy manual install guide rather than spin up a docker image and it was a long painful journey only to be met with the error described by OP, it was looking like I had wasted 2 days of my life on this until i stumbled on your post.
To elaborate on the fix, I used this command to convert both keystores (change the filename to keystore.jks for the other one) :
I left the old jks files inplace (unsure if nessecary), but upon restarting the wildfly service I noted in the logs /opt/wildfly/standalone/log/server.log that it could not read the new p12 files as the owner was root:root. I changed this to wildfly:wildfly (chmod 700) and restarted the service and voila, no errors in the log and https://localhost:8443/ejbca/adminweb/ is now accessable.
No idea why this is required and not documented, did I make mistake and this is the fix? Maybe, but I was using the newest EJBCA 8.0 and the installation documention has some configuration items that are not present in the XXX.properties.sample files. Over all the documentation is quite comprehensive but has some areas where it presumes too much and give you nothing to work with as a total beginner.
One other tip I'll leave you with is if you have fapolicyd performing application control on your system like I did, it will deny allot of actions throughout this process. I found the audit.log not as useful so putting fapolicyd into debug mode helps allot:
In a couple of instances rather than trust files a directories I created a rule to allow the excuting binary and the MIME file type incase hashes change:
Hope this helps some poor soul in the future.
Last edit: Lambo 2023-08-05