Showing posts with label eap. Show all posts
Showing posts with label eap. Show all posts

Friday, February 10, 2017

JBoss EAP - Override Deployment Content

JBoss EAP - Override Deployment Content

A deployment overlay can be used to overlay content into an existing deployment without physically modifying the contents of the deployment archive. This can override deployment descriptors, JAR files, classes, JSP pages, and other files at runtime.

When defining a deployment overlay, you specify the file on a file system that will replace the file in the deployment archive. You must also specify which deployments should be affected by the deployment overlay. Any affected deployments must be redeployed in order for the changes to take effect.

JBoss CLI

Start the JBoss application server and run the jboss-cli command tool in the bin folder of your JBoss EAP install directory
  jboss-cli.sh --controller=: -c

Example:
  jboss-cli.sh --controller=localhost:9999 -c

Find name of deployments

[standalone@localhost:9999 /] /deployment=*:read-attribute(name=name)
{
    "outcome" => "success",
    "result" => [{
        "address" => [("deployment" => "my-app.war")],
        "outcome" => "success",
        "result" => "my-app.war"
     }]
}

Deployment overlay help

Display all the help for the deployment-overlay command

deployment-overlay --help

List links

Lists deployments the overlay is linked to:

  • deployment-overlay list-links --name=overlay_name [-l] [--server-groups=server_group_name(,server_group_name)*]

Example:
deployment-overlay list-links --name=my-app-deployment-overlay

Add action

Use the deployment-overlay add management CLI command to add a deployment overlay. Once created, you can add content to an existing overlay, link the overlay to a deployment, or remove the overlay.

Depending on the arguments the action:

  • always creates a new overlay with content;
  • optionally links it to the specified existing deployments;
  • also optionally re-deploys the affected (linked) deployments.

Options

  • name
    • overlay_name
  • content
    • archive_path=fs_path(,archive_path=fs_path)*. Comma-separated list that maps the file on the file system to the file in the archive that it will replace.
  • server-groups/all-server-groups
    • server_group_name(,server-group-name)*. In a managed domain, specify the applicable server groups by using --server-groups or specify all server groups with --all-server-groups.
  • deployments
    • deployment_name(,deployment_name)*. Comma-separated list of deployments to which this overlay will be linked.
  • wildcards
    • wildcard_name(,wildcard_name)*
  • redeploy-affected
    • Redeploys all affected deployments.
  • headers
    • {operation_header (;operation_header)*}


Examples
deployment-overlay add --name=my-app-deployment-overlay --content=WEB-INF/jboss-web.xml=/app/jboss-eap-6.4/standalone/deployment-overlay/jboss-web.xml --deployments=my-app.war --redeploy-affected

Nested deployments
If you have an zipped deployment with multiple zipped JAR's, WARs, etc. containing artifacts you want overlaying, then you need to include the name of the nested archive in the --content option. For example, if the EAR archive contains a war module in the root folder with the name my-app.war, then the following command overlays the WEB-INF/jboss-web.xml inside the sub-deployment my-app.war.
 deployment-overlay add --name=myOverlay --content=/my-app.war/WEB-INF/jboss-web.xml=/app/jboss-eap-6.4/standalone/deployment-overlay/jboss-web.xml --deployments=test.ear --redeploy-affected
Overlay Classes
 deployment-overlay add --name=classOverlay --content=/WEB-INF/classes/com/mydomain/MyClass.class=/app/jboss-eap-6.4/standalone/deployment-overlay/bin/com/mydomain/MyClass.class --deployments=my-app.war --redeploy-affected

Remove action

Depending on the arguments the action may:

  • unlink deployments (if --deployments or --wildcards argument is specified);
  • remove content (if --content argument is specified);
  • remove the overlay altogether with its content and links;
  • re-deploy affected deployments.

Options

  • name
    • overlay_name
  • content
    • archive_path=(,archive_path)*
  • server-groups/all-relevant-server-groups
    • server_group_name(,server_group_name)* 
  • deployments
    • deployment_name(,deployment_name)*
  • wildcards
    • wildcard_name(,wildcard_name)*
  • redeploy-affected
  • headers
    • {operation_header (;operation_header)*}


Examples
Unlink deployments
deployment-overlay remove --name=my-app-deployment-overlay --deployments=my-app.war



Monday, February 1, 2016

Useful commands to monitor and troubleshoot HornetQ in JBoss EAP 6

The JBoss Enterprise Application Platform (JBoss EAP) is a Java EE application server runtime platform used for building, deploying, and hosting Java applications and services. JBoss EAP 6 is Java EE 6 certified with Red Hat support.

HornetQ is an open source project to build a multi-protocol, embeddable, very high performance, clustered, asynchronous messaging system and is also developed by Red Hat. HornetQ is the Java Message Service (JMS) provider for JBoss EAP 6 and is configured as the Messaging Subsystem.

The following contains a collection of useful commands and steps in monitoring and troubleshooting HornetQ. Note that the commands below were run on a Windows machine with a default standalone setup of JBoss EAP with the messaging subsytem configured and a test queue created.

Before you continue if you are attempting to do this in a production environment then it is very important to backup your messaging data folders or anything else you may need. 

Finding the message count of a queue

  • Open a command prompt and run the jboss-cli script from within the JBOSS_HOME bin directory:
    • %JBOSS_HOME%/bin/jboss-cli.bat -c 
/subsystem=messaging/hornetq-server=default/jms-queue=testQueue/:count-messages
  • If the outcome was a success the result should contain how many messages are in the queue. 

Listing the messages in a queue

  • Still connected to the JBoss command line interface run the following command:
/subsystem=messaging/hornetq-server=default/jms-queue=testQueue/:list-messages

Moving messages

  • You can move all messages from a one queue to another:
/subsystem=messaging/hornetq-server=default/jms-queue=testQueue/:move-messages(other-queue-name=destinationQueue)
  • You can move a message from one queue to another if you know the message id of the message you want to move. You should be able to get this from listing the message as described earlier:
/subsystem=messaging/hornetq-server=default/jms-queue=testQueue/:move-message(other-queue-name=destinationQueue,message-id=ID5e1b49b7-15a2-11e5-a905-89636a1272dc)

List prepared transactions

  • You can list prepared transaction on the HornetQ server by running the following command:
/subsystem=messaging/hornetq-server=default/:list-prepared-transactions

Commit prepared transactions

  • If you need to force commit a prepared transaction you can do so by providing the transaction-as-base-64 value found in the list-prepared-transaction command for the following command:
/subsystem=messaging/hornetq-server=default/:commit-prepared-transaction(transaction-as-base-64=AAAAAAAAAAAAAP__wADIWogIO3NWnRrMAADsLwAAAAIAAAAAAAAAAAAAAAAAAP__wADIWogIO3NWnRrMAADsFzEHAgIA)

Java utility applications

HornetQ has a number of Java utility applications that can be run in order to perform certain tasks, these classes can be found in the %JBOSS_HOME%\modules\system\layers\base\org\hornetq directory. 

ExportJournal

  • Use this class to export the journal data. You can use it as a main class or through its native method exportJournal(String, String, String, int, int, String), example as main method:
java -cp %JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-commons-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-core-client-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-jms-client-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-jms-server-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-journal-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-server-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\jboss\logging\main\jboss-logging-3.1.2.GA-redhat-1.jar \
org.hornetq.core.journal.impl.ExportJournal %JBOSS_HOME%\standalone\data\messagingjournal hornetq-data hq 10485760 %JBOSS_HOME%\tmp\journalExport.dmp

XmlDataExporter

  • Read the journal, page, and large-message data from a stopped instance of HornetQ and save it in an XML format to a file, example:
java -cp %JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-commons-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-core-client-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-jms-client-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-jms-server-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-journal-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-server-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\jboss\logging\main\jboss-logging-3.1.2.GA-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\jboss\netty\main\netty-3.2.6.Final.jar \
org.hornetq.core.persistence.impl.journal.XmlDataExporter %JBOSS_HOME%/standalone/data/messagingbindings %JBOSS_HOME%/standalone/data/messagingjournal %JBOSS_HOME%/standalone/data/messagingpaging $JBOSS_HOME/standalone/data/messaginglargemessages > journal-export.xml

XmlDataImporter

  • Read XML output generate by the org.hornetq.core.persistence.impl.journal.XmlDataExporter class, create a core session, and send the messages to a running instance of HornetQ, example:
java -cp %JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-commons-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-core-client-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-jms-client-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-jms-server-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-journal-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-server-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\jboss\logging\main\jboss-logging-3.1.2.GA-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\jboss\netty\main\netty-3.2.6.Final.jar \
org.hornetq.core.persistence.impl.journal.XmlDataImporter journal-export.xml localhost 5445

PrintData

  • PrintData writes a human-readable interpretation of the contents of a HornetQ Journal, example:
java -cp %JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-commons-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-core-client-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-jms-client-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-jms-server-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-journal-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-server-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\jboss\logging\main\jboss-logging-3.1.2.GA-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\jboss\netty\main\netty-3.2.6.Final.jar \
org.hornetq.core.persistence.impl.journal.PrintData standalone/data/messagingbindings/ standalone/data/messagingjournal/ > printData.log

PrintPages

  • PrintPages writes a human-readable interpretation of the contents of a HornetQ Journal and its pages, example:
java -cp %JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-commons-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-core-client-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-jms-client-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-jms-server-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-journal-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\hornetq\main\hornetq-server-2.3.12.Final-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\jboss\logging\main\jboss-logging-3.1.2.GA-redhat-1.jar;%JBOSS_HOME%\modules\system\layers\base\org\jboss\netty\main\netty-3.2.6.Final.jar \
org.hornetq.core.paging.PrintPages standalone/data/messagingpaging/ standalone/data/messagingjournal/ > printPages.log

Thursday, January 28, 2016

Java client authentication for JBoss EAP over SSL

SSL Encryption for Web Server

Secure Sockets Layer (SSL) encrypts network traffic between two systems. Traffic between the two systems is encrypted using a two-way key, generated during the handshake phase of the connection and known only by those two systems.

In order for a browser to connect with JBoss EAP over SSL the following steps will need to be performed:
  • Create keystore containing public and private keys for the server
  • Configure a HTTPS connector in JBoss EAP 

In order for a Java client application to authenticate with JBoss EAP over SSL the following steps will need to be performed:
  • Create keystores for the server and client 
  • Configure a HTTPS connector in JBoss EAP 
  • Include the SSL configuration in your client application

SSL Encryption Keys and Certificate

For secure exchange of the two-way encryption key, SSL makes use of Public Key Infrastructure (PKI), a method of encryption that utilizes a key pair. A key pair consists of two separate but matching cryptographic keys:

  • public key - shared with others and used to encrypt data
  • private key - kept secret and used to decrypt data that has been encrypted using the public key

When a client requests a secure connection, a handshake phase takes place before secure communication can begin. During the SSL handshake the server passes its public key to the client in the form of a certificate. The certificate contains:

  • the identity of the server (its URL)
  • the public key of the server
  • a digital signature that validates the certificate. You can purchase a certificate from a Certificate Authority (CA), or you can use a self-signed certificate. Self-signed certificates are not considered trustworthy but are appropriate for internal testing purposes.

The client then validates the certificate and makes a decision about whether the certificate is trusted or not.

If the certificate is trusted, the client generates the two-way encryption key for the SSL connection, encrypts it using the public key of the server, and sends it back to the server.

The server decrypts the two-way encryption key, using its private key, and further communication between the two machines over this connection is encrypted using the two-way encryption key.

Generate a keystore containing public and private keys.

keytool -genkeypair -alias jbossweb -keyalg RSA -keysize 1024 -keystore server.jks -validity 3650 -keypass jbosswebpass -storepass jbosswebpass
  • -genkeypair (previously named genkey)
    • Generates a key pair
  • -alias
    • alias name of the entry to process
  • -keyalg                
    • key algorithm name
  • -keysize              
    • key bit size
  • -keystore            
    • keystore name
  • -keypass                  
    • key password
  • -storepass                
    • keystore password

Subject Alternative Name

When generating the keystore you might need to set the subject alternative name, Chrome for instance will block access to a site that just uses the common name field and not the subject alternative name. In order to specify a subject alternative name you can use the ext option in the keytool command like:
keytool -genkeypair -alias jbossweb -keyalg RSA -keysize 1024 -keystore server.jks -validity 3650 -keypass jbosswebpass -storepass jbosswebpass -ext SAN=dns:test.example.com

Verify the key

The following command is quite useful to print information on the keystore:
keytool -list -v -keystore server.jks

Generate a certificate signing request.

keytool -certreq -keyalg RSA -alias jbossweb -keystore server.jks -file certreq.csr

Test the newly generated certificate signing request.

openssl req -in certreq.csr -noout -text

CA signed / self-signed certificate

  • Submit your certificate signing request to a Certificate Authority (CA) who can authenticate your certificate so that it is considered trustworthy by third-party clients. The CA supplies you with a signed certificate, and optionally with one or more intermediate certificates.
keytool -import -trustcacerts -alias jbossweb -keystore server.jks -file server.crt
  • If you get the following error: "keytool error: java.lang.Exception: Failed to establish chain from reply" it might be because you need to import root certificates. You should be able to know if you need this by whoever issued the CA to you. You will need to do the following:
  • Import root certificate to cacerts which will be available at JAVA_HOME/jre/lib/security folder using following command:
 keytool -importcert -alias root -file Root.cer -keystore cacerts
  • Import root certificate using following command:
 keytool -importcert -alias root -file Root.cer -keystore server.jks
  • Import intermediate certificate using following command
 keytool -importcert -alias sub -file Sub.cer -keystore server.jks
  • Import site certificate using following command:
 keytool -trustcacerts -importcert -alias jbossweb -file server.crt -keystore jbossprep.jks
  • If you only need certificate for testing or internal purposes, you can use a self-signed certificate. You can export one from the keystore you created in the first step above:
keytool -export -alias jbossweb -keystore server.jks -file server.crt

Create keystores for the Java client application

The following steps describe how to create keystores for the client and how to import these keystores into the truststores. 

Export the server's public key

  • Export the server public key created in the above steps by running the following command:
 
 keytool -exportcert -alias jbossweb -keystore server.jks -file server.cer -keypass jbosswebpass -storepass jbosswebpass
  • -exportcert (previously named export) 
    • Exports certificate
  • -alias
    • alias name of the entry to process
  • -keystore            
    • keystore name
  • -file                  
    • output file name
  • -keypass                  
    • key password
  • -storepass                
    • keystore password

Create the client's keystore private/public key


  • Run the following command:
 
 keytool -genkeypair -alias clientalias -keyalg RSA -keysize 1024 -keystore client.jks -keypass clientpass -storepass clientpass -validity 3650
  • -genkeypair (previously named genkey)
    • Generates a key pair
  • -alias
    • alias name of the entry to process
  • -keyalg                
    • key algorithm name
  • -keysize              
    • key bit size
  • -keystore            
    • keystore name
  • -keypass                  
    • key password
  • -storepass                
    • keystore password
  • -validity
    • validity number of days
  • -storetype
    • keystore type. Default is jks, for PKCS12 use -storetype PKCS12

Subject Alternative Name

The same as why mentioned above to specify a subject alternative name you can use the ext option in the keytool command like:
 
 keytool -genkeypair -alias clientalias -keyalg RSA -keysize 1024 -keystore client.jks -keypass clientpass -storepass clientpass -validity 3650 -ext SAN=dns:test.example.com

Export the client's public key

  • Run the following command:
 
 keytool -exportcert -alias clientalias -file client.cer -keystore client.jks -keypass clientpass -storepass clientpass
  • -exportcert (previously named export) 
    • Exports certificate
  • -alias
    • alias name of the entry to process
  • -file                  
    • output file name
  • -keystore            
    • keystore name
  • -keypass                  
    • key password
  • -storepass                
    • keystore password

Server truststore

  • Add the client's public key to the truststore of the server. The following imports the clients public key into the existing server.jks
 
 keytool -importcert -trustcacerts -alias clientalias -file client.cer -keystore server.jks -keypass jbosswebpass -storepass jbosswebpass
  • Instead of doing the above you could also add the client's public key to a truststore file
 
 keytool -importcert -trustcacerts -alias clientalias -file client.cer -keystore truststore.jks -keypass jbosswebpass -storepass jbosswebpass
  • importcert (previously named import)
    • Imports a certificate or a certificate chain
  • -trustcacerts                   
    • trust certificates from cacerts
  • -alias
    • alias name of the entry to process
  • -file                  
    • input file name
  • -keystore
    • keystore name
  • -keypass
    • key password
  • -storepass
    • keystore password

Client truststore

  • Add the server's public key to the truststore of the client
 
 keytool -importcert -trustcacerts -alias jbossweb -file server.cer -keystore client.jks -keypass clientpass -storepass clientpass
  • importcert (previously named import)
    • Imports a certificate or a certificate chain
  • -trustcacerts                   
    • trust certificates from cacerts
  • -alias
    • alias name of the entry to process
  • -file                  
    • input file name
  • -keystore
    • keystore name
  • -keypass
    • key password
  • -storepass
    • keystore password

More information on how to use the keytool command can be found here.

Export private key from server keystore

If you ever need to export your server JKS keytool format to PKCS #12 format and the private key you can follow these steps:
  • Save JKS as PKCS:
 
keytool -importkeystore -srckeystore server.jks -destkeystore keystore.p12 -deststoretype PKCS12 -srcalias jbossweb -deststorepass jbosswebpass -destkeypass jbosswebpass
  • Export certificate using openssl:
 
openssl pkcs12 -in keystore.p12  -nokeys -out cert.pem
  • Export unencrypted private key:
 
openssl pkcs12 -in keystore.p12  -nodes -nocerts -out key.pem
  • Verify that the Certificate and your Private Key go together:
 
diff <(openssl x509 -noout -in server.cer -modulus) <(openssl rsa -noout -in key.pem -modulus -passin pass:jbosswebpass)

Configure a HTTPS connector in JBoss EAP 6

Create a secure connector, named HTTPS, which uses the https scheme, the https socket binding (which defaults to 8443), and is set to be secure. This can be done via CLI or by editing the standalone.xml configuration file directly, this is what an example one-way SSL authentication HTTPS connector configuration looks like:
<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
  <connector name="HTTPS" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">
    <ssl name="https" key-alias="jbossweb" password="jbosswebpass" certificate-key-file="${jboss.server.config.dir}/keys/server.jks" cipher-suite="RSA" protocol="TLSv1"/>
  </connector>
  <virtual-server name="default-host" enable-welcome-root="true">
    <alias name="localhost"/>
    <alias name="example.com"/>
  </virtual-server>
</subsystem>

The following example is for two-way SSL authentication:
<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
   <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
   <connector name="HTTPS" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">
     <ssl name="https"
       key-alias="jbossweb"
       password="jbosswebpass"
       certificate-key-file="${jboss.server.config.dir}/server.jks"
       verify-client="true"
       ca-certificate-password="jbosswebpass"
       ca-certificate-file="${jboss.server.config.dir}/truststore.jks"/>
   </connector>

   <virtual-server name="default-host" enable-welcome-root="true">
     <alias name="localhost"/>
     <alias name="example.com"/>
   </virtual-server>
 </subsystem>
  • The verify-client attribute is equivalent to Tomcats clientAuth attribute. When this value is set to true it means the SSL stack should require a valid certificate chain from the client before accepting a connection.
  • When using keytool to create keystores, JBoss will compare the value you enter in the name against the hostname and will complain if it does not match You can set the following JVM argument to have JBoss ignore the hostname:
  • -Dorg.jboss.security.ignoreHttpsHost=true

Include the SSL configuration in your client application

Standalone Java Application

  • Within your standalone client application the following properties will need to be set to point to the client's keystore/truststore. 
  • Adding these system properties will set the keystore/truststore for the whole JVM.
 
 System.setProperty("javax.net.ssl.keyStore", "/path/to/client.jks");
 System.setProperty("javax.net.ssl.keyStorePassword", "clientpass");
 System.setProperty("javax.net.ssl.trustStore", "/path/to/client.jks");
 System.setProperty("javax.net.ssl.trustStorePassword", "clientpass");
  • Once those properties are set you should be able to make the necessary HTTPS call (an example would be a webservice request over SSL).

Browser as the Client

In order to test the certificates through a browser you will need to import all the certificates (root, intermediates and the certificate you got back from the CA). If you have configured JBoss above to verify-client then you will also need to import the client.p12 keystore into the browser. The following applies to windows:

Server Certificate

  • Open internet connections, an easy way to do it is by running: inetcpl.cpl
  • Go to the content tab
  • Certificates
  • Trusted Root Certification Authorities 
  • Import
  • Choose the CA signed / self-signed certificate (server.crt)

Client Keystore

  • Open internet connections, an easy way to do it is by running: inetcpl.cpl
  • Go to the content tab
  • Certificates
  • Personal 
  • Import
  • Choose the PKCS12 client keystore (client.p12)

Configuring Debug Options

In order to print debug options you can run your java application / JBoss application server with this addtional system parameter:
 -Djavax.net.debug=ssl,handshake
or
 -Djavax.net.debug=all

Keystore Explorer

Keystore Explorer is an open source GUI replacement for the Java command-line utilities keytool and jarsigner. KeyStore Explorer presents their functionality, and more, via an intuitive graphical user interface.