Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Jira and Confluence integration issues: self-hosted

dharmaj June 4, 2018

I have Jira and Confluence installed on same server on centos 7.4 virtual-machine.

I have Jira installed behind nginx for https access while Confluence is not but that can change in future. I did import SSL cert (and CA bundle) that I am using for Jira using /opt/atliassian/confluence/jre/bin/keytool and it was successful.

But I still don't have working application links between Jira and Confluence.

Please note here that I don't know what to enter for:

Consumer Key, Shared Secret or Public Key fields during the integration.

 

P.S: I am using Jira v7.10 and Confluence v6.9;

 

1 answer

0 votes
Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 5, 2018

It sounds like you are encountering a similar problem as this thread: https://community.atlassian.com/t5/Jira-questions/Application-Links-Consumer-Key-Consumer-Name-Public-Key/qaq-p/304670

In that thread, it is explained that you typically should not need to enter Consumer Key, Shared Secret, etc when creating this application link as these are pulled automatically.  The fact that you are being prompted for these is usually an indication that the sites can't talk to each other, usually because of a proxy.

One way around this is to follow the guide in How to bypass a reverse proxy or SSL in Application Links.   This can be a helpful means to get the two applications connected to each other without using SSL.  Since both sites are on the same server, you could create a connector in each application that only listens to an internal address, like localhost.  That way the applications could still talk to each other, but if you wanted to restrict outside users from reaching on that unsecured interface you could still achieve that.

dharmaj June 6, 2018

Thank you Andrew for your reply. I understand that if it asks me to enter consumer key, shared secret that means something went wrong. In order to fix that I tried adding 2 connectors in order to get it working; now there 2 things:

1) After adding 2 connector I had no luck adding application link successfully.

2) due to 2nd connector I can no longer browser jira from my proxy-url. It takes me to jira dashboard but when I click on any url it takes me to standard port:
e.g: dashboard is displayed on https://sub.domain.com:8081/ and when I click on any link it takes me to https://sub.domain.com/JIRA-ID which is "NOT FOUND".

Here are my connector code:

 <Connector port="8080" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false"
maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443"
acceptCount="100" disableUploadTimeout="true" bindOnInit="false"/>

 

 <Connector port="8081" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false"
maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443"
acceptCount="100" disableUploadTimeout="true" bindOnInit="false" secure="true" scheme="https"
proxyName="sub.domain.com" proxyPort="8081"/>

I have spent quite a bit of time to get this working but no luck so far.

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 7, 2018

The purpose of creating the second connector was to eliminate SSL from the equation for the time being.   As such, when following that guide, the URL used to link the two applications should use http, not https.

So for your first connector of :

 <Connector port="8080" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false"
maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443"
acceptCount="100" disableUploadTimeout="true" bindOnInit="false"/>

You should be able to connect to the site directly using an address like http://localhost:8080 when you're on that server.   Since this connector is not being utilized by a proxy, this would be the preferable option to use when creating an unproxied application link.

Conversely, Confluence, the other application would also be expected to have an unproxied connector in its server.xml that could then serve up content in this manner.

dharmaj June 7, 2018

HI Andrew,

Thank you for hanging in there with me. I did fall back to the basic non-https, no-proxy links using ip address and accessed both jira and confluence as following:

http://192.168.1.49:8090/wiki

http://192.168.1.49:8080/jira

 

Everything was fine, I was able to successfully link both application and link/search Jira issues from within the confluence. It was great.! 

and then I reverted back to my proxy connector to use website using sub.domain.com (using previously posted connectors). I had to comment the other connector using which I linked 2 apps as if I don't do it images/icons won't load in Jira.

So now when I am accessing both these software from production URL using https here is the error that I am getting (on both Jira and Confluence):

Invalid OAuth signature

Please help.

Thanks;

dharmaj June 8, 2018

To fix this "Invalid OAuth signature" I changed application link url to actual https production url as "https://sub.domain.com:8081/wiki" and "https://sub.domain.com:8081/jira" in respective links but then I got following error:

The remote certificate can&#39;t be trusted

To fix this I did import ssl certificate with certificate-chain and unencrypted private key as .pem file and restarted both confluence and jira but that still shows remote certificate can't be trusted.

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 8, 2018

That can't be trusted error can happen for three possible reasons:  check out SSL and application link troubleshooting guide

From that page:

Checklist of possible causesActions you can take

The remote SSL certificate has expired.

The remote certificate doesn't appear to be issued by a trusted authority (it may have been self-signed).

  • If the certificate was issued by a trusted authority, you may need to install one or more intermediate certificates.
  • If the certificate is self-signed, you can import the certificate into the Java trust store, for the JVM that the local application is using. See Check the SSL certificate location below.
The remote certificate may be in the wrong location in the file system.

If this is not an expired cert, and it's not self signed, then I'd check the location again.  I'm not sure if you're using a different certificate for Jira vs Confluence, or if perhaps they are using the same wildcard cert.  However it's possible that Jira and confluence installed on the same system could be using different trust store locations because they could have different JVM environments.

One way to avoid that is to define a $JAVA_HOME variable on the system.  By doing this, we can be more certain of which java installation/version each application is using when it starts up. Our documentation on Installing Java has details on this.  If you've done this and are still having problems connecting here, it might help try the diagnosis steps in Unable to Connect to SSL Services due to PKIX Path Building Failed.  There is a utility there called sslpoke you can then use from that server to learn some more details about why this connection might be failing.

dharmaj June 8, 2018

1) certificate is valid till 2020

2) it's issued by Godaddy (I am not sure it is trusted in context here or not)

3) location - Jira and Confluence seems to be using the same JVM as when I import cert in one JRE (/opt/atlassian/confluence/jre/bin) and then go to Jira JRE (/opt/atlassian/jira/jre/bin) it tells me that cert already exists in the keystore.

dharmaj June 14, 2018

Hi Andrew, 

Issue is fixed, sslpoke did help. Turned out that I was importing certificate incorrectly w/o using -keystore option which ended up importing cert into some default certstore instead of the one for jira and confluence. 

Thank you for your help.

Suggest an answer

Log in or Sign up to answer