I have Jira Software 7.3.1 running on Windows Server 2012.
First time I was using it at xxx.xxx.xxx.xxx:8080 and everything worked fine.
Now I've to migrate it to a subdomain.
I've done everything according to this article https://confluence.atlassian.com/adminjiraserver071/integrating-jira-applications-with-iis-802593039.html and eveyrhing works good.
Now I have to use SSL certificate on this subdomain and I'm refering to https://confluence.atlassian.com/adminjiraserver071/running-jira-applications-over-ssl-or-https-802593051.html
When using system without HTTPS - it working. If I'm using with HTTPS, I see a lot of errors in browser console that requests were blocked because of asking http... from https...
Screenshot
I suppose, it is because I have not installed redirect
<security-constraint>
<web-resource-collection>
<web-resource-name>all-except-attachments</web-resource-name>
<url-pattern>*.jsp</url-pattern>
<url-pattern>*.jspa</url-pattern>
<url-pattern>/browse/*</url-pattern>
<url-pattern>/issues/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
But when I'm installing this redirect suddenly port 8443 is added
https://sub.domain.com:8443/secure/Dashboard.jspa
Please, advice what to do in this situation.
My server.xml
<?xml version="1.0" encoding="UTF-8"?>
<Connector acceptCount="100"
connectionTimeout="20000"
disableUploadTimeout="true"
enableLookups="false"
maxHttpHeaderSize="8192"
maxSpareThreads="75"
maxThreads="150"
minSpareThreads="25"
port="8080"
protocol="HTTP/1.1"
redirectPort="8443"
proxyName="sub.domain.com"
proxyPort="80"
useBodyEncodingForURI="true"/>
<Connector URIEncoding="UTF-8" enableLookups="false" port="8009" protocol="AJP/1.3" redirectPort="8443"/>
<Engine defaultHost="localhost" name="Catalina">
<Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true">
<Context docBase="${catalina.home}/atlassian-jira" path="" reloadable="false" useHttpOnly="true">
<Resource auth="Container" factory="org.objectweb.jotm.UserTransactionFactory" jotm.timeout="60" name="UserTransaction" type="javax.transaction.UserTransaction"/>
<Manager pathname=""/>
<JarScanner scanManifest="false"/>
</Context>
</Host>
<Valve className="org.apache.catalina.valves.AccessLogValve" pattern="%a %{jira.request.id}r %{jira.request.username}r %t "%m %U%q %H" %s %b %D "%{Referer}i" "%{User-Agent}i" "%{jira.request.assession.id}r""/>
</Engine>
<Connector SSLEnabled="true"
acceptCount="100"
clientAuth="false"
connectionTimeout="20000"
disableUploadTimeout="true"
enableLookups="false"
keyAlias="my_alias"
keystoreFile="path_to_keystore.jks"
keystorePass="mypassword"
keystoreType="JKS"
maxHttpHeaderSize="8192"
maxSpareThreads="75"
maxThreads="150"
minSpareThreads="25"
port="8443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
scheme="https"
secure="true"
sslProtocol="TLS"
proxyName="sub.domain.com"
proxyPort="443"
useBodyEncodingForURI="true"/>
</Service>
</Server>
Also important thing is that from config wizard I cannot select HTTP and HTTPS as it's not active for me. Just HTTP or HTTPS can be selected.
Please, help me to avoid adding 8443 port to URL.
Thanks in advance!
Could you explain where you are trying to terminate the SSL connection?
In other words, is IIS supposed to be doing all the SSL work, or are you trying to make JIRA's Tomcat do it as well?
Hello Nic,
if I understand correctly, this is a solution?
I've googled a little and found article https://stackoverflow.com/questions/31922167/iis-how-to-simulate-ssl-termination-on-load-balancer
Have I to do the same as described there?
This is IIS realization, is there any other way, less complex?
I haven't done any termination of ssl connection. I just followed articles (links above)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Not that I know of, that article doesn't seem to be about SSL proxies in IIS.
IIS is pretty horrid for doing this sort of work, a far less complex solution is running Apache or nginx as a proxy, but you should stick with IIS if your systems are all IIS based.
I'm sorry, I did not explain "termination of ssl" - you are doing it if you use https. The phrase means "where does the encryption stop". Imagine a standard proxy server setup of:
User -1> Internet -2> Your proxy -3> JIRA
Your user fires up an SSL connection over the internet. You can "terminate the SSL" at -2> or at -3> here. Whichever one you chose, the work of encryption is done on the server it lands on.
JIRA's Tomcat is not a good place to do it - it loads the JIRA process, it's not particularly flexible, it doesn't fit in well with the reasons most people use proxies, and it means some fiddling with the proxy to make it work. It is preferable to do it on the proxy server (IIS in your case). The question I'm asking is where you want to do it?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Nic for you answer.
All websites are stored in IIS. It can be difficult to install Apache and make them both listent to 80 and 443 ports.
So, I've to look how to do this in IIS.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The solution was found:
1. Create on IIS website, add ssl certificate, bind app to 80 and 443 port
2. Using IIS URL rewrite module create 2 proxy rules rewriting to Https://jira_host:8443
3. Enable jira 8443 port according to the articles above.
And everything will work, there is no need to use tomcat IIS connector.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi there, can you elaborate on this a bit? I tried creating the proxy rules but it makes me download and install ARR 3.0 and then says something about configuring a server farm which is not my intent at all. How exactly did you create those rules? Btw, I do have the IIS URL rewrite module installed.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.