Setting Application Links for Confluence/Jira behind a nginx proxy

[Willem]

Greetings from Germany all,

I am struggling to find the application Links to work despite trying various suggestions.

The problem in short: Confluence and Jira needs to be linked to each other with a "Application Link", but both complain that the other is "offline", yet each application works 100%.

My current Configuration:

Internal Atlassian Server:

• Windows Server 2012
• Jira :8080
• Confluence :8090 

Internal Proxy Server:

• CentOS 7

• nginx

The DNS server points to the Proxy, that does a https force with valid SSL Certificate, and then a reverse stream to the Atlassian Server on the relevant port, working as expected. I also ensured that both Confluence and Jira are aware of the Proxy by defining it the respective server.xml files. Both applications are using there respective SSL URI as default Site URL.

The clients seem to be happy with this config, but the server itself apparently not. I am thinking that maybe it is a proxy Problem. Here is my complete nginx config (without the private info's ;) )

upstream wiki {
#Confluence
        server xxx.xx.xx.238:8090;
}

upstream issue {
#Jira
        server xxx.xx.xx.238:8080;
}

server {
        listen          xxx.xx.xx.252:80;
        server_name     wiki.xxx.com;
        access_log      /var/log/nginx/proxy.wiki.xxx.com.access.log.gz combined;
        error_log       /var/log/nginx/proxy.wiki.xxx.com.error.log;
        return          301 https://$server_name$request_uri;
}

server {
        listen          xxx.xx.xx.252:80;
        server_name     issue.xxx;
        access_log      /var/log/nginx/proxy.issue.xxx.com.access.log.gz combined;
        error_log       /var/log/nginx/proxy.issue.xxx.com.error.log;
        return          301 https://$server_name$request_uri;
}

server {
        listen                  xxx.xx.xx.252:443 ssl;
        server_name             wiki.xxx.com;
        ssl                     on;
        ssl_certificate         /etc/ssl/certs/wildcard.xxx.com/wildcard.xxx.com.crt;
        ssl_certificate_key     /etc/ssl/certs/wildcard.xxx.com/wildcard.xxx.com.key;
        ssl_protocols           TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers       on;
        ssl_ciphers             "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
        ssl_dhparam             /etc/ssl/certs/dhparam.pem;
        ssl_session_cache       shared:SSL:10m;
        add_header              Strict-Transport-Security "max-age=15768000; includeSubDomains";
        access_log      /var/log/nginx/proxy.wiki.xxx.com.ssl.access.log combined;
        error_log       /var/log/nginx/proxy.wiki.xxx.com.ssl.error.log;
        location / {
                proxy_pass              http://wiki;
                proxy_next_upstream     error timeout invalid_header http_500 http_502 http_503 http_504;
                proxy_redirect          off;
                proxy_buffering         off;
                proxy_set_header        Host            wiki.xxx.com;
                proxy_set_header        X-Real-IP       $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}
server {
        listen          xxx.xx.xx.252:443 ssl;
        server_name     issue.xxx.com;
        ssl                     on;
        ssl_certificate         /etc/ssl/certs/wildcard.xxx.com/wildcard.xxx.com.crt;
        ssl_certificate_key     /etc/ssl/certs/wildcard.xxx.com/wildcard.xxx.com.key;
        ssl_protocols           TLSv1;
        ssl_prefer_server_ciphers       on;
        ssl_ciphers             "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
        ssl_dhparam             /etc/ssl/certs/dhparam.pem;
        ssl_session_cache       shared:SSL:10m;
        add_header              Strict-Transport-Security "max-age=15768000; includeSubDomains";
        access_log      /var/log/nginx/proxy.issue.xxx.com.ssl.access.log combined;
        error_log       /var/log/nginx/proxy.issue.xxx.com.ssl.error.log;
        location / {
                proxy_pass              http://issue;
                proxy_next_upstream     error timeout invalid_header http_500 http_502 http_503 http_504;
                proxy_redirect          off;
                proxy_buffering         off;
                proxy_set_header        Host            issue.xxx.com;
                proxy_set_header        X-Real-IP       $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Is there anybody out there that could help me get these Application Links to work?

[Adrien Ragot 2]

• Which URL do you use in your application links?
• I see "listen                  172.29.40.252:443 ssl;". Why do you specify the IP? You can just specify the port. Maybe it works well from a browser, but the danger may be that in certain situations it doesn't match the IP (say you access from Java from localhost, for example, maybe it resolves to IP 127.0.0.1? or a local network IP because of a locally defined DNS?).

[Willem]

Oops, forgot the IP in there.. (removed) For clarification, these are 2 different servers. Internal Atlassian Server - xxx.xx.xx.238 (Windows with Confluence and Jira) Internal Nginx Server - xxx.xx.xx.252 (Linux with nginx) The DNS for issue.xxx.com(jira) and wiki.xxx.com(confluence) is set to point to the proxy. The proxy is then used to get the info from the Windows server with the different ports.... a Reverse proxy setup. Both Confluence and JIRA is also setup with the DNS URL(nginx), thus forcing the application to also use the proxy, seeing as only the proxy has the SSL Certificate. There should be no localhost traffic, unless JIRA or Confluence has it hard coded somewhere. Both servers are in a single Enterprise Domain, with a DNS / DHCP etc. servers.

[Adrien Ragot 2]

What URL do you use in your application links?

[Willem]

The ones specified in the nginx config, https:// issue.xxx.com and https:// wiki.xxx.com

[Adrien Ragot 2]

If those are the URLs in the Applinks config, if you can "curl -v https://issue.xxx.com"; and "curl -v https://wiki.xxx.com"; *from the Windows machine* return the webpages, if there is no context path, and if your CA certificate is recognized by the JVM which runs JIRA/Confluence (because it's not a given that 'curl' uses the same CA as the JVM), then there should be no issue. If not resolved, maybe Atlassian's support can help you (https://support.atlassian.com).