I had very a similar issue (jira & stash behind the nginx reverse proxy - all of them on the same host). I installed separate https://letsencrypt.org certs for both jira & stash and everything works fine now.

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