Jetty + HikariCP + JVM SSL Connectivity Issues to RDS PostgreSQL with RDS 2019 CA root certificate - postgresql

I am having no luck in trying to connect to RDS PostgreSQL with Jetty (9.4.26) + JVM (java-1.8.0)
I have tried a few things
Importing 2019 RDS CA into Java cacerts
Setting up a separate TrustStore file for Java
Setting TrustStore file for Jetty in start.ini
Turning -Djavax.net.debug=ssl on shows that the 2015 RDS CA was added to trust, but I just cannot put a fingert as to where it is being told to trust. I am suspecting that the webapp has the 2015 RDS CA embedded...
Logs from Jetty
(-Djavax.net.debug=ssl)
~
~
adding as trusted cert:
Subject: CN=Amazon RDS Root CA, OU=Amazon RDS, O="Amazon Web Services, Inc.", L=Seattle, ST=Washington, C=US
Issuer: CN=Amazon RDS Root CA, OU=Amazon RDS, O="Amazon Web Services, Inc.", L=Seattle, ST=Washington, C=US
Algorithm: RSA; Serial number: 0x42
Valid from Thu Feb 05 20:11:31 AEDT 2015 until Thu Mar 05 20:11:31 AEDT 2020
~
~
~
~
~
Jan 23, 2020 9:54:46 AM org.postgresql.Driver connect
SEVERE: Connection error:
org.postgresql.util.PSQLException: SSL error: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at org.postgresql.ssl.MakeSSL.convert(MakeSSL.java:67)
at org.postgresql.core.v3.ConnectionFactoryImpl.enableSSL(ConnectionFactoryImpl.java:391)
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:162)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49)
at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:195)
at org.postgresql.Driver.makeConnection(Driver.java:452)
at org.postgresql.Driver.connect(Driver.java:254)
at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:95)
at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:101)
at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:314)
at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:171)
at com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:441)
at com.zaxxer.hikari.pool.HikariPool.access$300(HikariPool.java:66)
at com.zaxxer.hikari.pool.HikariPool$PoolEntryCreator.call(HikariPool.java:576)
at com.zaxxer.hikari.pool.HikariPool$PoolEntryCreator.call(HikariPool.java:569)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
at org.postgresql.ssl.MakeSSL.convert(MakeSSL.java:62)
... 18 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
at sun.security.validator.Validator.validate(Validator.java:262)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:330)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:237)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
... 26 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
... 32 more
~
~
~
Any ideas?

I'm going to take a stab at answering this as I have a working fix
The fix is upgrading the PostgreSQL JDBC Driver. The current version was 42.2.1, at the time of upgrade the version that worked was 42.2.9
Now going through Psql JDBS driver changelog, I found that from version 42.2.5 onwards there was code change that altered sslmode used
Looking at JDBC driver source, specifically in the ssl/MakeSSL.java file in the 42.2.1 version of the driver, this code section is now no longer present
33 SSLSocketFactory factory;
34
35 String sslmode = PGProperty.SSL_MODE.get(info);
36 // Use the default factory if no specific factory is requested
37 // unless sslmode is set
38 String classname = PGProperty.SSL_FACTORY.get(info);
39 if (classname == null) {
40 // If sslmode is set, use the libp compatible factory
41 if (sslmode != null) {
42 factory = new LibPQFactory(info);
43 } else {
44 factory = (SSLSocketFactory) SSLSocketFactory.getDefault();
45 }
46 } else {
47 try {
48 factory = (SSLSocketFactory) instantiate(classname, info, true,
49 PGProperty.SSL_FACTORY_ARG.get(info));
50 } catch (Exception e) {
51 throw new PSQLException(
52 GT.tr("The SSLSocketFactory class provided {0} could not be instantiated.", classname),
53 PSQLState.CONNECTION_FAILURE, e);
54 }
55 }

Related

Cannot load certificate file client.crt

Linux Mint 21
Success install openvpn.
OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
Now want to connect to remote setup via openvpn.
sudo openvpn Leo.ovpn
but get error:
2022-08-15 09:29:10 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2022-08-15 09:29:10 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2022-08-15 09:29:10 WARNING: file 'client.key' is group or others accessible
2022-08-15 09:29:10 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
2022-08-15 09:29:10 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2022-08-15 09:29:10 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2022-08-15 09:29:10 OpenSSL: error:0A00018E:SSL routines::ca md too weak
2022-08-15 09:29:10 Cannot load certificate file client.crt
2022-08-15 09:29:10 Exiting due to fatal error
P.S. I check folder. Exist files: client.crt and ca.crt

Payara ssl certificate and eclipse console

I have a problem for 2 days with eclipse console for payara that is not working anymore.
After I restart the server the only thing that is displayed is:
2018-08-25T05:28:01.959+0000|Info: Running Payara Version: Payara Server 4.1.2.174 #badassfish (build 192)
2018-08-25T05:28:01.961+0000|Info: Server log file is using Formatter class: com.sun.enterprise.server.logging.ODLLogFormatter
2018-08-25T05:28:02.587+0000|Info: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
2018-08-25T05:28:02.594+0000|Info: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
2018-08-25T05:28:02.599+0000|Info: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
2018-08-25T05:28:02.694+0000|Info: Authorization Service has successfully initialized.
2018-08-25T05:28:02.776+0000|Info: Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry
2018-08-25T05:28:02.809+0000|Info: Grizzly Framework 2.3.31 started in: 86ms - bound to [/0.0.0.0:8080]
2018-08-25T05:28:02.937+0000|Info: Grizzly Framework 2.3.31 started in: 24ms - bound to [/0.0.0.0:8181]
2018-08-25T05:28:02.954+0000|Info: Registered fish.payara.ha.hazelcast.store.HazelcastBackingStoreFactoryProxy for persistence-type = hazelcast in BackingStoreFactoryRegistry
2018-08-25T05:28:02.956+0000|Info: Registered Hazelcast BackingStoreFactory with persistence-type = hazelcast
2018-08-25T05:28:03.027+0000|Info: Grizzly Framework 2.3.31 started in: 14ms - bound to [/0.0.0.0:4848]
2018-08-25T05:28:03.154+0000|Info: Grizzly Framework 2.3.31 started in: 6ms - bound to [/0.0.0.0:3700]
2018-08-25T05:28:03.356+0000|Info: Created HTTP listener http-listener-1 on host/port 0.0.0.0:8080
2018-08-25T05:28:03.364+0000|Info: Created HTTP listener http-listener-2 on host/port 0.0.0.0:8181
2018-08-25T05:28:03.367+0000|Info: Created HTTP listener admin-listener on host/port 0.0.0.0:4848
2018-08-25T05:28:03.417+0000|Info: Created virtual server server
2018-08-25T05:28:03.421+0000|Info: Created virtual server __asadmin
2018-08-25T05:28:03.756+0000|Severe: The SSL certificate has expired: [
[
Version: V3
Subject: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 1024 bits
modulus: 135786214035069526348186531221551781468391756233528066061569654028671100866720352830303278016129003918213826297308054231261658522889438712013757624116391437358730449661353175673177742307421061340003741057138887918110217006515773038453829253517076741780039735595086881329494037450587568122088113584549069375417
public exponent: 65537
Validity: [From: Sat Aug 22 16:41:51 GMT 1998,
To: Wed Aug 22 16:41:51 GMT 2018]
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
SerialNumber: [ 35def4cf]
Certificate Extensions: 7
[1]: ObjectId: 1.2.840.113533.7.65.0 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 0D 30 0B 1B 05 56 33 2E 30 63 03 02 06 C0 ..0...V3.0c....
[2]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 H.h.+....G.# .O3
0010: 98 90 9F D4 ....
]
]
[3]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
[4]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[CN=CRL1, OU=Equifax Secure Certificate Authority, O=Equifax, C=US]
Despite the fact that Payara log (server.log) is populated after this with details, eclipse console not.
The used woraround was to use a tail -f server.log
PS: that happens to everybody in the office. So I guess it's something related with payara ssl expired certificate.
I'm using:
Payara Server 4.1.2.174 #badassfish (build 192) and Eclipse Java EE IDE for Web Developers. Version: Oxygen.3a Release (4.7.3a) Build id: 20180405-1200
I think You can simply remove the failing certificate from the keystore. For me the failing certificate had alias: equifaxsecureca and was stored in cacerts.jks
I used the following command:
keytool.exe -delete -alias equifaxsecureca -keystore cacerts.jks -storepass <your pass>
BTW. There is also another one that is failing: gtecybertrustglobalca

FreeIPA Server Error - ipa: ERROR: No valid Negotiate header in server response

I have recently installed FreeIPA on RHEL7. This seems to be running well for few hours and then calls to ipa starts to fail with the following error.
ipa: ERROR: No valid Negotiate header in server response
==================================================
[root ~]# ipa -v user-find --all
ipa: INFO: trying https://xxx.xxx.xxx.xxx/ipa/json
ipa: INFO: [try 1]: Forwarding 'user_find/1' to json server 'https://xxx.xxx.xxx.xxx/ipa/json'
ipa: ERROR: No valid Negotiate header in server response
-=================================================
[I have masked the hostnames with 'xxx']
In /var/log/httpd/error_log - I see the following error.
[Thu Dec 14 15:50:23.413286 2017] [auth_gssapi:error] [pid 10694] [client xxx.xxx.xxx.xxx:50198] GSS ERROR In Negotiate Auth: gss_accept_sec_context() failed: [Unspecified GSS failure. Minor code may provide more information ( Request ticket server HTTP/xxx.xxxx.xxxx.xxx#EC2.INTERNAL kvno 2 not found in keytab; keytab is likely out of date)], referer: https://xxx.xxx.xxx.xxx/ipa/xml
What is the possible cause? Looks like some misconfiguration.

SSL Handshake error with an Axis2 client on IBM JDK 6, SR 5

An Axis2 Client invokes a 2 way mutual SSL secured mainframe based webservice.
The client is running on IBM JDK6, SR 5
`
Caused by: com.ctc.wstx.exc.WstxIOException: Connection has been shutdown: javax.net.ssl.SSLException: java.lang.NullPointerException
at com.ctc.wstx.sw.BaseStreamWriter.finishDocument(BaseStreamWriter.java:1692)
at com.ctc.wstx.sw.BaseStreamWriter.close(BaseStreamWriter.java:288)
at org.apache.axiom.util.stax.wrapper.XMLStreamWriterWrapper.close(XMLStreamWriterWrapper.java:46)
at org.apache.axiom.om.impl.MTOMXMLStreamWriter.close(MTOMXMLStreamWriter.java:188)
at org.apache.axiom.om.impl.llom.OMSerializableImpl.serializeAndConsume(OMSerializableImpl.java:197)
at org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:74)
... 18 more
Caused by: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.lang.NullPointerException
at com.ibm.jsse2.sc.i(sc.java:401)
at com.ibm.jsse2.sc.j(sc.java:371)
at com.ibm.jsse2.j.write(j.java:23)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:76)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:134)
at java.io.FilterOutputStream.flush(FilterOutputStream.java:134)
at org.apache.commons.httpclient.ChunkedOutputStream.flush(ChunkedOutputStream.java:191)
at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:99)
at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:214)
at com.ctc.wstx.sw.BufferingXmlWriter.close(BufferingXmlWriter.java:194)
at com.ctc.wstx.sw.BaseStreamWriter.finishDocument(BaseStreamWriter.java:1690)
... 23 more
Caused by: javax.net.ssl.SSLException: java.lang.NullPointerException
at com.ibm.jsse2.n.a(n.java:13)
at com.ibm.jsse2.sc.a(sc.java:154)
at com.ibm.jsse2.sc.a(sc.java:515)
at com.ibm.jsse2.sc.a(sc.java:522)
at com.ibm.jsse2.sc.a(sc.java:146)
at com.ibm.jsse2.j.write(j.java:10)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:76)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:134)
at java.io.FilterOutputStream.flush(FilterOutputStream.java:134)
at org.apache.commons.httpclient.ChunkedOutputStream.flush(ChunkedOutputStream.java:191)
at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:99)
at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:214)
at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:311)
at org.apache.axiom.util.stax.wrapper.XMLStreamWriterWrapper.flush(XMLStreamWriterWrapper.java:50)
at org.apache.axiom.om.impl.MTOMXMLStreamWriter.flush(MTOMXMLStreamWriter.java:198)
at org.apache.axiom.om.impl.llom.OMSerializableImpl.serializeAndConsume(OMSerializableImpl.java:195)
... 19 more
Caused by: java.lang.NullPointerException
at com.ibm.jsse2.fb.<init>(fb.java:32)
at com.ibm.jsse2.hb.a(hb.java:262)
at com.ibm.jsse2.hb.a(hb.java:209)
at com.ibm.jsse2.gb.n(gb.java:140)
at com.ibm.jsse2.gb.a(gb.java:123)
at com.ibm.jsse2.sc.a(sc.java:320)
at com.ibm.jsse2.sc.g(sc.java:198)
at com.ibm.jsse2.sc.a(sc.java:599)
at com.ibm.jsse2.j.write(j.java:20)
... 29 more'
The application is hosted on WAS 7, fix pack 11
I tried going through the IBM forums for the fixes as part of SR 8 and I could locate this which is kind of close to my issue
http://www-01.ibm.com/support/docview.wss?uid=swg1PM35288
The link you posted shows that this issue was fixed in WAS 7 Fix Pack 19 and above.

two certificates with the same domain name

I have added two certificates into my server's(jboss) keystore with domain name in both as "localhost". So now if a local client accesses the server which of the certificates will be sent to the client.
There is no error thrown in jboss, and it is working fine. I just want to know how jboss is choosing which certificate to send?
Listing the contents of the truststore used by java program.
Your keystore contains 2 entries
tomcat, 5 Mar, 2012, trustedCertEntry,
Certificate fingerprint (SHA1): B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:
AB:28:E1:1E
tomcat1, 6 Mar, 2012, trustedCertEntry,
Certificate fingerprint (SHA1): C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:
DD:23:97:87
both tomcat and tomcat1 have the cn=localhost
Listing the contents of the keysttore used by jboss.
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
tomcat, 5 Mar, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:
AB:28:E1:1E
tomcat1, 6 Mar, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:
DD:23:97:87<br>
Displaying the keystore entry using th keytool's list "-v" option asper Kevin's request.
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
Alias name: tomcat
Creation date: 5 Mar, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost
Issuer: CN=localhost
Serial number: 5aaac34c
Valid from: Mon Mar 05 15:04:46 IST 2012 until: Sun Jun 03 15:04:46 IST 2012
Certificate fingerprints:
MD5: 6A:9D:10:37:4F:98:7F:85:D5:93:95:CC:C3:84:07:D8
SHA1: B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:AB:28:E1:1E
SHA256: FB:F5:BC:9F:17:E9:28:8C:77:1B:40:17:8B:D3:12:71:05:0D:CF:9C
99:00:C4:25:76:46:CE:E0:0C:E6:6B
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: F6 B3 2E B5 A0 76 78 7E 9D B6 2A D6 4A 6A 8D 96 .....vx...*.Jj..
0010: FA 7D 47 9B ..G.
]
]
*******************************************
*******************************************
Alias name: tomcat1
Creation date: 6 Mar, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost
Issuer: CN=localhost
Serial number: 4891416
Valid from: Tue Mar 06 06:41:21 IST 2012 until: Mon Jun 04 06:41:21 IST 2012
Certificate fingerprints:
MD5: B9:31:FE:75:E9:28:E6:BC:F2:94:60:93:7B:0C:00:63
SHA1: C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:DD:23:97:87
SHA256: 58:7B:D3:A1:2C:8E:C1:C9:26:0A:9F:A1:86:D1:79:76:34:D2:83:6A
88:0C:E1:36:F5:88:3F:DC:F7:D7:89
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: F1 BF 69 B4 CA D6 9E 72 AC C3 26 9F CD 57 58 7A ..i....r..&..WXz
0010: 62 19 8B B8 b...
]
]
*******************************************
*******************************************
By default, JBoss (or Apache Tomcat) will use the default settings the default X509KeyManager to choose which certificate to use: it will pick the first one it finds in the keystore that is valid for the type of key (e.g. RSA for an RSA-based cipher suite) and at the time of connection.
Failing that, if an alias is explicitly specified in keyAlias, it will pick the certificate in that alias (and it will fail if the key type isn't correct).
If, instead of this, the name of a custom class implementing SSLImplementation is given in the SSLImplementation attribute, it will be used to provide the SSLSocketFactory (so the alias choice will be done however its SSLContext/KeyManager is configured).
Support for Server Name Indication (SNI), which is what would allow the key manager to use the requested host name to help make a choice, was only introduced in Java 7, and only on the client side, so the JSSE cannot use it on the server side currently.
What exactly are you trying to achieve ? The certs are stored in the keystore and presented to the user based on hostname match. This is incorrect, please see below.
Logically speaking it would load only one of these which in turn will be served to the user.
--Edit--
Trying to simplify by pointing to another link
Say you specify "keyAlias" in your jboss configuration to "tomcat" ; then the tomcat alias will be picked up
If you do not specify an alias then the "first key read in the keystore will be used"