Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Got TLSv1.2?

If you're terminating SSL on your Jira server, something administrators miss quite often is setting the ciphers to secure and disabling protocols such as TLSv.1.0 and 1.1.

How to check your settings?

First, go to SSLLabs and drop in your Jira url.  Give it a test.   You'll get a cool looking report card on how you're doing and what you need to do to fix things.


Second, review your server.xml file.  On your Jira application server, this is typically located under the Jira_Home directory in the conf folder.    Scroll down that file and check your connector settings, you'll see something like:


if you don't see a line that says "ciphers=".....", you may have a problem.

How to fix it?

So you got a B on your SSLLabs score, and your connector settings in your server.xml look kind of lame.    Lets fix it.

Open back up your server.xml file and lets force sslprotocol to TLS1.2 and lets setup some secure cipher usage.  The final product should look something like:

SSLEnabled="true" acceptCount="100" clientAuth="false"
connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false"
keyAlias="AwesomeKey" keystoreFile="keystore" keystorePass="rockingpassword" keystoreType="JKS"
maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="443"
scheme="https" secure="true" sslProtocol="TLSv1.2" sslEnabledProtocols="TLSv1.2" useBodyEncodingForURI="true"

 Obviously, use your own keystore folder and keystore password.

Next, run the SSLLabs test again:


You've done it!

Congratulations, you're now one bit more secure.   

Now a few notes of caution.  Always test this sort of change on your staging environment first, and I've done this on Jira 7.4+. 

Can I use this configuration on Confluence?

Yes, absolutely.... go for it... but do it in your staging server.xml first, please :)

I use Bitbucket, what's its TLSv1.2 Setting?

BitBucket uses a slightly different configuration.  Look in the file found in Bitbucket\shared\ folder.  The configuration  lines you need will look like:


Last, last note... remember any time you change these config files, you need to restart your instance.  So, service stop/start/restart or restart your application server.


It's possible to get an A (A+ in fact) with older TLS still enabled so you're not killing non-modern clients. Our networking guys insist on using some awful Cisco WAAS product that only supports TLS 1.0! So we have to leave some things I'd rather have off enabled.

And yet, here's our box:


The key to doing this safely (and avoiding downgrade attacks) is a good reverse proxy like nginx and the ssl_prefer_server_ciphers on; directive that we have ourselves on line 47 of this config here. Check out the full repo to get all the files you need for a ballin nginx setup (but generate some new DH primes ;) ). But for sure, get rid of those awful export grade ciphers.

Awesome, thanks for this.   I certainly agree - installing a Web Application Firewall and doing ssl offload is certainly better and better performing, especially in busy environments.   SSLLabs has some score limiters in place, for instance TLSv1.0 will limit your protocol score to 90%, 1.1 will limit you to 95% and I think that's what we see in your scorecard accurately.

Just as a note, as an industry - TLSv.1.0 is going away.  If you deal with PCI, Office365, and Salesforce for example in your org, you know it must be gone soon and clients that touch this data must support higher protocols with heavy preference to TLSv1.2.

My recommendation is really if you're stuck and can't deploy a higher protocol you should consider mitigating risk and remove applications not supporting TLSv1.2 from public facing.

Adding some information here.

I certainly agree - installing a Web Application Firewall and doing ssl offload is certainly better and better performing, especially in busy environments. 

This is what most of setups are done and I would like to recommend the following. The OP discusses about how to achieve a good rating via Tomcat and SpringBoot.

This is what I generally base my security settings off. Give the Mozilla SSL Configurator a go:

The configurator gives users a number of configurations for different proxies like Apache, nginx and ELBs. If the environment is suitable, we generally recommend a reverse proxy in front of the Atlassian application (or any application for that matter) to offload SSL. Using them gives users a a wider set of security configurations to set and control.

Edit: Grammar and spelling.

Great to see technical posts like this, as well as community members contributing their configs back.


Log in or Sign up to comment

Atlassian Community Events