We have a setup where both Jira and Confluence are installed on the same machine (ports 8080 and 8090 respectively). There is a proxy in front of the server that does SSL termination for both applications. The application context for Jira is /jira and for Confluence is /confluence.
I can not link applications. In App link screen I put the URL to the other app and when I click NEXT, nothing happens on the screen.
Browser console says the following communication fails:
The Jira remote API is enabled.
Atlassian says "The configuration of your proxy is outside of the scope of support" (thank you Atlassian). So if anyone can help me solve this problem I would really appreciate it.
Sounds like Farzad is referring to adding the public certificates of the applications to the JIRA and Confluence Java trust stores, cacerts. We have info on how to do this in https://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services.
Hello, I have a question about the SSL for JIRA and SSL for Confluence applications. I am using a reverse proxy to direct traffic to our internal JIRA and Confluence servers. Additionally, we are using EasySSO by TechTime to process SSO. Since I can't exactly test these tools in our development environment (as they are not proxied), would someone at Atlassian be able to indicate if either of these tools would modify or affect the EasySSO configurations? I am looking at these two tools to solve an issue with Application Links between JIRA and Confluence. Right now I am unable to connect the two. Thanks for the answer!
I was able to successfully configure the application link by installing and configuring apache with mod_proxy on our server along with setting my host file on my client workstation to point directly to the server.
Once the application links were set I was able to remove the host entry and everything operated as expected.
It sounds a bit strange that you'd need to workaround it in that manner and suggests there may have been some issues with the configuration. If you're using HTTPS offloaded at Apache, you'll need to ensure that the Tomcat connectors have been configured as proxy connectors rather than standard connectors. Also, if you're offloading HTTPS and using a self-signed certificate or self-signed CA, each application will need to have either the cert or CA loaded into the trust store. In case you missed these:
The important things to remember are setting the proxyName, proxyPort and scheme parameters on the HTTP connector and also disabling http compression in Confluence and GZip compression in JIRA.
If you need to import the certificates from each other's server, you could use the following plugins:
I'm happy to take a look through your configuration if you'd like - if so please provide details of:
I am a bit lost on the subject too, but managed to get it to work to 90%.
We run JIRA and confluence on the same machine, both using http only in tomcat. We deployed a apache mod proxy in front of it that does the SSL termination for both applications, using virtualhost that forwards the respective fqdn to it's respective ports (i.e jira.example.tld points to port 8080, confluence.example.tld points to 8090.
When setting up application trust i was forced to bypass the proxy, so instead of using https://jira.example.tld we use http://jira.example.tld:8080. For Activity streams, linking to JIRA tickets on confluence this config works fine, but some things (like linking a JIRA to a confluence document) it claims that the application-url is wrong.
Question: Should i use FQDN or short names in the mod proxy, application-links, baseurl, and so forth?
We're looking for participants for a workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sha...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs