Any plans to provide a simple way to enable SSL certificates with Jira?

[NCCER Hostmaster]

Atlassian currently does not support applying SSL certificates to a Jira server.

This scares me a little, because it seems like such an obvious and critical core function of any web platform.

I understand that you can't support every platform, every CA, every form of certificate.

But my ten-year-old PBX allows me to paste some cert text into a couple of boxes and I've got SSL encryption.

I look at the features available in the admin interface, and I just can't understand why this is the thing that's too hard to achieve.

Is this a Java thing? It seems like other Java-based platforms have a similar attitude towards SSL, like it's an unimportant afterthought.

[Nic Brough -Adaptavist- · Accepted solution]

It's the "platform" point that I think matters here.

Jira itself has no SSL capability, and it should not have to. It runs on a platform (or actually a couple) that should be handling the SSL.

When someone asks about SSL and Jira, there are two sides to think about - outgoing and incoming.

On incoming, I don't think Atlassian can really do a lot about SSL.  There are too many ways you might do it to try to support them all.  I have a preference for "Terminate SSL at the proxy", as that's what I've been taught and done the most, but even there, there's a stack of options, and do you really want to give your Jira system the rights to edit your entire network proxy settings?  If you're doing SSL by proxy, Jira should never be the place to do it.  You could do it in Tomcat, but again, you'd need to give the Jira admins the right to edit the Tomcat setup, which may not be right for you.  Those things might be ok for a small install where your Jira admins are also the server admins and possibly network admins, but you'd still need to do a load more config to allow Jira to make all those remote system changes.

Outgoing SSL would be a lot easier to do - you just need to give the Java system running Tomcat a certificate that says "you can talk to another system".  You still have the (relatively easy to fix) security issue that this would mean letting the Jira/Tomcat process root access to server.  Atlassian have done some of it - there's already a "Configure SSL" link buried in the admin menu that gives you an "import certificates" box.  Paste a cert into it and it generates a file that is "current certs + new one" which you can then give to the system admin and ask them to replace the existing one in the Java that runs Tomcat.

TLDR - I feel the pain of SSL on a platform, but I think Atlassian have got as close as they can without getting into a myriad of security issues.

[NCCER Hostmaster]

Thanks for pointing out the existence of the Configure SSL option, I probably should have made it clearer from the beginning that I'm using the Jira Installer. I certainly understand that you don't want to box people into a single approach, and different environments have different requirements. But when you run what seems to be a turnkey installer on a clean box, and the product that comes out at the end is missing critical components, and then Atlassian says they DO NOT SUPPORT making it secure, that's a bit off-putting.

The Jira installer actually installs the Java environment and Tomcat itself. Jira itself set up Tomcat, so why not put a self-signed cert in there too?

I'm not trying to be a jerk, I'm coming at this from the perspective of someone who downloaded what I thought would be a turnkey installer, and discovered that it's unusable, and that to make it usable, Atlassian tells me to install X11 on my server so I can run a third-party GUI tool. There's no way I'm going to do that, but I can't open a ticket and ask for assistance because making the installed product secure is not supported. 

I just feel that a default, out-of-box installation should provide some level of connection security. Maybe that's unrealistic of me, but I know I'm not the only one who feels this way.

[NCCER Hostmaster]

I believe the real problem is that Atlassian describes this thing I downloaded as an "installer" when it's clearly more of a prototype/demo tool.

[Nic Brough -Adaptavist-]

It's definitely an installer - you run it, you get a running installed usable version of the software.

Sure, it's rarely got everything most of us want it to do, but I wouldn't expect an installer to try to cope with the 5,000ish variations I've installed over the years, especially as the overwhelming majority of that configuration is well outside the application and often shouldn't be touched by service users.  The ultimate faff of doing SSL in one way limits the install, making it harder for the 99% of us who do NOT want to do it that way.

[NCCER Hostmaster]

Sorry, but my definition of a usable web application is one with encryption. Anyone hosting an unencrypted website of this nature should be fired. Usable doesn't mean you can click links and things happen, it means you can actually use it. And this is unusable for production. Period.

[Nic Brough -Adaptavist-]

Ohh, no, I'm completely with you on encryption.  There's no need to say sorry for encryption, I suspect I'm totally on your side there.  I should say sorry for leaving that out!

That should happen for any website that allows someone to write data (Public information that should be shared, read-only - no encryption.  The instant someone should write data - encrypted)

The problem here is that there are so many different ways of doing it.  And, I think I kind of reacted to one part of what you said without explaining it.  Self-signed certificates should not be used for shared systems.  So there's no way I'd want that in there automatically. 

And, making it part of the installer means you would need to provide a way to install certs in Apache, nginx, lighttpd, cherokee, hiawatha, mongrel2, and, that's a fraction of where to do it, and I've not even started on load balancers...

[Steven F Behnke]

It takes literally minutes to get apache up and running including SSL. You SHOULD be proxying tomcat and taking advantage of what a webserver actually offers.

https://confluence.atlassian.com/kb/securing-your-atlassian-applications-with-apache-using-ssl-838284349.html

[NCCER Hostmaster]

So if it's something I SHOULD be doing, why doesn't  the installer actually do it? Why isn't it part of the setup? Why isn't the process supported by Atlassian?

If I SHOULD be doing it, why doesn't Atlassian SUPPORT doing it?

I don't mean provide a link to a brief description, I mean SUPPORT - actively support - the best practice that we all know is absolutely mandatory for any production web application.

I'm not compiling a kernel, I'm not adding a repository, using a package manager. I'm running an INSTALLER provided by Atlassian specifically for the purpose of getting a production Jira install up and running, and when the process is complete, I have an unusable insecure application.

Am I really the only one who thinks this is a bit weird?

[Steven F Behnke]

While I understand where you're coming from, it's alway been marketed as enterprise software. I see systems knowledge as integral to enterprise software. Adding ssl to tomcat is not a use case atlassian needs to provide in app, because it's supposed to be managed by a Servlet Container savvy systems administrator. 

[NCCER Hostmaster]

So basically, Atlassian doesn't give a damn about my use case. Got it.