Configure HTTPS (SSL) using Windows cert store

[Mason and Hanger IT Department]

All of the documentation about enabling HTTPS for the web administration portion of Bitbucket use an issued certificate file either directly or installed in the bitbucket specific keystore.  Is there any way to have Tomcat use the built-in Windows key store so I can use my domain CA's signed Server certificate?

I'm wondering if at the very least i can export the signed server cert and use it directly, but then I would have to reconfigure this thing every time the Domain CA renews the cert.

[Martin Stenderup]

In %BITBUCKET_HOME%\shared\bitbucket.properties set the following configuration:

server.additional-connector.1.port=443
server.additional-connector.1.secure=true
server.additional-connector.1.scheme=https
server.additional-connector.1.ssl.client-auth=want
server.additional-connector.1.ssl.protocol=TLSv1.2
server.additional-connector.1.ssl.key-store=
server.additional-connector.1.ssl.key-store-password=
server.additional-connector.1.ssl.key-store-type=Windows-My
server.additional-connector.1.ssl.key-password=
server.additional-connector.1.ssl.key-alias=<friendly-name-or-CN>

[Dave Theodore [Coyote Creek Consulting]]

If you want to run on 443 and have people just type in https://bitbucket.domain.com you really should do this using a reverse proxy server.  In order for Tomcat to bind to TCP:443, it will need to be run as Administrator user (or with equivalent permissions.) That creates a attack vector in the event that someone exploits a Java vulnerability. This could lead to the attacker being able to take over the whole server, since they would be breaking in as Administrator user.

Best practice is to use a reverse proxy server, which will have the smarts to start and bind to the privileged 443 port, then spawn children running as unprivileged users. This also allows you to continue running Tomcat on an unprivileged high port and run as an unprivileged user.  If an attacker manages to take over the Java process, they will only have as much permissions to do damage as the user Bitbucket runs as.  

This also makes management of the certificates easier. When your SSL certs expire, you simply drop the new ones in to the correct directory, update the config file to use the new certs and restart the proxy. Managing certs in Tomcat requires an application restart.

Atlassian has docs on how to set up Apache, but the process is similar for other reverse proxy servers such as IIS, nginx, etc.

[Mason and Hanger IT Department]

I appreciate the information, and please forgive my limited network security knowledge.  I'm not sure if it makes a difference, but using 443 specifically is not required, and this server will not be available outside our LAN.  This is just a small single server instance we are running internally for about 5 users.  I imagine the vulnerability you described above has to do with the Tomcat implementation of SSL, and doesn't matter which port it runs on.  

I'm not sure there is much benefit running the reverse proxy unless i also added ACLs to only allow the reverse proxy service to connect to the bitbucket server, otherwise users/attackers could just access the server directly.

I haven't found any documentation showing bitbucket running on IIS, so I doubt that's an option.  If there is a security benefit in the reverse proxy, I could use the IIS instance I have on this server already to run the reverse proxy per this document, and use the domain server cert in IIS.  What would this mean for bitbucket/tomcat though?  Could tomcat use the same domain signed cert?