It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

gadget.common.error.500

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

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.

Have not tried this out but makes sense, thanks!

Like Matthias Wuertele likes this

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

Like deamond likes this

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.

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.

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,

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"/>

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

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.

Like Radik Mukhiev likes this

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

Based on @Mindaugas Valkavicius 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

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

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.

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

@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.

@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.

@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

@O ZWe will try this! Thanks! :)

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. 

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

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. 

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Jira Software

How to create Jira issus from Excel file?

When to use CSV importer When managing your processes in Jira, there are many occasions where you need to create a lot of tasks. Creating them one by one will cost you a lot of time and effort and i...

3,616 views 15 25
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you