If a client is using external load-balancers (F5) or intermediate Web Servers, there may be a need to update the default self-sign server cert for the Wildfly/JBoss services.
The scenario covered is for CA Identity Suite (IM, IG, IP), but may reference for other J2EE instances.
Below are the steps to update, if you receive a complete PFX file.
- Note: If possible, request SANS addresses for all FQDN and IP addresses to be used for the Identity Suite environment to lower TCO and allow the client to rotate this file as often as they like, instead of having three (3) or more unique certs.
Step01: View the J2EE / Wildfly JKS used for path and current password for the keystore.
grep -C 2 keystore /opt/CA/wildfly-idm/standalone/configuration/ca-standalone-full-ha.xml
<server-identities> <ssl> <keystore path="/opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates/caim-srv" keystore-password="changeit"/> </ssl> </server-identities>
Step02: View current Self-Sign Cert and then delete it from the caim-srv JKS keystore [backup the JKS keystore first]
- Under this path: /opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates
keytool -printcert -v -file caim-srv.cer [May identify the current alias from this file]keytool -list -v -keystore caim-srv -store-pass changeit -alias caim-srv-01keytool -delete -keystore caim-srv -store-pass changeit -alias caim-srv-01keytool -list -v -keystore caim-srv -store-pass changeit -alias caim-srv-01
Step03: Change pfx password to match the IM default JKS password (this is currently hardcoded in ca-standalone-full-ha.xml as changeit]
- Avoid error message: JBAS015229: Unable to start service Cannot recover key
keytool -importkeystore -srckeystore idm.test.companyABC.dom.pfx -srcstorepass company123 -srcstoretype pkcs12 -destkeystore caim-srv.pkcs12 -deststoretype pkcs12 -deststorepass changeit -destkeypass changeit
Step04: Import the intermediate pfx (with new password of changeit) into the Wildfly JKS file caim-srv.
keytool -importkeystore -srckeystore caim-srv.pkcs12 -srcstorepass changeit -srcstoretype pkcs12 -destkeystore caim-srv -deststoretype JKS -deststorepass changeit
Step05: Restart IM and monitor the wildfly-console.log; ensure that TCP 8443 does start and listen
grep -C 2 -i https /opt/CA/wildfly-idm/standalone/log/wildfly-console.log 10:28:24,853 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015973: Starting subdeployment (runtime-name: "castylesr5.1.1.war")10:28:24,880 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]10:28:25,033 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017519: Undertow HTTPS listener https listening on /192.168.242.146:844310:28:26,545 INFO [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.3.2.Final10:28:29,031 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Registered web context: /castylesr5.1.1
Step06: View certs from on 8443 (use browser or openssl)
openssl s_client -connect caim-srv-01:8443 -showcerts
Step07: Need to add the public root CA cert to "TRUSTED" CA section of JKS, to avoid "self-signed cert" message. [use browser or openssl to capture this final root cert]
keytool -import -trustcacerts -file idm-test.companyABC.com.publicCA.cer -alias Clients_public_CA_root_cert -keystore caim-srv -store-pass changeit
Step08: Retest with openssl to ensure correct server cert and the CA public root cert are properly deployed. [Should see error return code 0 (zero)]
openssl s_client -connect caim-srv-01:8443 -showcerts -CAfile idm-test.companyABC.com.publicCA.cer
Step09: To test with FQDN from client; add in the FQDN to the custom vApp Alias file: /opt/CA/VirtualAppliance/custom/hosts & execute alias: configureCustomHostRecordsExample:
vi /opt/CA/VirtualAppliance/custom/hosts192.168.242.146 idm.test.companyABC.dom
Step10: Retest with FQDN and openssl
openssl s_client -connect idm.test.companyABC.dom:8443 -showcerts -CAfile idm-test.companyABC.com.publicCA.cer
SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 5BEEFA84E70684E48ABF1177DA77AF389A1F783A7499C35CBF5407A4BE0E2B62 Session-ID-ctx: Master-Key: 10E66BFE580454ADE9E1775C3F77ECDCBDE36C9599CAED3F017284CC4755C06548115E599BBABD42BF73D6B99745CB9C Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1542388356 Timeout : 300 (sec) Verify return code: 0 (ok)
Alan ... the steps provided work effectively in most environments. I ran into an issue, however, based on the browser used to validate the certificates which had me rework and retest the openssl steps more than once. It turns out Chrome and Firefox have deprecated support for SHA-1 certificates, which is not the case with IE 11. A recent test at a customer site, where IE 11 is the default browser on workstation or virtual desktop images, was resolved by noting the difference in the browser support.
Excellent finding. So we should pre-test the certs provided for SHA-1; then we can advise they be regenerated.
Lets test the following CLI processes to see if they can help with this pre-check:
If I look at various certs in an example PFX, I can see some have different algorithms used.
/opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates > openssl x509 -noout -text -in idm.test.ABC.dom.cer | grep "Signature Algorithm" | uniq
Signature Algorithm: sha256WithRSAEncryption
/opt/CA/VirtualAppliance/custom/wildfly-ssl-certificates > openssl x509 -noout -text -in idm-test.ABC.publicCA.cer | grep "Signature Algorithm" | uniq
Signature Algorithm: sha1WithRSAEncryption
On MS Windows, we could pre-check with the certutil command:
certutil -dump idm.test.ABC.dom.ca-public-root-cert.cer | find "Algorithm"
Signature Algorithm: Algorithm ObjectId: 1.2.840.1135220.127.116.11 sha1RSA Algorithm Parameters:Public Key Algorithm: Algorithm ObjectId: 1.2.840.113518.104.22.168 RSA Algorithm Parameters:Signature Algorithm: Algorithm ObjectId: 1.2.840.113522.214.171.124 sha1RSA Algorithm Parameters:
An another example view using openssl s_client with a pipe to view a live connection:
openssl s_client -connect 192.168.242.146:8443 < /dev/null 2>/dev/null | openssl x509 -text -in /dev/stdin | grep "Signature Algorithm"
Signature Algorithm: sha256WithRSAEncryption Signature Algorithm: sha256WithRSAEncryption
From the above tests, it appears the server cert is sha256, but the public root CA cert is using sha1.
- So we can likely conclude the client team would need to have their certs regenerated with a new CA certificate to avoid issues with non-IE browsers.
Optional: A review of configurations for other browsers, show that an option that could be provided to a client's internal security/audit team as a temporary process until new certs are generated.
A new startup link could be added to the users' desktop for Chrome with the following switch.
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --ignore-certificate-errors
I ran a quick test from a VDI. Chrome still complains, starting with "You are using an unsupported command-line flag: --ignore-certificate-errors". I also still see the Not secure warning display when the browser window opens.
Curious, I thought that would address it as a temporary solution, but when I retried, I had the same challenge:
- Here are the three (3) messages that I captured during testing.