HiI installed Jira 8 on a Ubunt 18.04, using a lighttpd reverse proxy to offer https to clients.On the dashboard I get a "gadget.common.error.500"
Th error in catalina.out seems to be the cause:14-Feb-2019 08:33:52.483 WARNING [http-nio-8080-exec-9] com.sun.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI https://es.hinlocal.ch/rest/activity-stream/1.0/preferences?_=1550133232310, contains form parameters in the request body but the request body has been consumed by the servlet or a servlet filter accessing the request parameters. Only resource methods using @FormParam will work as expected. Resource methods consuming the request body by other means will not work as expected.How do i fix this?
Hello,
I also had the same problem on Jira 8. I fixed it by providing the correct baseUrl in the System -> General Configuration
The base URL is correct, it is the one the reverse proxy listens to.
I had this problem after configuring direct SSL with self-signed certificates in JIRA 8.0.1 tomcat. In main board i was getting gadget.common.error.500 error message.
After few hours i have managed to solve it by adding my self-signed ca and server certificates to tomcats jre keystore:
keytool -importkeystore -destkeystore cacerts -srckeystore /opt/certs/servkeystore.p12 -srcstoretype pkcs12 -alias tomcat -deststorepass changeit -srcstorepass <yourstorepass> -validity 3650keytool -importkeystore -destkeystore cacerts -srckeystore /opt/certs/keystore.p12 -srcstoretype pkcs12 -alias ca -deststorepass changeit -srcstorepass <yourstorepass> -validity 3650
BTW Confluence 6.14 does not have this problem and works without this configuration.
Have not tried this out but makes sense, thanks!
Just hit the same issue and the certificate import solved it for me as well. Thank you
It's not working for me. I'm putting the certificates on cacerts of embedded JRE from Jira located in /opt/atlassian/jira/jre/lib/security/cacerts.
Based on @Romualdas answer, I was able to fix this error.Importing my local intermediate certificate to the Jira cacerts store worked instantly:
keytool -importcert -file intermediate.cer -keystore /opt/atlassian/jira/jre/lib/security/cacerts -alias "local.ch"
@O ZI having this same issue but I don't have this file in your CMD you provided.
After upgrading from 7.11 to 8.3 this is what's currently in our folder
But before we upgraded our Jira this is WHAT we had in our folder
I don't quite understand, what file are you referencing? cacerts file is there on both screenshots. If you are refering to the intermediate.cer, this is the one I used to sign the locally issued certificate.
@O ZI tried running the CMD you provided and it didn't do anything for me.
I changed the url but no luck do I need to restart tomcat
Just wanted to add some more info in case anyone else came across a similar situation. In my case, there's a few specific configurations that are important...
- Jira is running in a docker container using AWS ECS and a load balancer with path based routing
- SSL is terminated at the load balancer
- The load balancer has a DNS alias atlassian.my.domain.com
- The environment variable ATL_PROXY_NAME is set to match the alias above
- The certificate is entered into the trust store via a command like the following (where ${loadbalancer} is the DNS name of the load balancer);
openssl s_client -connect ${loadbalancer}:443 -servername ${loadbalancer}:443 < /dev/null | sed -ne \"/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p\" > public.crt; /opt/java/openjdk/bin/keytool -import -alias ${loadbalancer} -keystore /opt/java/openjdk/jre/lib/security/cacerts -file public.crt -storepass changeit -noprompt
Some of the troubleshooting steps I had come across pointed me toward adding an extra hosts entry of 127.0.0.1 -> atlassian.my.domain.com. The problem for me is that since SSL is terminated at the load balancer, redirecting the alias to 127.0.0.1 resulted in a failure to connect. This is apparent when running the following command from inside the container via docker exec;
openssl s_client -showcerts -connect atlassian.my.domain.com:443
The result is that the connection is refused. That's because 127.0.0.1 isn't listening on that port, it's only using HTTP. I was also able to confirm that when running the same command against the load balancer DNS name (NOT the alias) it is successful. So in my case I needed to specifically not have the hosts entry. The unfortunate side effect of this design is that traffic must go from the container to the external load balancer IP to resolve the gadget error. For folks in a similar situation, I would highly recommend using the above openssl command from the server/container to validate that the connection succeeds and that the certificate presented is in the trust store. For folks running Jira on Windows, you should be able to use something like this (https://gist.github.com/jstangroome/5945820) to grab the certificate from the alias.
It looks like you're new here. Sign in or register to get started.
