Create Application Link JIRA to Confluence using SSL and IIS and ARR

[David Zahorsky]

Hi fellow Atlassians

I have one server with JIRA (6.1.1) and Confluence (5.3.1) on it. Both are running correctly with HTTPS. I'm using IIS and ARR. The set up has been done with this guide: https://confluence.atlassian.com/display/JIRAKB/Integrating+JIRA+with+IIS+using+ARR?focusedCommentId=420971762#comment-420971762

The only thing which im hanging is, to get an application link between those 2.

When i want to create the Incoming Trusted Connection i get the following error:

Unable to retrieve the application's certificate: java.net.SocketException: Connection reset

I added both Certificates to the JRE cacert.

If i check with SSLPoke i get the following message:

java SSLPoke myhost 443

Successfully connected

Now im at an end... :-(

- Question: Is JIRA using different Ports either then 80 443? (My Firewall just lets those 2 through, since internally the port 8080 and 8090 are not going through the firewall)

Any help on that? Thanks

David

[David Zahorsky · Accepted solution]

Hi Tiago

We are getting to it :-)

So to achieve your approach i had to make another connector in the server.conf on both JIRA and Confluence.

To makes things easier i show you the JIRA changes:

One for http and the other for https

<Connector port="8080"

                   maxThreads="150"
                   minSpareThreads="25"
                   connectionTimeout="20000"

                   enableLookups="false"
                   maxHttpHeaderSize="8192"
                   protocol="HTTP/1.1"
                   useBodyEncodingForURI="true"
                   redirectPort="8081"
                   acceptCount="100"
                   disableUploadTimeout="true"
				   
				   
				   />
				    <Connector port="8081"

                   maxThreads="150"
                   minSpareThreads="25"
                   connectionTimeout="20000"

                   enableLookups="false"
                   maxHttpHeaderSize="8192"
                   protocol="HTTP/1.1"
                   useBodyEncodingForURI="true"
                   acceptCount="100"
                   disableUploadTimeout="true"
				   proxyName="jira.company.com"
				   scheme="https"
				   proxyPort="443"
				   
				   />

I changed the URL Rewrite Rule going to http://localhost:8081/{R:1}

Then i made the application link to http://localhost:8080

The application link worked! But, the URLs in the JIRA Macro Gadgets are generating the wrong urls:

for example: http://localhost:8080/browse/ABC-2059

I tried to make an outbound rewrite rule, but that didn't work.

Thanks for your assistance, i really appreciate it.

Regards

Dave

[Andrey Ambartsumov]

In my case I have problem with paranoid SSL configuration in nginx:

ssl_protocols TLSv1.2;

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/nginx/ssl/dh4096.pem;

SSLPoke utility return 'connection reset, nginx didn't log any message because loglevel 'warn' does not log ssl handshake problems (use 'info'!).

You may read how to use SSLPoke here http://brakertech.com/testing-ssl-chaining-issues/(googling how use SSLPoke do not follow to atlassian sites).

The solution is:

ssl_protocols TLSv1.2 SSLv3;

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/nginx/ssl/dh1024.pem;

E.g:

ssl_protocols - added SSLv3

ssl_dhparam - used 1024 bit Diffie-Hellman param., because java can't handle 4k lenth key.

So, I think problem with IIS is the same problem with SSL configuration.

[Robert Rauchstaedt]

Andrey, did you managed to get this running with TLSv1.2 only ?! We have the same problem with Jira/Stash Applinks. We also get refused connection when only TLSv1.2 and TLSv1.1 are enabled. If we enable TLSv1 or SSLv3 it work, but both are insecure... -- Robert

[Jinesh Choksi]

We came across this issue when adding an application link for Stash in Bamboo. Our setup is: - Bamboo v5.9.0 (on its own server) - Stash v3.9.2 (on its own server) - Apache httpd 2.4.6 + mod_proxy + mod_ssl (on both servers acting as a reverse proxy) - Our SSL config was based on: https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.6&openssl=1.0.1e&hsts=yes&profile=modern - JDK 1.8u45 (SSLv3 is disabled by default in this JDK) We saw that the issue was that Bamboo was trying to download a manifest over https and failing because SSLv3 had been disabled. The workaround for us which _does not_ involve re-enabling insecure protocols was: Adding: -Dhttps.protocols="TLSv1.1,TLSv1.2" -Djdk.tls.client.protocols="TLSv1.1,TLSv1.2" to the JVM arguments in the setenv.sh script for Bamboo. This will inform the JVM that the only available protocols are TLS v1.1 and 1.2. We chose not to use TLS v1.0. Source for this information: http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html (see the use case for JDK 8) -- Jinesh

[David Zahorsky]

Actually it looks like the bug i have at the moment. Thanks for sharing it with me. Let's hope Atlassian finds a fast way to mend this bug.

[Tiago Comasseto]

Hi Dave, maybe the issue you're facing with JIRA macros can be a bug, I was checking some references and found this bug report: https://jira.atlassian.com/browse/CONF-29182

Please see the linked issues, is this the same behavior you're seeing in your instance?

Cheers

[David Zahorsky]

Hi Tiago

It's definitely https://jira.company.com.

I believe the link is being made by the Application Link URL. So i have an idea about doing an outbound url rewrite. Do you have experience with that? I tried to create a rule, but with no effect :-(

Regards

Dave

[Tiago Comasseto]

David, just confirming, what's the URL defined in your Base URL? Is it the proxied URL?

Cheers

[David Zahorsky]

Hi Tiago

Nice to hear that i can also help you :)

Yeah i changed the display Url:

http://postimg.org/image/wx0oktx41/

But no effect :-(

And it is not cached, i added a new Jira macro, and it still has the localhost:8080 url.

Any other ideas?

Can it be done with ARR outbound rewriting?

Regards

Dave

[Tiago Comasseto]

Hi Dave,

That was very clever and actually it gave me an idea to solve another issue :)

As for this part:

The application link worked! But, the URLs in the JIRA Macro Gadgets are generating the wrong urls:

for example: http://localhost:8080/browse/ABC-2059

Did you have the chance to change the Display URL as in the screenshot in this link?

Cheers

[Tiago Comasseto]

Hi David,

The "Connection reset" message seems to me that IIS for some reason is blocking the communication over 443.

I also noticed that you mentioned that the applications are running on the same server. In this situation, there wouldn't have the need to connect your applications through the proxied URL. You can recreate the application link using the direct address (as http://localhost:8080) and just edit the Display URL in your application link configuration to point to the proxied URL.

This way all cross-application communication would be done directly and all URLs that are displayed to the final user would be build using the proxied URL.

Lets us know if it works for you.

Cheers

[David Zahorsky]

In the logs i get following errors when i want to create App Links.

2013-10-31 15:59:25,666 ERROR [http-8090-19] [core.rest.ui.CreateApplicationLinkUIResource] tryToFetchManifest ManifestNotFoundException thrown while retrieving manifest
 -- url: /rest/applinks/2.0/applicationlinkForm/manifest.json | userName: tom.tester
com.atlassian.applinks.spi.manifest.ManifestNotFoundException: java.net.SocketException: Connection reset
	at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.download1(AppLinksManifestDownloader.java:201)
	at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.access$000(AppLinksManifestDownloader.java:44)
	at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader$1$1.<init>(AppLinksManifestDownloader.java:86)
	at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader$1.apply(AppLinksManifestDownloader.java:79)
	at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader$1.apply(AppLinksManifestDownloader.java:76)

[Tiago Comasseto]

Hi David,

Isee that during the SSLPoke test, you haven't specified the path to the cacerts file that is being used by JIRA. You can see it in JIRA logs, the path is something like the following:

java.home                                     : /usr/lib/jvm/java-1.7.0-oracle-1.7.0.25.x86_64/jre

I'd be more secure that the certificate was imported into the file cacerts file that is being used by JIRA testing with this syntax

java -Djavax.net.ssl.trustStore=/usr/lib/jvm/java-1.7.0-oracle-1.7.0.25.x86_64/jre/lib/security/cacerts SSLPoke your_host 443

The same also apply to Confluence.

Cheers

[David Zahorsky]

Hi Tiago

Thanks for your assistance.

Jira:

java.home : C:\Java\jre7

C:\>java -Djavax.net.ssl.trustStore=C:\java\jre7\lib\security\cacerts SSLPoke jira.company.com 443

Successfully connected

Confluence:

The problem here is, the log does not state which jre it is using. So i just can suppose that it is using the same jre.

I checked the service properties, to see if it is targeting the same jvm:

Java Virtual Machine:

C:\Java\jre7\bin\server\jvm.dll

[Peter Van de Voorde]

Hi David,

Jira normally runs on port 8080 and Confluence on port 8090.

Maybe that's your problem?

Best regards,

Peter

[David Zahorsky]

Yes that is true, but with ARR all Requests which are going to jira.company.com are being rewritten to http://localhost:8080.

Same for Confluence which are being rewritten to http://localhost:8090