JIRA and Confluence Using the Same FQDN and SSL Cert

[El Jefe]

I've got JIRA up and running on port 8444 over SSL a specific FQDN and a CA-signed cert. It works great. Now, I want to run Confluence over SSL on the same Linux server using the same FQDN on port 8443. Confluence is already running ok on the box, using http on port 8090.

I have been looking at the instructions here (https://confluence.atlassian.com/display/DOC/Running+Confluence+Over+SSL+or+HTTPS), but it seems like those instructions are meant for a FQDN running only Confluence, as it requires me to submit a new CSR to my CA. I can't do this, as I already have imported the CA response into JIRA's .jks file that the cert request originated from. After reading this item (https://answers.atlassian.com/questions/260235), I tried pointing Confluence's server.xml to the .jks keystore that JIRA is using, but it does not work. The password for the keystore and the private key are the same.

I also tried copying the .jks keystore file to another directory, in case there were access restrictions on the JIRA directory containing the .jks, but still no joy. I then tried changing the name of the alias for the private key to 'tomcat', which I think would be the alias if I followed original instructions from above (https://confluence.atlassian.com/display/DOC/Running+Confluence+Over+SSL+or+HTTPS)

Ultimately, I want to set up trust relationship between the two and let JIRA act as the user repository for both.

Has anyone experienced this problem or have steps to use the same FQDN and Cert for both JIRA and Confluence or suggestions on what else I should check as possible sources for the problem?

[Timothy]

I would recommend you to scrap that and put Apache in front of JIRA and Confluence. You can then put the SSL cert in the Apache layer and not mess with the ports at the Tomcat layer. You can use this guide (https://confluence.atlassian.com/display/JIRA/Integrating+JIRA+with+Apache+using+SSL) for both JIRA and Confluence.

[El Jefe]

That makes sense to me, at least in writing. I have been trying to avoid touching Apache as part of this, as I am short on time and don't know if I can scale its learning curve just now. There's also another app on the server using an Apache install and I am ignorant of what I need to do to make sure they are all playing nice.

If I choose a different FQDN for Confluence and follow the steps for setting it up using SSL, will I mess up my JIRA install? Those steps use $JAVA_HOME  variable, which is pointing to the JRE folder in my JIRA directory. If it won't hurt JIRA, I may just go with a different subdomain for the Confluence server until I get my act together to tackle Apache.

[B_ Normann P_ Nielsen]

I agree 100% with Timothy Chin, using SLL directly in tomcat sucks, and all these changes to xml files i /conf makes upgrades a bitch. Setting an Apache in front with SSL termination is quite simple (compared to doing jks files....) So upgrades are easier, SLL renewal way simpler and You can use the Apache for stuff like blocking urls, rewriting stuff etc etc... also, You can use default ports 8080 and 8090 and just proxypass 443 (https) in apache. I have a non SSL part at http://www.mos-eisley.dk/display/it/Apache2+Proxy+Passing - to use SSL look at the default SSL file comming with apache2 i something list /etc/apache2/sites-available