nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Application links when running behind reverse proxy

Olaf Trygve Ber

What are the appropriate URL-patterns to use for jira, confluence and stash?

We are running the services behind apache reverse proxy, and are using client certificates for extra security. The https-traffic is terminated at the proxy.

We have added separate connector in server.xml on all services to enable all services to speak to each other on the internal service network on HTTP (no proxyHost, etc. on this connector).

When setting up application links using the internal http-address, the automated procedure seamingly fails when setting up reverse link, due to the base url not being the same as the url used internally, although we have set the appropriate proxyHost=, sheme=, etc in server.xml. Temporarily setting the base url to the internal url when creating the link has not helped.

But the link is created, although dysfunctional. So we have added the IP-patterns and URL patterns manually as indicated in a different question and managed to get most of inter-application stuff working based on the info found here: https://answers.atlassian.com/questions/87355/what-are-the-appropriate-url-patterns-to-use-for-each-atlassian-tool-in-configuring-trusted-connections-between-applications-application-links Unfortuneately, this info seems not to be canonical and authorative and we are missing info in the URL patterns for stash (incoming).

So we would really want to know:

1) What are the appropriate URL-patterns to use for JIRA, Confluence and Stash.

2) Why do the automatic procedure for application links fail when we are accessing an application on a http-connector internally, and try to use the external connector (https)?

3) Are there other ways to do this which should be preferred? Do atlassian expect us to run the inter-app connection internally on HTTPS?

Accepted answers

Olaf Trygve Ber

After several rounds of checking logs, I thought I had it all working, only to find there is a bug in stash preventing branch creation from JIRA to work properly (https://jira.atlassian.com/browse/STASH-4250).

So I solved it this way:

- Connector taking traffic from proxy is as before, with proxyHost, etc in server.xml.

&lt;Connector 
	port="8080"
	maxThreads="150"
	minSpareThreads="25"
	connectionTimeout="20000"
	enableLookups="false"
	maxHttpHeaderSize="8192"
	protocol="HTTP/1.1"
	useBodyEncodingForURI="true"
	redirectPort="443"
	acceptCount="100"
	disableUploadTimeout="true"
	proxyName="jira.mydomain.tld"
	proxyPort="443" 
	scheme="https" /&gt;

- Connector for service network traffic is put on https and port 443. Jira and Confluence requires priviledges for this:

&lt;Connector 
	SSLEnabled="true"
	acceptCount="100"
	clientAuth="false"
	connectionTimeout="20000"
	disableUploadTimeout="true"
	enableLookups="false"
	keyAlias="tomcat"
	keystoreFile="/opt/atlassian/certs/keystore.jks"
	keystorePass="********"
	keystoreType="JKS"
	maxHttpHeaderSize="8192"
	maxSpareThreads="75"
	maxThreads="150"
	minSpareThreads="25"
	port="443"
	protocol="org.apache.coyote.http11.Http11Protocol"
	scheme="https"
	secure="true"
	sslProtocol="TLS"
	useBodyEncodingForURI="true"/&gt;

$ setcap cap_net_bind_service+ep  /opt/atlassian/confluence/jre/bin/java
$ echo "/opt/atlassian/confluence/jre/lib/amd64/jli" &gt; /etc/ld.so.conf.d/java-libjli.conf

- DNS is bypassed on the server hosts for the application FQDNs, such that internal traffic between the applications do not go via proxy. I added this to the /etc/hosts file:

192.168.2.20 confluence.mydomain.tld
192.168.2.30 jira.mydomain.tld
192.168.2.40 stash.mydomain.tld

Now application link creation is smooth, and I do not need to edit any trust-parameters.

All comments

Philipp Kraut1

Hey Olaf,

i have a similar setup. Let me give you my config as an example, maybe it helps you. I use JIRA and Stash behind haproxy to have nice URLs without ports and also for SSL offload. When adding the application link to JIRA i used the address "127.0.0.1:9191" and Stash was able to find JIRA on the local interface.

Stash connectors:

&lt;Connector port="7990" protocol="HTTP/1.1"
    address="127.0.0.1"
    connectionTimeout="20000"
    useBodyEncodingForURI="true"
    redirectPort="443"
    compression="off"
    compressableMimeType="text/html,text/xml,text/plain,text/css,application/json,application/javascript,application/x-javascript"
    secure="true"
    scheme="https"
    proxyName="stash.mydomain.com"
    proxyPort="443" /&gt;

&lt;Connector port="8990" protocol="HTTP/1.1"
    address="127.0.0.1"
    connectionTimeout="20000"
    useBodyEncodingForURI="true"
    redirectPort="8990"
    compression="off"
    compressableMimeType="text/html,text/xml,text/plain,text/css,application/json,application/javascript,application/x-javascript" /&gt;

Jira connectors:

&lt;Connector acceptCount="100"
    connectionTimeout="20000"
    disableUploadTimeout="true"
    enableLookups="false"
    maxHttpHeaderSize="8192"
    maxThreads="150"
    minSpareThreads="25"
    port="8181"
    address="127.0.0.1"
    protocol="HTTP/1.1"
    redirectPort="443"
    useBodyEncodingForURI="true"
    scheme="https"
    proxyName="jira.mydomain.com"
    proxyPort="443"/&gt;

&lt;Connector port="9191"
    address="127.0.0.1"
    maxThreads="150"
    minSpareThreads="25"
    connectionTimeout="20000"
    enableLookups="false"
    maxHttpHeaderSize="8192"
    protocol="HTTP/1.1"
    useBodyEncodingForURI="true"
    acceptCount="100"
    disableUploadTimeout="true"/&gt;

HAProxy config:

global
	log	127.0.0.1	local0
	log	127.0.0.1	local1 notice
	maxconn	8192
	chroot	/usr/share/haproxy
	user	haproxy
	group	haproxy
	daemon

defaults
	log		global
	mode	http
	option	forwardfor
	option	httplog
	option	dontlognull
	option	redispatch
	option	tcp-smart-accept
	option	tcp-smart-connect
	option	httpchk
	retries	3
	maxconn	6000
	balance roundrobin

	timeout	connect 5s
	timeout	client  30s
	timeout	server  120s

	compression algo gzip
	compression type text/html text/plain text/css

backend jira
        server	jira 127.0.0.1:8181 check inter 2000 maxconn 50

backend stash
        server	stash 127.0.0.1:7990 check inter 2000 maxconn 50

frontend http-in
	bind :::80
	bind :::443 ssl crt /etc/haproxy/haproxy.pem

        option  http-server-close

	redirect scheme https if { hdr_beg(Host) -i jira stash } !{ ssl_fc }

        acl req_jira	hdr(host) -i jira.mydomain.com
        acl req_stash	hdr(host) -i stash.mydomain.com

        use_backend jira if req_jira
        use_backend stash if req_stash

Olaf Trygve Ber

Thanks, Phillip. I tried you setup. Still the reverse "application URL" ends up being wrong when I set up the link. They are automatically set to the base URL with https. And the result is that the reverse link is not created properly.

Olaf Trygve Ber

So I solved it this way:

- Connector taking traffic from proxy is as before, with proxyHost, etc in server.xml.

&lt;Connector 
	port="8080"
	maxThreads="150"
	minSpareThreads="25"
	connectionTimeout="20000"
	enableLookups="false"
	maxHttpHeaderSize="8192"
	protocol="HTTP/1.1"
	useBodyEncodingForURI="true"
	redirectPort="443"
	acceptCount="100"
	disableUploadTimeout="true"
	proxyName="jira.mydomain.tld"
	proxyPort="443" 
	scheme="https" /&gt;

- Connector for service network traffic is put on https and port 443. Jira and Confluence requires priviledges for this:

&lt;Connector 
	SSLEnabled="true"
	acceptCount="100"
	clientAuth="false"
	connectionTimeout="20000"
	disableUploadTimeout="true"
	enableLookups="false"
	keyAlias="tomcat"
	keystoreFile="/opt/atlassian/certs/keystore.jks"
	keystorePass="********"
	keystoreType="JKS"
	maxHttpHeaderSize="8192"
	maxSpareThreads="75"
	maxThreads="150"
	minSpareThreads="25"
	port="443"
	protocol="org.apache.coyote.http11.Http11Protocol"
	scheme="https"
	secure="true"
	sslProtocol="TLS"
	useBodyEncodingForURI="true"/&gt;

$ setcap cap_net_bind_service+ep  /opt/atlassian/confluence/jre/bin/java
$ echo "/opt/atlassian/confluence/jre/lib/amd64/jli" &gt; /etc/ld.so.conf.d/java-libjli.conf

- DNS is bypassed on the server hosts for the application FQDNs, such that internal traffic between the applications do not go via proxy. I added this to the /etc/hosts file:

192.168.2.20 confluence.mydomain.tld
192.168.2.30 jira.mydomain.tld
192.168.2.40 stash.mydomain.tld

Now application link creation is smooth, and I do not need to edit any trust-parameters.

Adam Makowiecki1

Hi Olaf, I am currently looking into a similar configuration as you have described. My question to you is how do your internal users access Jira/Confluence? Do they have to through the firewall to the Apache Web Server only to be redirected back to Jira/Confluence Tomcat servers or did you setup a configuration where internal users access via Jira/Confluence Tomcat directly?

Olaf Trygve Ber

Hi, Adam. All users go through the same front end (Apache in our case). No redirection. You could of cource have multiple front ends if you alter the DNS lookup for clients from internal network. E.g. internally use a separate front end or just use the tomcat HTTPS-connector directly -- yourserver.tld -> internal IP, no client cert requirement on Apache front end or tomcat connector. And additionally an Apache with client cert requirement for external users -- yourserver.tld -> external IP with Apache front end. In our case, we have an auto enrollment certificate policy, so it is very simple for internal users to aquire a certificate. Also, our servers are on a network separated from both external and internal clients. We therefore so far have kept things simple and use only one front end for both external and internal clients with the same client certificate requirements.

Adam Makowiecki1

Thanks for that Olaf. I believe we will go with Apache front end with SSL termination on Apache. I was thinking of using internal DNS entry for internal network users to access Jira and Confluence Tomcat servers directly with just HTTP, however; doesnt that mean external users and internal users will have different URL in their browsers and Jira and Confluence servers only allow 1 base URL (e.g. if base URL is external URL internal users will get base URL mismatch warnings )? Or if internal DNS entry will match external user URL there is the HTTP internal vs HTTPS external mismatch?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-administration

bitbucket-administration

confluence-administration