Application Links over HTTPS not working (Cert Problem?)

[Daniel Jilg]

My company is using Jira and Confluence at the moment (and probably will be using Fisheye, Crucible and Crowd later on) and I can't get them to connect to each other using application links over HTTPS.

It worked when I was using HTTP, but for security reasons, the company asked me to allow only encrypted communication with the server that hosts the Atlassian software. So I created a self-signed certificate with the Common Name "dev.mycompany.com" and changed the connector string in c:/Atlassian/Jira/conf/server.xml to read as follows:

<Connector protocol="org.apache.coyote.http11.Http11Protocol" port="8443" maxHttpHeaderSize="8192" SSLEnabled="true"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true" useBodyEncodingForURI="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" keystorePass="XXXX" keystoreFile="C:\Atlassian\Security\.keystore"/>

I also changed the Server Base URL to the correct value. This works: I can reach the Jira server at https://dev.mycompany.com:8443. I changed the Confluence configuration similarly, and this works as well.

However, Jira and Confluence can't communicate with each other. Instead, when I create a new Application Link in Jira and paste the Confluence server's URL into the error message "The host is unknown. Verify that the URL is correct."

I presume this is because of the self-signed certificate. Do I have to import that somewhere, so the servers both trust the certificate? Do I have to change it somehow? Any other workarounds?

Edit: This is Jira 4.3.4 standalone and Confluence 3.5.5 standard running on Windows Server 2008 R2 Enterprise.

[Andy Brook [Plugin People] · Accepted solution]

Short story, you need to import the certificate signer (you) into your JRE trust store as per: http://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services

When a Java application connects to an SSL host it MUST be able to validate its signer. In the case of a self signed cert you will have problems. To validate this, use the test SSLPoke class I contributed, If you cannot open a simple SSL socket connection to your server in a few lines of Java, neither will Confluence be able to do the same for Jira.

The less grief way is to not use a self-signed cert, and to use a paid-for certificate, whos CA chain is _probably_ validatable via the existing JRE certificate cacerts file. I say _probably_ as some companies, eg Verisign like to introduce the concept of an intermediary CA, which is frankly annoying, as the Chain of Trust is broken and _that_ intermediary CA _still_ needs importing into your JRE CACERTS file.

[Daniel Jilg]

Why didn't I find this page? Thanks, I'll check it out and report back.

[Daniel Jilg]

Okay, I imported the certificate into Java's cert store, but when I run the SSLPoke tool, it still crashes with an UnknownHostException. Any ideas?

[twong_atlassian]

Unknown host exception usually denotes that the other server's dns name is not resolvable from the source server: Could you verify by simply running an nslookup from each server looking up the other's DNS name?

[Daniel Jilg]

Tim, indeed it appears to be a DNS issue: nslookup on the server returns the wrong IP. I'll try to fix that and check if the problem persists.

[Daniel Jilg]

Fixing the DNS and changing the certificate's common name made the servers communicate with each other. Thank you very much, gentlemen.

[Haig Bedrosian]

@Ahjaz(and anybody else connecting externally over HTTPS and internally over HTTP via apache reverse proxy on the same server), you can get around the Java SSL self-signed certificate issues and establish application links by making direct connections to your tomcat application instances over HTTP. This can be done by using "http://localhost:{PORT}" as the base URL when setting up an application link, where {PORT} is the port number to which your desired tomcat application instance is bound.

It seems so darn obvious now but it sure wasn't when I was attempting to configure things the first time around. Hopefully this helps others save a little time and aggravation. Paying it forward.

[Robert Westman]

Hello. I knows it's been almost a year, but maybe you will get a notification and help me out. I didn't quite understand what you did. My problem is also, that i can't seem to get the trusted links to work. I tried using the apache proxy with http or ajp protocol, but neither worked. In the tomcat documentation i didn't find any base url option for the server.xml Im at my wit's end and quite frustrated.

[Haig Bedrosian]

It's not in the Tomcat settings but in Jira where you setup the application links. That's where you'll find the base URL field.

[Robert Westman]

Ah ok damn, thats bad. Im using crowd sso and the authentication cookie won't work if the base url is not the one the users are trying to connect with. Why is this application linking so complicated and the documentation on this topic so lackluster... Its one of the things you look forward to when using all products of one vendor :(

[Ahjaz Hussain]

This was resolved,

created two connectors in server.xml for both jira and confluence. http for internal communication via the server only.

Do not require SSL internally...

Thanks

[jbratu]

This was a great solution. In each server.xml file I created a second connector on a different port i.e. 8081 for Jira and 8091 for Confluence. When creating the application link I used the IP and internal HTTP port number for the other server. I.e. http://192.168.0.2:8091 to link Jira to Confluence. Jira determined the correct display link which referenced HTTPS.

[Tobias Schander]

Please mind this Bug https://jira.atlassian.com/browse/CONF-34608 in this Setup.

[Ahjaz Hussain]

Hi mbrinson

Rather than starting a new thread, I am been experiencing issues with JIRA and Confluence application links, which has never worked since enabling SSL through apache.

oth JIRA and confluence are on the same serverand installed Apache behind JIRA as follows Client Browser - >HTTPS --> Apache Proxy --> HTTP --> Tomcat/JIRA

I cannot access JIRA or confluence on the local server with localhost:8080 or the FQDN, as I need to configure application links, also I am only terminating ssl from apache only.

Any help is appreciated, I have been stuck with this issue for weeks now,

[Renjith Pillai]

Hey Ahjaz,

what does nslookup <<your jira fqdn>> say while running on the JIRA server?

[Michael Brinson]

Just wanted to follow up here (since this post has been resurrected), and say thanks to Jordan Tomkinson. His tip on using the AJP protocol was jus what I needed. It's been a long time now since I got it working correctly, so I can't be sure that it wasn't something else I did (in addition to switching to using AJP), but I do remember liking the way that AJP performed better.

Anyway, it's working now (and has been for some time) and it's set up with AJP.

[Davet]

Whether you have AJP or HTTP the problem is the same.

Make sure that you are looking at the correct cacerts directory (I have seen four or five on some servers:(

I use a standalone jdk so that i don't have to import the certificate every time I upgrade Confluence/JIRA

In fact you dont have to touch apache or jdk during an upgrade

[joseph brown]

Thanks for this post, i will try that.

[Moodle Sysadmin]

See:

http://confluence.atlassian.com/display/JIRA/Configuring+Apache+Reverse+Proxy+Using+the+AJP+Protocol

It's basically the same with Confluence, we have Jira + Crowd set up this way and our apache proxy handles SSL.

[Moodle Sysadmin]

Try using AJP instead of HTTP for the tomcat listener as per the atlassian documentation when using tomcat behind an apache proxy

[Michael Brinson]

Which documentation are you referring to? I've seen several different docs on this setup. Most of them point in the direction of using the method I've set up.

I'll try to find the documentation on the AJP method and see if I can get it working that way.

Thanks!

[Michael Brinson]

Daniel - have you gotten this to work without issues? I've got mine set up behind apache proxy (ssl) and have jira and confluence talking to each other via http (presumably).

The problem I run into is that right after I create an application link between them I get the message "Application seems to be offline. Click here to relocate."

I've looked through the apache logs and as nearly as I can tell this is because everything gets redirected through the base url which, of course, uses https. I guess that since jira and confluence aren't set up to talk https then a request comes through between them (instead of coming in through the proxy) and then they can't find each other? I don't know. I'm at a loss. Been working on this for weeks now...

[Daniel Jilg]

Sorry mbrinson, I have no clue what the culprit in your situation might be. I ensured the following things, and then it just worked:

• The certificate was fully trusted and valid (see Andy Brooks answer and comments) and
• The server could find itself using the address used in the cert (try editing the server's host file to try out different values if you're not sure)
• And that's it.

[Daniel Jilg]

While researching this, I found another workaround for the problem, other than the solutions proposed by Andy Brook and Tim Wong: I re-enabled the unencrypted connectors in Jira's and Confluence's server.xml files, so they could talk to each other over plan HTTP. At the same time, I blocked the ports the HTTP connectors used in the server's firewall, so no outside access to these ports is possible.

Are there drawbacks to this way? Presumably you'd have to configure both sides of the application link manually, since the URL used is different than the stored base URL.

Edit: Just noticing, you can in fact set the reciprocal URL to any value you want. Nice.

[Srini Balakrishnan]

hi, can you share the server.xml file connectors and explain what do you mean by unencrypted connectors?