Problems configuring SSL for Bitbucket

[Kevin Berger]

We are trying to configure HTTPS in BitBucket (Version 5.2.1) using https://confluence.atlassian.com/bitbucketserver/securing-bitbucket-server-with-tomcat-using-ssl-776640127.html#SecuringBitbucketServerwithTomcatusingSSL-configuretomcat as a guideline. We imported our existing certificate, which is working in our Jira instance, into a new file called ssl-keystore.

However, when we try to start the BitBucket service, we get error:

2017-07-17 13:40:39,270 ERROR [main]  o.a.coyote.http11.Http11NioProtocol Failed to start end point associated with ProtocolHandler ["https-jsse-nio-8443"]
java.lang.IllegalArgumentException: java.io.IOException: Alias name [tomcat] does not identify a key entry

When we imported the certificate using keytool, we explicitly set the clause "-alias tomcat".

Any troubleshooting suggestions would be appreciated.

[Christian Glockner · Accepted solution]

Hi Kevin,

It sounds like you imported the certificate into the keystore but not under the name that Tomcat expects, tomcat. To fix this you'll need to add an additional attribute to the Connector element in server.xml, keyAlias that stores the alias that the certificate in question is stored under in the keystore.

You can find more on this in the Tomcat documentation.

Edit: Never mind, I should read before I post. You said you did provide the -alias switch when importing the keystore. Can you run 

keytool -list -keystore <keystore>

(where <keystore> is the keystore filename) and provide the output here?

Cheers,

Christian

Premier Support Engineer

Atlassian

[Kevin Berger]

Hi Christian,

Thanks for responding. We decided to try the original pfx file that was generated as part of the CSR process and that ended up working. We got this working fine on a couple of dev servers. However, when we tried to get this running on our prod server, we got an error:

"o.a.coyote.http11.Http11NioProtocol Failed to start end point associated with ProtocolHandler ["https-jsse-nio-7990"]
java.lang.IllegalArgumentException: java.io.IOException: Invalid keystore format"

So we decided to compare the dev versus prod servers to see what the difference might be. One obvious difference is the Java JVM version. The dev servers that work have Java 1.8.0_66 and 1.8.0_102 installed; our prod server is 1.8.0_40.

So we want to see if we can replicate the problem on the dev server with Java 1.8.0_66 installed. We uninstalled Java and reinstalled 1.8.0_40 however cannot even get service to start. Commons-daemon log indicates error: "Failed creating java c:\program files\java\jre1.8.0_66\bin\server\jvm.dll" so the config is still pointing to previous version.

1. How can we change the Bitbucket config to point to a different JVM?

2. Any other troubleshooting suggestions?

Kevin

[Christian Glockner]

Hi Kevin,

Bitbucket looks at the JAVA_HOME environment variable to determine which JRE to use (see this document for more details).

I personally doubt that the JRE version is a factor here to be honest, especially since the version difference is minor.

Did you update the Connector element in server.xml to reflect that the keystore type is not JKS but PKCS12? You'll need to change it to keystoreType="PKCS12".

Cheers,

Christian

Premier Support Engineer

Atlassian

[Kevin Berger]

Hi Christian,

Is the server.xml file still relevant for BitBucket 5.x? The migration guide implies that this file is no longer relevant and has been replaced with bitbucket.properties; as the migration guide has section on how to apply server.xml customizations to bitbucket.properties.

Kevin

[Kevin Berger]

Also regarding Java, we verified JAVAE_HOME is set to "C:\Program Files\Java\jre1.8.0_40" (would be irrelevant if we can get this running on our prod server though)

[Christian Glockner]

Hi Kevin,

You're right in Bitbucket 5, server.xml is no longer relevant for those kinds of configurations. As everything is now in bitbucket.properties, you'd need to add the parameter server.ssl.key-store-type=pkcs12 to that file if your file is in PKCS12 format.

Cheers,

Christian

Premier Support Engineer

Atlassian

[Kevin Berger]

Hi Christian,

On our test server with Java 1.8.0_102 installed, it works for both server.ssl.key-store-type=jks and server.ssl.key-store-type=pkcs12. So we will try this on our prod server, which we will not be able to do until tomorrow morning. I still find it strange why it works on our dev servers but not prod. Anyway - I will let you know the results tomorrow.

Kevin

[Kevin Berger]

Hi Christian,
After implementing server.ssl.key-store-type=pkcs12, the https configuration is now working. We are having our developers verifying everything works: Bitbucket integrations with Bamboo, Jira, git

Kevin

[Christian Glockner]

Hi Kevin,

Great to hear that things appear to be working now!

Cheers,

Christian

Premier Support Engineer

Atlassian