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
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
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;
So, I think problem with IIS is the same problem with SSL configuration.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
David, just confirming, what's the URL defined in your Base URL? Is it the proxied URL?
Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi David,
Jira normally runs on port 8080 and Confluence on port 8090.
Maybe that's your problem?
Best regards,
Peter
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.