Proxying JIRA with Apache Edited

OS: Centos 7

Objective:

Current jira instance: <Server IP addr>:8099

Need to go to hostname: jira.companyname.com

Things I did: According to link: https://confluence.atlassian.com/kb/proxying-atlassian-server-applications-with-apache-http-server-mod_proxy_http-806032611.html

A. For atlassian application:

1. Stopped JIRA

2. Not using context path so ignored

3. For connector directive, In server.xml, added

proxyName="jira.companyname.com"
proxyPort="8099"
scheme="http"/>

B. For Apache HTTP server

1. mod_proxy enabled by default in Centos.

2. Configure virtual host using mod_proxy, 

Since includeOptional statement present in httpd.conf, In conf.d folder created an jira-vm.conf file with following. 

<VirtualHost *:80>
    ServerName jira.companyname.com
     
    ProxyRequests Off
    ProxyVia Off
ProxyPreserveHost On <Proxy *> Require all granted </Proxy> ProxyPass / http://<ip addr>:8099 ProxyPassReverse / http://<ip addr>:8099 </VirtualHost>

 3. Restart apache

systemctl restart httpd.service

4.  Modify CentOS SELinux policy

$ sudo /usr/sbin/setsebool -P httpd_can_network_connect 1

 C. Restart JIRA.

Result:

I dont see any response on jira.company.com

On ipaddr:8099 I see my jira instance with error:

"

Dashboard Diagnostics: Mismatched URL Hostname

JIRA is reporting that it is running on the hostname 'jira.clarionus.com', which does not match the hostname used to run these diagnostics, '<ip addr>'. This is known to cause JIRA to construct URLs using the incorrect hostname, which will result in errors in the dashboard, among other issues."

 

Server.xml snippet:


<Connector port="8099"

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

enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"
bindOnInit="false"
proxyName="jira.company.com"
proxyPort="80"
scheme="http"/>

 

Things I have tried: 

1. Restarted Jira after changing XML proxyPort to 8099 instead of 80. Result: same error. Reverted back to 80.

2. Checked if conf file is case sensitive with On and Off. Result: same error.

3. Atlassian won't help as our support expired last month. :(

What other areas should I look into? 

Thank you for your time

 

Edit: For Solution, See my post towards the end summarizing the issues I faced.

6 answers

1 accepted

Priyank, do you have the Apache as a proxy server imposed on you? I just went through this exercise with both Jira and Confluence (way fussier) and, after struggling for a couple of days with httpd, I threw in the towel and gave NGINX a shot.

2 hours after going down the NGINX rabbit hole, it worked. Perfectly. The configurations were a metric tonne easier to get "right". The only "gotcha" was that NGINX doesn't use cert chains quite directly. One needs to manually add in the chain to the cert file. ALSO, the way openssl creates them seems to have the cert chain in the wrong order - I had to make sure I had host -> intermediate -> root in order in the file.

Aside from that gotcha, I shall NEVER struggle with httpd again. The other bonus is that the "cookbook" examples on the Atlassian pages just... work.

Mike,

Ah, I see. Ok I will spend some time today and try to explore NGINX option. I shall post my updates soon.

Thank you for your time.

Mike, Moses,

@Moses Thomas @Mike Rathwell

I configured NGNIX and I have discovered that there is a deeper problem to this than I first thought. 

When I do an nslookup, the domain jira.companyname.com is linked to domain address 216.XX.XXX.XXX. (Accessible through outside network-Internet anywhere)

And the server IP addr that I was trying my configurations for is 10.XX.XXX.XXX (Accessible through  inside company network only)

Since I was trying to link server IP addr to jira.companyname.com, it was giving me the error? This is my understanding. Correct me if I am wrong. Its still giving me the error with server IP addr and the jira.companyname.com domain.

 

Basically the task is "to proxy internal traffic that accesses 10.91.121.163 to Jira.companyname.com" as well as "to proxy external traffic from 216.XX.XXX.XXX to jira.companyname.com"

Not sure if I am clear enough here.

1. Will reverse proxy help me here? Or what else should I consider?

 2. What Ip addr should be used in conf file? 216.XX or 10.XX because it does not work for 10.XX so far.

3. I could not find any related documentation. I am using the wrong keyword to search maybe. Can you point me in the right direction?

Your assistance helps me thoroughly. 

Thank you.

I'd have stayed with Apache HTTP :p - at least I am fond of it and find it pretty easy.

Hi Priyank,

Your environment is largely the same as what I have here. What I've done is ALL traffic (whether in the office or not) goes to the public IP address. This gave me a measure of security as well since I can BLOCK the Jira host IP address from direct access. The ONLY way through to the server is via the NGINX host. If I need to get directly to the server (which in your case would be the 10.x.x.x address, I actually have to be on a VPN.

I have the internal IP address simply serving via tomcat on 8080 with NGINX heading in that direction. That saves me the trouble of having to configure SSL on the internal address on Tomcat as well. One place to manage certs.

Mike,

Your idea makes sense. And in this case I still need to get the jira.companyname.com active.

But I am failing to understand how I can get the jira.companyname.com to work. I am pulling my hair but still cant seem to figure out what is the problem.

jira.companyname.com (216.x.x.x.x) still does not match the expected hostname 10.x.x.x

After adding proper lines in the .nginx.conf file as well as the server.xml file. 

I am not using a context path. But I will try to follow the instructions to add context path and see if that gets me anywhere. 

Thank you

@PriyankPls show your nginx  file

 include /etc/nginx/conf.d/*.conf;

server {
listen 80;
server_name jira.companyname.com;
location / {
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://10.x.x.x:8099;
client_max_body_size 10M;
}
}

I made these changes based on this post. In the configure NGNIX section.

Also the server.xml snippet is attached.

<!-- Nginx Proxy Connector -->
<Connector port="8099"
maxThreads="150"
minSpareThreads="25"
connectionTimeout="20000"
enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"
proxyName="jira.companyname.com"
proxyPort="80"
scheme="http"/>

<!-- Standard HTTP Connector -->
<Connector port="8082"
maxThreads="150"
minSpareThreads="25"
connectionTimeout="20000"
enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"/>

 As per instructions in the same link. 

Where should the instance for 216.x.x.x external access ipaddr be placed if anywhere? 

 

SO... this assumes that:

  1. NGINX is on (or appears local) to your JIRA server
  2. The DNS to your jira instance is ONLY the public IP address

Note: mine is abstracted by having all this in containers which make it look local. If you're NOT local and have a separate NGINX server that has both internal and external NICs, your DNS for JIRA would point at the NGINX server. The "proxy_pass" directive would point at wherever tomcat is serving JIRA

 

The chunk in server.xml

        <Connector

        port="8080"

        maxThreads="150"

        minSpareThreads="25"

        connectionTimeout="20000"

        enableLookups="false"

        maxHttpHeaderSize="8192"

        protocol="HTTP/1.1"

        useBodyEncodingForURI="true"

        redirectPort="8443"

        acceptCount="100"

        disableUploadTimeout="true"

        bindOnInit="false"

        proxyName="jira.company.com"

        proxyPort="443"

        scheme="https"

/>

The nginx jira config file

server {

    server_name .jira.company.com;

    listen 80;

 

    location / {

        return 301 https://$server_name$request_uri;

    }

}

 

server {

    listen 443 ssl;

    server_name .jira.company.com;

    ssl_certificate /etc/nginx/certs/jira2018-chained.crt;

    ssl_certificate_key /etc/nginx/certs/jira2018.key;

 

    client_max_body_size 0;

 

    location / {

        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:8080;

    }

}

Note also the server_name directive with the leading ".". That allows a match between jira.company.com OR *.jira.company.com (for test instances using the same NGINX conf

I have the following "default" config that i definitively renamed to "0.conf" to ensure it loads FIRST

# Instructions for defaults found on https://irulan.net/nginx-http-and-https-default-server/

server {

 

    listen 80 default_server;

    listen [::]:80 default_server ipv6only=on;

    server_name _;

 

    server_name_in_redirect off;

    log_not_found off;

 

    return 410;

 

}

 

server {

 

    listen 443 ssl default_server;

    listen [::]:443 ssl default_server ipv6only=on;

    server_name _;

 

    ssl_certificate /etc/nginx/certs/snakeoil-certificate.pem;

    ssl_certificate_key /etc/nginx/certs/snakeoil-key.pem;

 

    ## To ensure old/ancient versions of Nginx to be secure and not fall victim

    ## to SSLv3 vulnerabilities, uncomment the following lines:

    #

    # ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    # ssl_ciphers HIGH:!aNULL:!MD5;

 

    server_name_in_redirect off;

    log_not_found off;

 

    return 410;

 

}

Another "gotcha" I'd had was the config order loading. It loads by natural sort order so before I changed the config name of default, it was loading in the wrong order (mostly borked confluence but I like to be definitive what loads when)

This also includes a "fake" cert in the middle for default listens. With this, things like nmap will see 80 and 443 open but will NOT, by default, see any applications listening

So... here is what I have that seems to work. In my case, NGINX logically appears local to the Jira server. The DNS points at wherever NGINX is. If NGINX is not local to JIRA, merely change the "proxy_pass" directive to point at wherever Tomcat is serving JIRA.

 

My server.xml (I do NOT have the fallback port)

 

        <Connector

        port="8080"

        maxThreads="150"

        minSpareThreads="25"

        connectionTimeout="20000"

        enableLookups="false"

        maxHttpHeaderSize="8192"

        protocol="HTTP/1.1"

        useBodyEncodingForURI="true"

        redirectPort="8443"

        acceptCount="100"

        disableUploadTimeout="true"

        bindOnInit="false"

        proxyName="jira.company.com"

        proxyPort="443"

        scheme="https"

    />

 

NGINX Default config (file definitively named 0.conf to force loading FIRST; the config files are loaded in natural system sort order). This default also nicely obscures stuff; nmap will return ports 80 and 443 open but NOT any applications on them.

 

# Instructions for defaults found on https://irulan.net/nginx-http-and-https-default-server/

server {

 

    listen 80 default_server;

    listen [::]:80 default_server ipv6only=on;

    server_name _;

 

    server_name_in_redirect off;

    log_not_found off;

 

    return 410;

 

}

 

server {

 

    listen 443 ssl default_server;

    listen [::]:443 ssl default_server ipv6only=on;

    server_name _;

 

    ssl_certificate /etc/nginx/certs/snakeoil-certificate.pem;

    ssl_certificate_key /etc/nginx/certs/snakeoil-key.pem;

 

    ## To ensure old/ancient versions of Nginx to be secure and not fall victim

    ## to SSLv3 vulnerabilities, uncomment the following lines:

    #

    # ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    # ssl_ciphers HIGH:!aNULL:!MD5;

 

    server_name_in_redirect off;

    log_not_found off;

 

    return 410;

 

}

 

NGINX Jira config (named jira.conf). The "." in front of the server_name argument is the special wildcard that matches the explict host name as well as *.hostname so you can use the same config for test and other environment instances.

 

server {

    server_name .jira.company.com;

    listen 80;

 

    location / {

        return 301 https://$server_name$request_uri;

    }

}

 

server {

    listen 443 ssl;

    server_name .jira.company.com;

    ssl_certificate /etc/nginx/certs/jira2018-chained.crt;

    ssl_certificate_key /etc/nginx/certs/jira2018.key;

 

    client_max_body_size 0;

 

    location / {

        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:8080;

    }

}

 

If you need it, here is my Confluence config named confluence.conf

 

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/confluence2018-chained.crt;

    ssl_certificate_key /etc/nginx/certs/confluence2018.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";

    }

}

@Priyank@Mike RathwellWhere are we i am lost  now too many code :D

@Moses Thomas, without proxy servers we'd have SO much less to talk about :P

Anyway, I posted my (sanitized) server.xml block and the 3 NGINX conf files that make JIRA and Confluence work behind my proxy server and the assumptions for the config (copied these straight out of my dev box)

@Mike RathwellI wanted to  also  post mine but there will  be no need i can see they look more the same in structure, i hope @Priyank will  fix his issue with this  code provided.

 

Best!

@Moses Thomas, that was my hope that this fixes it. HOWEVER, in looking at @Priyank files, I note the include *.conf just before his configuration. 

@Priyank, I got bit by almost this same thing initially and alluded to it above; the order the conf files are loaded. I had tried, as you did, to toss that config in the default.conf and just use that. It broke. SO I started with the box stock install and did the following:

  1. Created the separate jira.conf and put it in the conf.d directory
  2. Kept the generic *.conf files in /etc/nginx.
  3. Keep the default.conf in /etc/nginx/conf.d
  4. Created a 0.conf with the code above to load first for the obfuscation so it loads first

This makes sure all the required stuff gets loaded by default, the obfuscation stuff gets loaded BEFORE the default so the default.conf only modifies the configuration then the jira.conf (and confluence.conf) is added on the configuration with the directives specific to each.

And this time I rooted around in my Dockerfiles, source conf files, and exec'd into my test NGINX container to look at what is RUNNING in real life to make sure I wasn't talking out my.... hat... 

@Mike RathwellYou  don't need to  keep  the  confluence.conf file seperate you can  add the setting in   /etc/nginx.conf  and  /etc/nginx/conf.d/jira.conf  to  be  compact and easy  to  manipulate.

@Moses Thomas That is very true. In my case, however, I have this all containerized and tried to make it so only ADDing my bits discretely I get a couple of things:

  1. A better chance that a subsequent NGINX release that has new and fun things in default configurations don't break when I mess around in the default files with my Docker image build
  2. Lets me keep Jira and Confluence as separate conf files so small changes in those typically mean only a layer update when pushing a new image to the Docker repository

I did largely the same with Jira and Confluence configs - Added ONLY variables to the setenv.sh to ADD my own JVM Opts and memory settings during build and the rest is docker entrypoint scripts that xmlstarlet changes based on environment to server.xml and dbconfig.xml files.

Also I am not smart enough to deal with more than one thing at one time.

@Mike RathwellOk  i understand, Lets wait for @Priyank as i am highly  interested in this topic  best!

@Moses Thomas@Mike Rathwell,

Hi Guys,

Your support through this is deeply appreciated. 

So I did a port scan on jira.companyname.com yesterday, I should have done it long ago. And port 80 & 443 appear closed.

So much time and effort spent and turns out the other department didn't do this before they gave me the domain name. 

Well, lesson learnt. 

I have emailed the team asking them to open those ports after which I can resume my testing. Hopefully today they can figure it out so I can implement the changes you guys mentioned above. I will keep you posted. 

Once again, Thank you.

@Priyank

For now comment ProxyReserveHost and add these two lines in proxy in <Proxy*> </Proxy> in xml  proxy port should be 80 and restart jira again  and see what happens?

Order deny,allow

Allow from all

 

Best regards,

Moses,

I tried with the above recommendations. But it did not have any effect so far. 

Here is my error log: Dashboard Diagnostics: Mismatched URL Hostname JIRA is reporting that it is running on the hostname 'jira.companyname.com', which does not match the hostname used to run these diagnostics, '<ip addr>'. This is known to cause JIRA to construct URLs using the incorrect hostname, which will result in errors in the dashboard, among other issues.

I am running apache 2.4 and as per this document, 

Using Apache with mod_proxy

For V2.4, I think the Proxy tag should contain Require all granted. 

What might be wrong? Any other ideas?

Firstly  do  you have  apache server install on the host  jira is  running?  check  ip adress

and its better to  have a static  address  in Centos7 where Jira is running, one more thing  is you DNS server able to  resolve the host name where Jira is running?

Moses,

Yes Apache is installed as I get the version info on "httpd -v"

[root@srvvmjira bin]# httpd -v Server version: Apache/2.4.6 (CentOS) Server built: Apr 20 2018 18:10:38 [root@srvvmjira bin]#

And Static IP address is in use. Which I confirmed by "ifconfig" 

Yes my DNS server can access <ipaddr>:8099 and can access JIRA. But it can't access jira.companyname.com so far.

Does that make sense? Or I might be confused.

How about your ajp ? Did you enable them ?

As per PartB in this document to enable mod_proxy_ajp:

Since Centos7 has mod_proxy_ajp_proxy modules enabled by default, I did not touch that. 

In the same document as per PartB, 2. Configure the virtual hosts using mod_proxy_ajp:

Here is my code snippet at the end of my httpd.conf that I added.

<VirtualHost *:80> 
ServerName
jira.companyname.com
ProxyRequests Off
ProxyVia Off
# ProxyPreserveHost On
<Proxy *>
Require all granted
# Order deny,allow
# Allow from all
</Proxy>
ProxyPass /
http://<ipaddr>:8099
ProxyPassReverse /
http://<ipaddr>:8099

# <Location />
# Require all granted
# </Location>
</VirtualHost>

 I think I followed the steps as described. I tried few things with the Location tag, proxypreservehost and order allow. But ended up commenting it out as it did not help.

 

Thank you for your time and patience.

Did you enable it on your server.xml ?

VIckey,

Yes I made those changes in the xml file. 

<Connector port="8099"

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

enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"
bindOnInit="false"
proxyName="jira.company.com"
proxyPort="80"
scheme="http"/>

I added the last 3 lines of code for this purpose in this file.

Thank you for your time. 

Did you uncomment the ajp connection line ? your protocol doesnt say AJP .

It should be something like this ;

 

<Connector port="8009" redirectPort="8443" enableLookups="false" protocol="AJP/1.3" URIEncoding="UTF-8" 

I don't think what you've shown above is for AJP

And your apache configurations should have something like this ;

ProxyPass / ajp://localhost:8009/
ProxyPassReverse / ajp://localhost:8009

Vickey,

So I checked some links and there seem to be 2 ways of Proxying Atlassian server applications with Apache server. One is 'mod_proxy_http' and second on is 'mod_proxy_ajp' protocol.

Since all my efforts so far have been using mod_proxy_http, I am trying to exhaust all possibilities that come my way using this method. 

If nothing works I will switch over to ajp as you recommend. 

As of now like some others suggested, I am looking into NGINX in place of Apache. Hopefully that will bear some fruit.

I deeply appreciate your time and input.

Thank you.

Dang it... seems to have lost my post.

SO... here we go. This assumes that you have NGINX on your Jira host. If not, the proxy_pass directive in the below config changes to wherever Tomcat is serving Jira. Also , I did NOT put in the "fallback" port.

The DNS should point at wherever your NGINX server is running ONLY and even if it is running on a separate host. If it is a separate host from Jira, the NGINX server would then forward to the place stated in proxy_pass directive.

Server.xml

        <Connector

        port="8080"

        maxThreads="150"

        minSpareThreads="25"

        connectionTimeout="20000"

        enableLookups="false"

        maxHttpHeaderSize="8192"

        protocol="HTTP/1.1"

        useBodyEncodingForURI="true"

        redirectPort="8443"

        acceptCount="100"

        disableUploadTimeout="true"

        bindOnInit="false"

        proxyName="jira.company.com"

        proxyPort="443"

        scheme="https"

    />

NGINX - first the default configuration which is explicitly named 0.conf so it loads FIRST. The nice thing about this default is that something like nmap will ONLY see an open 80 and 443 but NOT return any applications by default.

# Instructions for defaults found on https://irulan.net/nginx-http-and-https-default-server/

server {

 

    listen 80 default_server;

    listen [::]:80 default_server ipv6only=on;

    server_name _;

 

    server_name_in_redirect off;

    log_not_found off;

 

    return 410;

 

}

 

server {

 

    listen 443 ssl default_server;

    listen [::]:443 ssl default_server ipv6only=on;

    server_name _;

 

    ssl_certificate /etc/nginx/certs/snakeoil-certificate.pem;

    ssl_certificate_key /etc/nginx/certs/snakeoil-key.pem;

 

    ## To ensure old/ancient versions of Nginx to be secure and not fall victim

    ## to SSLv3 vulnerabilities, uncomment the following lines:

    #

    # ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    # ssl_ciphers HIGH:!aNULL:!MD5;

 

    server_name_in_redirect off;

    log_not_found off;

 

    return 410;

 

}


Then the jira.conf file. The "." before the server_name is a special wildcard match for NGINX so it'll match jira.company.com or *.jira.company.com so I can use the same config for both production and test, for example

server {

    server_name .jira.company.com;

    listen 80;

 

    location / {

        return 301 https://$server_name$request_uri;

    }

}

 

server {

    listen 443 ssl;

    server_name .jira.company.com;

    ssl_certificate /etc/nginx/certs/jira2018-chained.crt;

    ssl_certificate_key /etc/nginx/certs/jira2018.key;

 

    client_max_body_size 0;

 

    location / {

        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:8080;

    }

}

 

@Mike Rathwell @Priyank Exactly i use nginx  also  and this would have been  lot  easier to  use instead  of apache i vote ngnix  so  may  be you  consider using  this reverse  proxy  server.

Moses,

Ok I will try it out at the earliest and post my results. I appreciate your time.

@Moses Thomas@Mike Rathwell@Vickey Palzor Lepcha,

I was finally able to finish this task. Here is the summary of issues faced.

1. The initial issue and the reason why I created this post was because no matter what I tried, I had a port mismatch on dashboard with Apache and NGINX. 

Reason was that ports were not accessible from outside. 

I totally misunderstood a text from IT that instructed me to change the DMZ port and to add a new NIC to the server. After some research I was able to make this change. 

2. After I was sure the changes were ok, I was still not able to access the server. Access ports on the new server were not opened by IT when they gave me the info. 

After some deliberation, we rectified that and the new NIC was up and running.

3. Going back to JIRA, I updated the server address on the nginx.conf file and JIRA was accessible from the internet. Voila!! 

Or so I thought, Turns out it was still not accessible from the internal network because of some routing rules that the IT folks had in place. And also this was just HTTP not HTTPS.

4. IT came back to me with updates on their policy and they opened the ports for internal access. Jira was accessible at HTTP.

I started working on the HTTPS and sent a generated cert to IT and they forwarded it to our CA.

CA came back with a cert but the download option was not available for Nginx but only Apache. I tried to fit it in just so hoping that there was no compatibility problem. 

5. But no, I got Nginx cert mismatch error. After some more research I found some post on godaddy for this case. I had to concatenate the two different certs from CA into one. After this change I thought I am all set.

6. But now when I access the site on browser, I got "URL scheme 'http', which does not match the scheme used to run these diagnostics, 'https'." on the Jira dashboard.

I changed the base URL in settings which fixed the issue. But wait.

7. In chrome, by the address bar, I got "Your connection is not fully secure" prompt for HTTPS. 

When I had first switched over to Nginx, the post I had followed had recommended I add a standard HTTP connector to my server.xml file along with HTTP & HTTPS. After some troubleshooting, I understood this was the issue. I commented out that instance from my server.xml and restarted Jira.

Success!! Sweet rewarding success!!

I have learnt a lot over the course of these few days that I am truly happy. And this isn't even my primary job!

Thank you all for your support.

I deeply appreciate your assistance.

I had a tough time myself when AJP was introduced with JIRA for the first time. Eventually, it has been smooth.

The take away is this - you will have quite a smooth JIRA upgrades( system admin perspective) now that you know what could get reset on server.xml file during upgrade :p

 

Congratulations on your learning journey - we all are learning.

@PriyankGood to  get feed back  from  you  and happy :) that you  have learned and we  tried to  help  as much  as we can.

 

Best!

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,180 views 5 10
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you