Layer 7 Access Management

Expand all | Collapse all

Steps to update the server cert for Wildfly for TCP 8443

  • 1.  Steps to update the server cert for Wildfly for TCP 8443

    Posted 11-16-2018 12:38 PM

    Team,

     

    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-01
    keytool -delete -keystore caim-srv -store-pass changeit -alias caim-srv-01
    keytool -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:8443
    10: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.Final
    10: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: configureCustomHostRecords
    Example:

    vi /opt/CA/VirtualAppliance/custom/hosts
    192.168.242.146 idm.test.companyABC.dom

    configureCustomHostRecords

     


    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)



  • 2.  Re: Steps to update the server cert for Wildfly for TCP 8443

    Posted 11-27-2018 11:16 AM

    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. 



  • 3.  Re: Steps to update the server cert for Wildfly for TCP 8443

    Posted 11-27-2018 12:39 PM

    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.113549.1.1.5 sha1RSA
    Algorithm Parameters:
    Public Key Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA
    Algorithm Parameters:
    Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.5 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



  • 4.  Re: Steps to update the server cert for Wildfly for TCP 8443

    Posted 11-27-2018 01:21 PM

    Hey Alan,

     

    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.



  • 5.  Re: Steps to update the server cert for Wildfly for TCP 8443

    Posted 11-27-2018 05:59 PM

    Hi Enrique,

     

    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.