0

For the past few days we have been attempting to setup Fisheye with TLS setup. We have gone through the process of setting up our TrustStore with our companies internal CA and setting up a seperate keystore with the host level certificate. We then updated the config.xml file with the ssl settings with excluded and included protocols. Here is what this looks like:

<web-server>
 <http bind=":80"/>
 <ssl truststore="/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts"
 keystore="/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/hosts.jks" 
 keystore-password="****" 
 bind=":443" truststore-password="*****">

<proxy-info/>

<excludeProtocols>
  <protocol>SSLv1</protocol>
  <protocol>SSLv2</protocol>
  <protocol>SSLv3</protocol>
  <protocol>TLSv1</protocol>
  <protocol>TLSv1.1</protocol>
</excludeProtocols>
<includeProtocols>
  <protocol>TLSv1.2</protocol>
</includeProtocols>
</ssl>
</web-server>

Upon testing we keep getting the following error in the browser.

enter image description here

Since we are using the latest version of Chrome, my suspicion is this is related to the ciphers or cipher suites the web server is using. However, I could not find any documentation on how to set them for the fisheye config.xml. I found a couple of plugs of using a reverse proxy server, however, this is not an option for us. I also found an article related to the keystore type but, this did not help us. If there is any documentation on how to setup ciphers or cipherSuites inside of the config.xml file. This would help us considerably.

If this requires making changes to apache directly, we are open to this as well.

Finally if this is the incorrect forum to post this type of question, please let us know and we will move it to the correct forum.

UPDATE 4/23/19: Tim Brigham, Thanks for the guidance,

In running the following command:

openssl s_client -connect fisheyetest.us.corp:443 -tls1_2

We receive the following output:

CONNECTED(00000005)
140735531881416:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.3/libressl/ssl/s23_clnt.c:541:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 318 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
---

It appears the negotiation is not getting the the ciphers and failing on trying to use SSLv3. Is there a way to change it.

UPDATE: 4/25/19 After banging my head around this last night and today, I have not been able to make much headway. Here is what I tried: - Removing the included and excluded protocols from the config.xml file - Check the permissions of the keystore. - Review the logs (to TLS or SSL related errors or errors related to the keystore or truststore) - Change the keystore type from JKS to pkcs12 and vise versa

In the latter step, the only thing I was able to get is a slightly different error message: enter image description here

Using the openssl command provides the same exact error. If I remove the -tls1_2 argument, it does the same.

I am stumped on this one. I am really surprised on this is so difficult. Any additional advice would be appreciated.

Gerald Schneider
  • 19,757
  • 8
  • 52
  • 79
thxmike
  • 153
  • 1
  • 10

3 Answers3

2

Before you do anything else you need to check which ciphers that your instance is actually providing. There are a couple ways of doing this, using either openssl s_client or nmap or my preference of using Wireshark to capture the SSL handshake

Once you have identified exactly what you are offering it should be fairly easy to see why your connection fails.

EDIT: Based on your output you don't have a server certificate being presented. It should be listed almost right under the "connected" output. I'd suggest turning off all your excludeprotocol entries for the time being and then work out why your cert isn't being presented. It could be something as simple as the permissions on the keystore or / format of keystore / needing to have the certificate name passed in.

Tim Brigham
  • 15,465
  • 7
  • 72
  • 113
0

We had same problem with very quiet jetty.

Solution was finally: JKS truststore must contain a key (private/public) with the same password as the JKS truststore itself.

Mario
  • 1
0

I was able to figure it out after 3 days. Ugh!. I had to include the entire certificate chain in a p12 file and then import into the keystore in non pkcs12 format. It was not enough that had my ca references in the trust store. Here are the commands I used to get this to work

First, I generated a combined pkcs12 formatted file (cert.p12) with the following command.

openssl pkcs12 -export -out cert.p12 -in host.pem -inkey key.pem -CAfile cacerts_root.pem -caname root -name jetty -certfile cacerts_int.pem

Second, create a new store with pkcs12 formated file:

keytool -importkeystore -deststorepass ***** -destkeypass ***** -destkeystore /path/to/jks-file/host.p12 -srckeystore cert.p12 -srcstoretype PKCS12 -srcstorepass **** -alias jetty

Finally, I updated config.xml file with the appropriate settings:

<web-server>
<http bind=":80"/>
<ssl truststore="/path/to/trust-file/cacerts"
truststore-password="*******"
keystore="/path/to/jks-file/host.p12"
keystore-password="********" bind=":443"><proxy-info/>
</ssl>
</web-server>

Restarted, and it came up. This was a huge pain. There was no logs, no errors to go by and no much on the documentation front. 

I tried the openssl command

openssl s_client -connect my.web.site:443

but this did not help. It kept telling me:

No client certificate CA names sent 

There has to be some better tooling to help diagnose these issues or Atlassian / Jetty / Tomcat should create this tooling. 

Thanks

thxmike
  • 153
  • 1
  • 10