This could be one of reasons why Stash integration functionality does not work, please see: https://jira.atlassian.com/browse/JRA-59406

I was having an issue getting Jira Triggers to communicate with Stash. We are using Apache mod_proxy for reverse proxy hostnames for each Atlassian app ( jira.company.com). This comment - https://jira.atlassian.com/browse/JRA-40968?focusedCommentId=712173&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-712173 - gave me an idea that perhaps not all of our hostnames had CNAME DNS records, and if Apache expected CNAMES that is why it wasn't working.

We are using http, not https (SSL). We are using Windows 2008 R2 with VMWare.

Sure enough our git VM where Stash is installed was using an A Record, but no CNAME - all of the other hostnams had CNAMES. As soon as we created the missing CNAME record, it resolved the issue. The A Record was for the name of the VM itself, so name your VM's differently than the hostname you wish to use, so that your can create CNAME records for the hostnames you want to use.

Hi simon50,

The investigation of this issue concluded that this was a configuration issue and not a bug, please refer to the comment above at https://jira.atlassian.com/browse/JRA-40968?focusedCommentId=712173&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-712173 for details.

If you need further help, could you please create a support ticket at https://support.atlassian.com? We should be able to troubleshoot and help you there.

The credentials should be the same as for this site (https://jira.atlassian.com).

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

This issue is not resolved! please fix it!

@ted, thanks for the tip. I will do that way

@Giovanni, the work around of using a second tomcat connector does work. You can not, however, have an SNI based SSL configuration present anywhere on that secondary connection. The connections must be unencrypted or using a wildcard certificate to function. To provide some transport security, however, I implemented OpenSwan IPSec on the connection between the jira and stash servers. While the data being transmitted is unencrypted as far as the applications are concerned. The connection itself is always encrypted, providing the same (if not better) security.

I hope that clarifies some things for you.

The workaround doesn't work I beliave because I try without the second port, I create the application links without ssl and work temporary, and then create the SSL configuration. As soon as the application links are updated they stop working.

The way I do can be tested if you have the ssl certs:

1. Install http://docker.io
2. Install https://github.com/michaelsauter/crane
3. See the crane.yml example configuration in: https://github.com/atende/jira. Update according
4. Update the hosts file in your machine pointing to the proxy container
5. Install everyone using docker lift -c crane.yml

The generated nginx proxy is:

server {
	server_name projetos.atende.info;
	listen 443 ssl;

	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;

	ssl_prefer_server_ciphers on;
	ssl_session_timeout 5m;
	ssl_session_cache shared:SSL:50m;

	ssl_certificate /etc/nginx/certs/projetos.atende.info.crt;
	ssl_certificate_key /etc/nginx/certs/projetos.atende.info.key;

	add_header Strict-Transport-Security "max-age=31536000";

	

	location / {
		proxy_pass http://projetos.atende.info;
		
	}
}

This ticket is not resolved.

I will try add a new port without SSL and use this with the application link, but I think that will not resolve because the links will be upgraded and the problem will return.

My case is not a misconfiguration in Apache. The URLs are served correctly I tested with curl -v.
Also I'm using different SSL certifications in every application: stash, jira and bamboo. All are valid certifications that browsers trust and the test SSLSpoke works https://confluence.atlassian.com/download/attachments/117455/SSLPoke.java

I will try the workaround by Christopher S. Hebert

Hi all,

Firstly, the specific problem in the issue description is an instance of apache being misconfigured. Please see Running several name-based web sites on a single IP address.

In detail, when a client https request is sent to https://stash.example.com it is served by the first virtual host (JIRA).

In this case, please add the following entry to your apache config:

NameVirtualHost *:443

This instruction will tell apache to route the request based on CNAMES, causing the matching virtual host to be selected.

Both these VirtualHost's use the same certificate indicating that a wild card common name has been used "*.example.com". On the other hand, the cases for SNI support are covered by JRA-24515 JIRA should support the use of TLS - SNI , please refer to that ticket for the use cases around that scenario.

Cheers,
Christopher

Same problem here with Jira and Bamboo and Jira and Stash all with ssl and subdomains

This however, does not seem possible for FishEye/Crucible, as I can't seem to setup a second connector...

Maybe the Atlassian guys can help out here. I have this in my config, but its yelling at me:
<web-server site-url="https://my.site.example.com">
<http bind=":8060" proxy-port="443" proxy-scheme="https" proxy-host="my.site.example.com"/>
<http bind=":8066"/>
</web-server>

Any ideas?

Following @arisalexadmin's comment above, I was able to get our stash/jira servers running.

We run Apache on our machines. However, I simply bypassed that completely by editing the server.xml file and added another connector on a different port without the proxy*/secure/scheme settings. As our servers run off the same machine, I selected two different ports for stash/jira.

This allowed me to connect the applications directly with eachother.

When I linked them up, I went into stash, changed the stash server URL to http://127.0.0.1:PORT, created a new application link to Jira from Stash. Once the link was created, I went to Jira's application links, and updated the display link to the https url.

Now everything seems to work.

Might be a good idea to update https://confluence.atlassian.com/display/JIRAKB/JIRA+Development+Panel+Missing+When+Viewing+Issue and https://confluence.atlassian.com/display/STASHKB/Capabilities+Warning+Applications+with+flagged+capabilities+may+be+offline+or+older+versions to reflect this workaround.

Thanks Christopher for the tips. Much appreciated.

Our configuration:
Nginx Proxy on standalone server doing redirect to:
jira.internal.example.com:8080
stash.internal.example.com:8080

CNAME entries for jira.example.com and stash.example.com -> proxy

Here was our workaround:

On both stash and jira tomcat configurations:
create second connector for port 8081 and remove all proxy, redirect, and ssl settings
restart
On both stash and jira server configurations, temporarily set Base URL to jira/stash.internal.example.com:8081

In the application links configuration on stash use http://jira.internal.example.com:8081

Once configuration is complete on both sides, reset Display URLs on both sides under Application Links configuration to https://jira/stash.example.com
Reset Base URLs in server configuration.

Bob's your uncle.

Likewise this issue is causing us lots of problems! Any progress?

Setup multiple IPs for the server and use IP addresses in Apache VirtualHost's

Our instances are on different machines/IPs, so you would think that this would work, but it isn't.

This issue is preventing us properly integration Stash & JIRA.

At the very least it should be included in the set up/installation instructions for affected products so that no new customer ends up deploying them in an unsupported configuration.

Sounds like we are having the same issue: running JIRA and Confluence proxied through Nginx with SSL.

1. JIRA and Confluence can talk to each other no problem after we applied SSL
2. Stash worked fine when we had it on our dev servers (which were not SSL)
3. After purchasing Stash and installing in our (SSL) production environment, that was the first time we encountered this bug ... JIRA cannot talk to Stash.

In fact, we bought the Stash licensing before we encountered this post, thinking that maybe the evaluation version didn't work under SSL. Our Atlassian consultants tell us that, in order to work around this bug, we would need to have our SSL certificate use a wildcard certificate – unfortunately, this is very bad practice in an enterprise environment, and our Info Security team won't allow it.

We are really hoping for a fix soon, as we just bought the Stash licenses, our development team just finished Stash training ... but now we cannot roll it out.

ted.wood:

dev panel works but requires explicitly trusting server cert. Trusting the CA does not work.

This is a strange one, and I suspect it may be due to how the public cert is being served. Is it signed by intermediates, and are those intermediates kept within the Tomcat JKS? If Java can't establish the full chain of trust to the CA (ie through the intermediates) it won't trust the URL. Most modern browsers cache those intermediate certs or fetch them from special servers so if you browse to the instance the cert may appear like it correctly resolves. If you use something like https://sslcheck.casecurity.org this will let you test the instance's setup to see if it's serving them.

Otherwise thanks for your fantastic testing. Really appreciate it!

atlassian827 thanks for letting us know, I'll follow up about this as we had seen it work in some situations.

We're running JIRA proxied through Nginx with SSL. Stash is running over the standalone tomcat SSL. Both have the SSL certificates imported into the keystores. Both behind subdomains.
JIRA runs on 443. Stash on 8443. For more details see ticket JSP-211812 which has been awaiting a response for about 24 hours.

Nothing relevant in any of the log files that I can see. My dev team was looking forward to using the triggers...

We too have encountered the same issue: whatever we change in JIRA and Stash configurations - Stash always is shown as having capability problems.
The only solution for us was:

• configuring HTTP proxying in Apache for Stash and JIRA
• restrict HTTP allowed remote address list to only permit Stash and JIRA communicate directly through localhost
• change /etc/hosts to resolve server addresses as 127.0.0.1
• create application link from Stash to JIRA - this leads to JIRA still thinking it has to connect to Stash using https
• manually (through database) update application link URL in JIRA to use http instead of https
  As you can see, this scheme is rather ugly and took me quite a while to figure it out. Please fix this issue as it makes the whole wonderful Development Panel idea unusable and total PITA.

@Ted thanks for the info. I tried the approach of running Jira and Stash behind different proxies with different IPs, This worked partly but Stash is reporting "The following JIRA instance(s) linked to Stash do not support workflow triggers" and Jira only gives an indication about such an issue in the transition triggers "Stash is not able to communicate with JIRA". All application links worked fine. But the "create branch" button inside a an issue only worked unidirectional and never showed that a branch was created after actual creation.

@David: The proposed workaround of running two virtual hosts with different IPs didn't help. See the comment above.

So i think the only solution right now is not to use SSL through reverse proxies., when you run Jira with Stash.

BTW: i'm using self signed certificates which are directly imported into the keystore of every java runtime.

@Julian – In tests I ran while trying to determine the cause of this issue for our organization I found the following: I just noticed I misread your question. I have not tried linking the applications over http but I did try connecting the applications directly (bypassing the proxy) while requiring user access over the proxy and this did not work. It would be possible to configure apache to proxy all connections except those from the stash/jira servers themselves and configure the applink to use http instead of https. If I have a chance I will test that out this week before I leave on Holiday.

To add a little more information to the discussion. Below are some tests I've run, with the assistance of Atlassian Support, to find some combination of SSL and proxy that would work:

• SSL Proxy for both:443 -> jira/stash:8080 - dev panel missing
• Non-SSL Proxy for both:80 -> jira/stash:8080 - dev panel works
• No proxy jira/stash:8080 - dev panel works
• No proxy jira/stash:8443 - dev panel works but requires explicitly trusting server cert. Trusting the CA does not work.
• SSL Proxy:443 -> jira/stash:8443 - dev panel missing even with server cert explicitly trusted
• SSL Proxy:443 for jira, Non-SSL Proxy:80 for stash -> jira/stash 8080 - dev panel works
• SSL Proxy:443 for jira, Non-SSL Proxy:80 for stash -> jira/stash:8443 - dev panel works

It does not appear that this has anything to do with the connection between the application and the proxy being over SSL or not. I did find it interesting, however, that I had to explicitly trust the server certs and could not just trust a CA as part of a PKCS12 or JKS file in server.xml.

Is there a possibility to use HTTP mode for linking internally and HTTPs for external access?