gadget.common.error.500

Reporting HIN February 14, 2019

Hi

I 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?

4 answers

4 votes
Romualdas February 28, 2019

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 3650
keytool -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.

O Z February 28, 2019

Have not tried this out but makes sense, thanks!

Like Matthias Wuertele likes this
garyj April 1, 2019

Just hit the same issue and the certificate import solved it for me as well. Thank you

Like deamond likes this
Vinícius Ferrão May 22, 2019

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.

Romualdas May 23, 2019

Hi, Vinicius,

Do you see imported certificates in keystore:

keytool -list -keystore /opt/atlassian/confluence/jre/lib/security/cacerts

Do you see whole chain of these certificates (root, intermediate, server) in keystore?

For self signed certs to work with updated browsers there must be at least root and branch server cert, encryption algorithm must be at least SHA256, and in server certificate Subject Alternate Names there must have FQDN of the server.

Vinícius Ferrão May 24, 2019

Yes, I can see the certificate:

[root@atlassian ~]# keytool -list -keystore /opt/atlassian/jira/jre/lib/security/cacerts | grep jira

Enter keystore password:  changeit

jira, May 24, 2019, PrivateKeyEntry, 

I don't have root CA or intermediate, since it's a self-signed one. Generated following the Atlassian SSL guide: https://confluence.atlassian.com/jira/connecting-to-ssl-services-117455.html

I tried everything that you could imagine. I don't know what to do anymore. Struggling for 2 complete days with it.

There's an open discussion with my settings, one of them: https://community.atlassian.com/t5/Jira-questions/gadget-common-error-500-using-nginx-and-HTTPS/qaq-p/1091220

Thanks,

garyj May 24, 2019

We had the same issue, using a GoDadddy signed certificate. And the solution above worked. It was important to make sure that we had a PKCS12 keystore which we then added to the cacerts in our case:

/opt/atlassian/jira/jre/lib/security/cacerts

the command identical to Mindaugas 

keytool -importkeystore -destkeystore cacerts -srckeystore /home/certs/pfx/wildcard-certificate-godaddy.pfx -srcstoretype pkcs12 -deststorepass changeit -srcstorepass [INSERT PASSWORD] -validity 3650

From memory it was important to have the PKCS12 (.pfx) as nothing else would work. 

As it's a wild card certificate which works for all out sub domains: *.domain.tld, I think even at one point I exported it from a Windows IIS server which created a nice little .pfx file which was easily imported using the above command into cacerts. 

Also had a brief look at your config, don't have time at the moment to look in great detail, but this my connector in server.xml from the machine where we ran the above command to fix the error. 

 

<Connector port="[INSERT YOU PORT NUMBER]" protocol="org.apache.coyote.http11.Http11NioProtocol" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"              maxHttpHeaderSize="8192" SSLEnabled="true"              maxThreads="150" minSpareThreads="25"              enableLookups="false" disableUploadTimeout="true"              acceptCount="100" scheme="https" secure="true"              clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"              server.ssl.key-alias="tomcat"          keystoreFile="/home/certs/pfx/wildcard-certificate-godaddy.pfx" keystorePass="[INSERT PASSWORD]" keystoreType="PKCS12"/>
Christopher O_Neill June 1, 2020

Quick question I tried to do the fix with the CAcerts and I replaced the original one inside the /security folder with the one that has my domain cacerts will that affect jira and if so does anyone know how to recover or get a copy of the original cacerts 

0 votes
Steve Orman July 16, 2020

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. 

0 votes
O Z July 10, 2019

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"

S_ Toyo August 5, 2019

@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

2019-08-05_10-19-31.png

But before we upgraded our Jira this is WHAT we had in our folder

2019-08-05_10-20-42.png

O Z August 5, 2019

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.

S_ Toyo August 6, 2019

@O ZI tried running the CMD you provided and it didn't do anything for me.

keytool -importcert -file intermediate.cer -keystore /opt/atlassian/jira/jre/lib/security/cacerts -alias "local.ch"

O Z August 6, 2019

@S_ Toyo   the part "-file intermediate.cer" references a file that must exist on your device. Intermediate.cer should be the singing certificate of your jira certificate.

S_ Toyo August 6, 2019

@O ZCan I use any of the files from my backup for my upgraded version? I made a backup of the entire directory and see a cacerts file a keystorePKCS12 file etc. I wasn't the person who did all this the first time around. As that person left our company. And this is the very first time we are upgrading any Atlassian product.

O Z August 6, 2019

@S_ Toyo  Yeah you can try with the cacerts file from a backup. Otherwise go to any website you host with your self-signed cert with firefox, go to the lock symbol -> secure connection -> more information -> security -> show certificate -> details -> certificate hierarchy *click* -> Export. 
This should be your file for the "-file" parameter. 

Like S_ Toyo likes this
S_ Toyo August 7, 2019

@O ZWe will try this! Thanks! :)

Vassily Pupkin October 16, 2019

Adding certs to cacerts file worked for me as well. We have Windows PKI infrastructure, which propagates certificates across AD domain, so I simply exported relevant certs (we have both a root and an issuer) to .cer files on one of windows machines and then used portecle to add those to cacerts file. 

Ajay Gupta December 11, 2019

Hi,

The command word for me when I tried using "jira.domain.tld"

keytool -importcert -file intermediate.cer -keystore /opt/atlassian/jira/jre/lib/security/cacerts -alias "jira.domain.tld"  and browse jira using (https://jira.domain.tld)

I still see issue when I use following's:

keytool -importcert -file intermediate.cer -keystore /opt/atlassian/jira/jre/lib/security/cacerts -alias "ci.domain.tld"

JIRA URL is :   https://ci.domain.tld/jira

 

I am using let's encrypts certificates, which should be of issue as they work for jira.domain.tld.

My Base URL are properly set (https://jira.domain.tld  and  https://ci.domain.tld/jira) in both cases.

thanks for any pointers.

0 votes
Alexey Matveev
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 14, 2019

Hello,

I also had the same problem on Jira 8. I fixed it by providing the correct baseUrl in the System -> General Configuration

O Z February 14, 2019

The base URL is correct, it is the one the reverse proxy listens to.

Like Radik Mukhiev likes this
Christopher O_Neill June 1, 2020

I changed the url but no luck do I need to restart tomcat

Like Dmitry Zotov likes this

Suggest an answer

Log in or Sign up to answer