Errors

Common failure logs will have similar messaging to this:

####<Apr 13, 2020 6:55:42,390 PM GMT> <Debug> <SecuritySSL> <ma-alecapp-lapp05.corp.apple.com> <ms2> <srikanth> <<WLS Kernel>> <> <a214efba-2b24-4410-a1a1-cad25adcf50d-000000d8> <1586804142390> <[severity-value: 128] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000000> <[Thread[srikanth,5,Pooled Threads]]weblogic.security.SSL.jsseadapter: SSLENGINE: SSLEngine.wrap(ByteBuffer,ByteBuffer) called: result=Status = OK HandshakeStatus = NOT_HANDSHAKING

bytesConsumed = 32 bytesProduced = 85.>

####<Apr 13, 2020 6:55:42,458 PM GMT> <Debug> <SecuritySSL> <ma-alecapp-lapp05.corp.apple.com> <ms2> <[ACTIVE] ExecuteThread: '10' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <a214efba-2b24-4410-a1a1-cad25adcf50d-000000d8> <1586804142458> <[severity-value: 128] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '10' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]weblogic.security.SSL.jsseadapter: SSLENGINE: SSLEngine.wrap(ByteBuffer,ByteBuffer) called: result=Status = OK HandshakeStatus = NOT_HANDSHAKING

bytesConsumed = 4080 bytesProduced = 4133.>

####<Apr 13, 2020 6:55:42,804 PM GMT> <Debug> <SecuritySSL> <ma-alecapp-lapp05.corp.apple.com> <ms2> <ExecuteThread: '1' for queue: 'weblogic.socket.Muxer'> <<WLS Kernel>> <> <a214efba-2b24-4410-a1a1-cad25adcf50d-0000005a> <1586804142804> <[severity-value: 128] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000000> <Exception processing peer certificates: peer not authenticated

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:450)

How to Troubleshoot

The TeamConnect application by itself has no SSL restrictions and should accept any connections regardless of form however SOP vendors may have requirements for connecting to their service that your Java server needs to be configured for, to allow those connections to succeed.
 
There are some JVM settings that will have an effect on whether or not TC can connect to a specific service and it will depend on how the service is using encryption for what you must allow.
 
Primary arguments that will have an affect are:
    -Djdk.tls.client.protocols=ALL
    -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.2 
    -Dhttps.protocols=TLSv1.2
    -Dcom.sun.net.ssl.enableECC=false 
 
 
While TLSv1.2 is quickly becoming the standard as 1.0 and 1.1 are deprecated, some third party service providers will still use them, so you will want to check with any that you are not sure of to confirm which version they use.
 

• Djdk.tls.client.protocols -- this sets the minimum security that the java server will be willing to communicate on. Have it set to TLSv1.2 means any site or connection that does not use this encryption will not connect.  For troubleshooting an issue to determine if it is the protocol that is the failure point, you can set this to ALL and it will accept all SSL connections.

• Dweblogic.security.SSL.minimumProtocolVersion -- this is weblogic specific, and is overwritten by the rule above if that is in your JVM arguments, however this can also be used to set the lowest negotiation level of SSL for your server. Oracle has a complete write-up of how this argument works that can be found at https://docs.oracle.com/middleware/1...n.htm#SECMG637

• Dhttps.protocols -- this JVM argument controls the default SSL protocols that Java uses to connect. This will be needed if you are on a Java 1.7 environment to allow TLSv1.2 connections, however Java 1.8 has this support natively and this additional argument will not be needed. If you want it to use multiple protocols these will have to be added individually, so allowing all TLS connections would look like:

     "-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2"
 

• Dcom.sun.net.ssl.enableECC -- This argument is a limiter only, and restricts the type of security ciphers that SSL can negotiate with and can cause connection failures if the cipher that the site you are connecting to if they only uses ones that are restricted.

 
To enable most efficient debugging to locate any potential SSL errors, you will want to add this JVM argument:

-Djavax.net.debug=all  

This will output all the traffic logs and connections to ms2.out and ms2.log so they can be investigated for connections and failures. 
 

• To investigate a host to see what SSL versions they are using, you can use the openssl command:  
  • openssl s_client -connect <website:port> -showcerts

 
This will give you a detailed export including their encrypted certificate as well as ciphers they use. You will get an output something like the below, this one is from usoptest.ctadvantage.com:443
 
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: FF528954A2A6CCC9863B68B2AA0E1572A2AC3C23806D559FA5E67592BBDEA5C0
    Session-ID-ctx: 
    Master-Key: 26F027AC04B62499D2BB0FAC90390F580A4E071C7A88FAE237DBCBCFF98A3CD3BB40BD37B4CDCE4119C8ABEE773BCE11
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1586814498
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

An alternative option is to use www.ssllabs.com and enter the URL, that site does audits of all website SSL connections and will give you an easily readable list of all the ciphers that it uses. Shown here:
 

 
From there, you can confirm in your ms2.out for the ciphers you are attempting to communicate over and ensure that the sites is in the list you are using.  The ciphers you are using will come out as a big list that will look something like this:
 

•  Cipher Suites: [TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256]

 
In this example, if you compare the Cipher suites that the java server is using, with the one the highlighted in green from the openssl command or listed on SSLLabs, and you can see that they do not have one that matches, which will always cause a failure.