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;
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
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):
Please help.
Thanks;
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
- Check the certificate details online (for example using https://www.digicert.com).
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.
- See Check the SSL certificate location below.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.