Setting up SSL NGINX. Any expected issues after implementation?

[Tripline]

Anyone setup https for Jira and ran into any issues? After reading about Jira Collaborative editing not working with Apache SSL, I was wondering if there was any unforeseen errors I can expect.

I'm running Jira Software on top on Windows 2016.

https://confluence.atlassian.com/confkb/confluence-collaborative-editing-does-not-work-with-ssl-and-apache-2-4-9-or-earlier-872132268.html

[JP _AC Bielefeld Leader_]

Well,

you're writing about Jira and not Confluence, so the linked article is not relevant for you. Anyway, Confluence runs like a charm behind an Apache HTTPD 2.4.9+ (This version was released 2014...)

I can only comment from the Apache HTTPD side, but I assume as long as you know what you're doing with ngnix, there shouldn't be any issues on the Jira side.

You terminate the SSL at the nginx server & forward all requests to Jira. Ngnix is a pure reverse proxy. We use Windows 2012 R2 as platform. You should be fine.

Did you check:

https://confluence.atlassian.com/jirakb/integrating-jira-with-nginx-426115340.html

Best

JP

[Mike Rathwell]

Hi @Tripline 

Yes... it will work and take far less time than trying to figure out the ins/outs/wherefores of doing it even on a supported version of Apache. Here's the config I used for Confluence successfully:

server {
server_name .confluence.company.com;
listen 80;

location / {
return 301 https://$server_name$request_uri;
   }
}

server {
listen 443 ssl;
server_name .confluence.company.com;
ssl_certificate /etc/nginx/certs/confluence-chained.crt;
ssl_certificate_key /etc/nginx/certs/confluence.key;

ssl_session_timeout 5m;

ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

location /{
client_max_body_size 0;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:8090/;
}
location /synchrony {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:8091/synchrony;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
}

 Note that I used the vernacular ".confluence.company.com" with the leading dot. I have wildcard certs and this allows me to use the same NGINX config for both "https://confluence.company.com" and "https://test.confluence.company.com" for example.

[JP _AC Bielefeld Leader_]

I'm wondering, if this configuration supports Synchrony via ws (websocket) protocol as I don't know if this is supported by ngnix native.

You're doing a proxy_pass to http:. Did you ever try ws: ?

[Mike Rathwell]

Short answer, @JP _AC Bielefeld Leader_ , is that no, I didn't. I cobbled this together out of several "half answers" that did some but not all and some I transposed from what ostensibly worked with Apache. 

Basically, after struggling to make Apache work for a day and a half, I gave up and had the NGINX config above working in a couple of hours.

All that said, when I RTF the Ms on this, it seems that yes, ws will work as evidenced by this page. Interestingly enough, I don't recall seeing the ws stuff when I put that together and, for me, is a moot point now given that I have my instances containerized on AWS and now behind an ALB rather than NGINX (which also works just wonderfully and all sorts of native instrumentation I can get as well)