Hello,
I´m having problems follwing this guide:
The first part, Generate the Java KeyStore was done succesfully.
However, I'm having problems with the 2nd part of the guide, configuring the web server.
I have tried the standard steps using the JIRA configuration tool, but after restart the JIRA app I get this error:I understand that the changes I made through the JIRA configuration tool is only making changes in the server.xml file.
So I tried the Advanced configuration, configuring the 8443 connector directly on the server.xml file
as it follows:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxHttpHeaderSize="8192" SSLEnabled="true"
maxThreads="150" minSpareThreads="25"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
sslEnabledProtocols="TLSv1.2,TLSv1.3"
clientAuth="false" useBodyEncodingForURI="true"
keyAlias="jira" keystoreFile="<JIRA_HOME>/jira.jks" keystorePass="changeit" keystoreType="JKS"/>
I had the same error. I edit the kestoreFile and pass to what I have.
I edit again this file and added in the connector:
relaxedPathChars="[]|"
relaxedQueryChars="[]|{}^\`"<>"
Bur I'm still having the same error.
This server is on production. So, to do rollback I configure http only again in the config tool and replace a backup of the sserver.xml file
This is what I´m running:
Server version: Apache Tomcat/8.5.32
Some questions for you;
What is the full address you are observing to get the error page you provided above?
Are you using Linux or Windows as your root OS?
Linux:
As it will significantly simplify the configuration process, have you used the .../bin/config.sh file to configure your https connection?
So, I take it that the server itself receives https encapsulated packets on port 8443;
OR do you have a reverse proxy in front of it; Nginx, Apache Tomcat, HAProxy, which will de-encapsulate it from https?
Hi, I´m using Windows Server 2012 R2 as root OS.
I used the config.bat and I think is the alternative of config.sh for windows.
I can not give you the full address since the server is on production right know and I can not generate the error until tomorrow.
My bad for not taking a full PrtSCrn. What I can tell you is that I start the browser and go to https:localhost/8443, and the browser shows that the Jira is loading plugins which is normal after rebooting.
When it finish the web changes and is the prtscr what I see.
I´m trying all this with local host directly because i don´t want to add possible problems to the "migration"
After I try that everything works on local host directly on port 8443 I will configure my reverse proxy, but I do not have problems with that for now.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I wager you are trying to test with https enabled? (as the port="8443" and SSLenabled="true")
This will make a demo of the server a bit more complicated, but that is a requirement these days.
I should warn you however, that SSL/TLS configuration ON the server itself is almost entirely unsupported by Atlassian though (through my experience with support), so I would suggest using a reverse proxy in front of it, so that you can eliminate many of these issues immediately;
https://confluence.atlassian.com/kb/reverse-proxy-and-application-link-troubleshooting-guide-719095279.html
On my own servers, I have found haproxy to be substantially simpler to configure than the suggestions from Atlassian (Apache/Nginx), but that is a matter of taste and familiarity.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I finally get it working. I realize that I was removing the http connector when adding the new one.
Thanks for your help!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Finally, following the advanced part 2 of the tutorial it´s working. When adding the connector for SSL I was removing the http connector. So I manually edit the server.xml file to keep both
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ah, yes.
Great to hear you found a resolution Valentin.
To accompany this;
This is another reason I suggested a proxy previously; It is easier to break down what causes issues; In this case because I do not require port redirection (ports are redirected on our proxy), it is easier to diagnose an issue with the server.xml file.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.