How to configure Bitbucket Docker for AD auth via SSL

[Adam]

Using the official Atlassian Bitbucket image I've written a docker-compose file, which gets Bitbucket working with SSL via an Nginx container. 

Everything works well except when I attempt to configure the Active Directory integration using SSL (non SSL AD traffic over 389 works fine).

When I click "Save and Test" I get an error:

"Connection test failed. Response from server:

<servername>:636; nested exception is javax.naming.CommunicationException: <servername:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: uname to find valid certification path to requested target]"

I've tried mounting the host CA certificates into the Bitbucket container at /etc/ssl/ca-certificates.pem, however this didn't resolve the issue.

Does anybody have any ideas as to how to resolve this issue with the Bitbucket container?

[Adam · Accepted solution]

Following the instructions here:

* https://confluence.atlassian.com/kb/unable-to-connect-to-ssl-services-due-to-pkix-path-building-failed-error-779355358.html

* https://confluence.atlassian.com/kb/ssl-and-application-link-troubleshooting-guide-719095282.html

* https://confluence.atlassian.com/bitbucketserver/migrate-server-xml-customizations-to-bitbucket-properties-897811761.html

I've created a keystore and mounted it into the container at: /var/atlassian/application-data/bitbucket/shared/config/ssl-keystore.jks.

This keystore was populated with the root & domain CA certs and the local machine cert.

I then updated bitbucket.properties to add:

server.secure=true                     # Already set via container env properties
server.scheme=https                    # Already set via container env properties
server.proxy-port=443                  # Already set via container env properties
server.proxy-name=bitbucket.domain.com # Already set via container env properties
server.ssl.key-store=/var/atlassian/application-data/bitbucket/shared/config/ssl-keystore.jks
server.ssl.key-store-password=<PASSWORD>
server.ssl.key-password=<PASSWORD>
server.ssl.key-store-type=jks
server.ssl.protocol=TLSv1.2

I still get the same error when attempting to change the AD User Directory configuration to SSL.

[Adam]

Finally figured it out.

It seems that for some reason the Bitbucket:6 container ignores its own keystore, regardless of what you put in the bitbucket.properties file.

This is how I fixed the issue:

Strip all of the server.* entries from bitbucket.properties

Copy $JAVA_HOME/jre/lib/security/cacerts from the container to the host

Use keytool to import your CA certs into this file

Mount this updated file back into the Docker container at its original location.

Note: My Nginx container is configured with certificates to do the HTTPS redirection.

[Riya Sander]

Wildcard SSL Certificate can help in this. you can get it from here https://www.clickssl.net/cheapest-wildcard-ssl-certificate-for-sub-domains

[Julius Davies [bit-booster.com]]

Personally I don't like touching $JAVA_HOME/jre/lib/security/cacerts. Mainly because you need to remember to re-apply your edit every time you receive a Java update!

I prefer to grab a proper wildcard cert and put that in front of AD (Active Directory).

There's a 2-year wildcard here for $84:  https://www.ssl2buy.com/alphassl-wildcard.php

I use that $84 cert in my own environment and it's fine with Java 6, Java 7, Java 8 and all newer Javas.

(Why not use a free Let's Encrypt cert instead? The problem with Let's Encrypt is that some older Java's don't work with it, and its 90-day expiry, while good for security, is not great for things like AD).

p.s. I have no relationship with any SSL certificate vendor.  Just sharing my own experience here.

[Adam]

Our environment is isolated - no Internet connectivity and multiple tiers of internal CAs, so I had limited options.

By re-mounting the cacerts file back into the container as a persistent file/volume (read only), that should work around any update scenarios.

[Julius Davies [bit-booster.com]]

I hear you.  I used to be the bitbucket admin for a mid-size financial (around 1000 staff total, including 100 developers).  Convincing the windows infra team to do anything to make my life easier usually took several months - not exactly an option when Bitbucket needs to be up & running yesterday!