Jira 500 error

Problem

When attempting to log in a user sees a message «ERROR OCCURRED» or a page saying there is a 500 error. The 500 error page and JIRA logs show In ‘print’ tag, expression «$dashboardTitle» evaluates to undefined. 

• This error may also show if the user is logged in and navigates to the dashboard.

The full error may vary. The followings are examples of how this error may appear:

2017-10-10 17:02:15,346 http-nio-8080-exec-22 ERROR user 1022x72x1 nzdy6m 172.26.101.158,127.0.0.1 /secure/Dashboard.jspa [c.a.j.web.servlet.InternalServerErrorServlet] {errorId=7a2145ee-058a-4a60-8736-1f785b5228ee, interpretedMsg=, cause=com.google.template.soy.tofu.SoyTofuException: In 'print' tag, expression "$dashboardTitle" evaluates to undefined., stacktrace=com.google.template.soy.tofu.SoyTofuException: In 'print' tag, expression "$dashboardTitle" evaluates to undefined....

2016-12-07 07:26:57,779 http-nio-8080-exec-22 ERROR user 446x4928x1 f7vyfp 0.0.0.0 / [[Catalina].[localhost].[/].[action]] Servlet.service() for servlet action threw exception
com.google.template.soy.sharedpasses.render.RenderException: In 'print' tag, expression "$dashboardTitle" evaluates to undefined.
    at JIRA.Dashboard.page.dashboard(dashboard.soy:12) [?:?]
...

2016-12-07 07:26:58,754 http-nio-8080-exec-22 ERROR user 446x4928x1 f7vyfp 0.0.0.0 / [jira.web.filters.CommittedResponseHtmlErrorRecoveryFilter] Exception occurred after HTTP response was already committed: javax.servlet.ServletException: java.lang.RuntimeException: com.google.template.soy.tofu.SoyTofuException: In 'print' tag, expression "$dashboardTitle" evaluates to undefined.
...

2016-12-07 07:26:58,108 http-nio-8080-exec-22 ERROR user 446x4928x1 f7vyfp 0.0.0.0 / [ContainerBase.[Catalina].[localhost].[/]] Unhandled exception occurred whilst decorating page
java.lang.RuntimeException: javax.servlet.ServletException: java.lang.RuntimeException: com.google.template.soy.tofu.SoyTofuException: In 'print' tag, expression "$dashboardTitle" evaluates to undefined.
    at com.atlassian.web.servlet.plugin.DynamicAuthorizationServletForwarder.forward(DynamicAuthorizationServletForwarder.java:55) [?:?]
    at com.atlassian.web.servlet.plugin.SanitizingServletForwarder.forward(SanitizingServletForwarder.java:32) [?:?]
    at com.atlassian.web.servlet.plugin.RememberingServletForwarder.forward(RememberingServletForwarder.java:51) [?:?]
    at com.atlassian.web.servlet.plugin.ResolvingServletForwarder.forward(ResolvingServletForwarder.java:38) [?:?]
...
Caused by: javax.servlet.ServletException: java.lang.RuntimeException: com.google.template.soy.tofu.SoyTofuException: In 'print' tag, expression "$dashboardTitle" evaluates to undefined.
    at com.atlassian.jira.web.dispatcher.JiraWebworkActionDispatcher.onActionException(JiraWebworkActionDispatcher.java:220) [classes/:?]
    at com.atlassian.jira.web.dispatcher.JiraWebworkActionDispatcher.service(JiraWebworkActionDispatcher.java:172) [classes/:?]
...
Caused by: com.google.template.soy.tofu.SoyTofuException: In 'print' tag, expression "$dashboardTitle" evaluates to undefined.
    at JIRA.Dashboard.page.dashboard(dashboard.soy:12) [?:?]
    at com.google.template.soy.tofu.internal.BaseTofu.renderMainHelper(BaseTofu.java:369) [?:?]
    at com.google.template.soy.tofu.internal.BaseTofu.renderMain(BaseTofu.java:322) [?:?]
    at com.google.template.soy.tofu.internal.BaseTofu.access$100(BaseTofu.java:66) [?:?]
    at com.google.template.soy.tofu.internal.BaseTofu$RendererImpl.render(BaseTofu.java:476) [?:?]
    at com.atlassian.soy.impl.DefaultSoyTemplateRenderer.render(DefaultSoyTemplateRenderer.java:45) [?:?]
    at com.atlassian.soy.impl.DefaultSoyTemplateRenderer.render(DefaultSoyTemplateRenderer.java:39) [?:?]
...

Cause

There’re a few possible causes:

1. The affected user has access to multiple dashboards with the same name and the same owner.
   • Note: The affected user does not need to be the owner of the dashboard(s). For example, the affected user may have them as part of their favorites.
2. There’s a corrupted application link.
3. Base URL healthcheck fails due to SSL certificate using SAN (applicable in JIRA 7.4 and above).
4. (Extra) You may also check this similar KB: Unable to Load Jira Dashboard seeing an HTTP 500 error when using F5 BigIP as a reverse proxy.
5. (Extra) The problem is happening on Jira Data Center with 2 nodes or more, and there is a symlink configured in each node pointing from the Jira home folder to the Jira shared folder, as explained in Error 500 when loading various Jira page(s) and JVM crashes

Diagnosis

1. For Cause 1, use the following SQL query to identify if there are multiple dashboards with the same name:

   SELECT * FROM portalpage WHERE pagename IN (SELECT pagename FROM portalpage GROUP BY pagename HAVING COUNT(pagename) > 1); 

   If 1 or more results are returned then you are impacted by this problem. If not, please check the below.

2. For Cause 2, do the following:

   1. Go to the Application Links page.
   2. Check the status of the application links as well as if any of them is not in use.

   If all application links are good, check the below.

3. For Cause 3, this error is thrown in the logs:

   2017-10-10 17:04:06,623 HealthCheck:thread-5 ERROR ServiceRunner     [c.a.t.j.healthcheck.support.BaseUrlHealthCheck] An error occurred when performing the Base URL healthcheck: 
   java.lang.ClassCastException: [B cannot be cast to java.lang.String
   	at org.apache.http.conn.ssl.DefaultHostnameVerifier.getSubjectAltNames(DefaultHostnameVerifier.java:309)

Resolution

For Cause 1

The fix is to make it so that there are no longer duplicate dashboard names under a single owner. It should be safe to have dashboards with duplicate names as long as the dashboards are not owned by the same user.

 Please do not attempt to modify this in the database.

1. Use the diagnosis query to determine the owner of the problem-causing dashboards.
2. The user will need to log into JIRA and then go to the following URL. This URL will be accessible even if the user encounters an error when logging in.
   1. BASE_URL/secure/ConfigurePortalPages!default.jspa
3. Edit one of the dashboards that have duplicate names. Change the name so that there is no longer a duplicate.

For Cause 2

1. Delete the unused application links. Mind the duplicated entries
2. For the other applinks, if there is a warning/error and you observe that the connection is not working, we would suggest removing the corresponding application links and testing if the dashboard can be accessed properly.

For Cause 3

There’re only workarounds for this cause:

• Temporarily use an SSL certificate that doesn’t use SAN
• Temporarily run JIRA over HTTP

Symptoms

The following page appears when trying access to the Statuses page:

Or you can’t see any workflow listed when navigating to workflows page.

With the following Error when expanded:

Technical details
Log's referral number: 0b8255e1-5025-4373-bbbb-744ded4b9177

Cause
Referer URL: http://10.60.5.147:8624/jira624/secure/admin/ViewStatuses.jspa
com.google.template.soy.tofu.SoyTofuException: In template JIRA.Templates.Statuses.success: In 'foreach' command {foreach $status in $statuses}{call .statusRow}{param status: $status /}{/call}{/foreach}, the data reference does not resolve to a SoyListData.
com.google.template.soy.tofu.SoyTofuException: In template JIRA.Templates.Statuses.success: In 'foreach' command {foreach $status in $statuses}{call .statusRow}{param status: $status /}{/call}{/foreach}, the data reference does not resolve to a SoyListData.
	at com.google.template.soy.tofu.internal.BaseTofu.renderMainHelper(BaseTofu.java:341)
	at com.google.template.soy.tofu.internal.BaseTofu.renderMain(BaseTofu.java:300)
	at com.google.template.soy.tofu.internal.BaseTofu.access$100(BaseTofu.java:56)
	at com.google.template.soy.tofu.internal.BaseTofu$RendererImpl.render(BaseTofu.java:427)

Referral number can be used to search for the relevant log.

errorId=0b8255e1-5025-4373-bbbb-744ded4b9177

Diagnosis

Check in the atlassian-jira.log whether the following error is written:

Caused by: com.atlassian.cache.CacheException: java.lang.IllegalStateException: There are more than one draft workflows associated with the workflow named '<workflow name>'
	at com.atlassian.cache.memory.DelegatingCache.get(DelegatingCache.java:67)
	at com.atlassian.jira.workflow.CachingDraftWorkflowStore.getDraftWorkflow(CachingDraftWorkflowStore.java:55)
	at com.atlassian.jira.workflow.OSWorkflowManager.getDraftWorkflow(OSWorkflowManager.java:249)

or 

Caused by: com.atlassian.cache.CacheException: java.lang.IllegalStateException: There are more than one workflows associated with '<workflow name>' in the database!
	at com.atlassian.cache.memory.DelegatingCache$DelegatingLoadingCache.get(DelegatingCache.java:270)
	at com.atlassian.jira.workflow.CachingWorkflowDescriptorStore.getWorkflow(CachingWorkflowDescriptorStore.java:68)
	at com.atlassian.jira.workflow.JiraWorkflowFactory.getWorkflow(JiraWorkflowFactory.java:37)
	at com.opensymphony.workflow.config.DefaultConfiguration.getWorkflow(DefaultConfiguration.java:89)

or 

2016-04-07 15:35:49,564 http-nio-8711-exec-20 ERROR <username> 935x813x1 r6dcz1 172.18.66.246 /secure/admin/workflows/ListWorkflows.jspa [webwork.util.ValueStack] query="inactiveWorkflows" {[id="inactiveWorkflows" type="8" values=""]}
java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 

Cause

1) The JIRA application database has a duplicate record for a draft workflow. The problem is likely to occur when there are multiple Administrators who are creating workflow drafts of the same workflow at roughly the same time.

JRA-40009
—
Getting issue details…
STATUS

1.1) The Jira application has a corrupted draft workflow(only one). We cannot open the original workflow for editing.

2) The JIRA application database has a duplicate record for a workflow. 

3) There are orphaned scheme references (e.g. workflow, permission, notification) in the nodeassociation JIRA table referencing a deleted project. This produces a NullPointerException when the workflow list is populated. The following SQL query can be used to diagnose the problem:

select * from nodeassociation where SOURCE_NODE_ENTITY='Project' AND SOURCE_NODE_ID not in (select ID from project);

4) Workflow contains duplicate actions

Resolution 1

1. Run the following SQL query on the database (to identify the drafts with more than one entry):

   SELECT count(*), parentname FROM jiradraftworkflows group by parentname having count(*) > 1;

   For the workflows(not draft), run the following query :

   SELECT count(*), workflowname FROM jiraworkflows group by workflowname having count(*) > 1;

2. Delete one of the Id which have the same parentname.

   SELECT id, parentname from jiradraftworkflows;
   DELETE from jiradraftworkflows where id = <chosen_id_with_duplicated_parentname>;

   For the workflows(not draft), run the following query :

   SELECT id,workflowname FROM jiraworkflows;
   DELETE from jiraworkflows where id = <chosen_id_with_duplicated_workflowname>;

3. Restart JIRA.
4. Run a re-index of your instance.

Resolution 1.1

Run the following SQL query on the database (to identify all the draft workflows):

select id,parentname from jiradraftworkflows ;

Try to open each of the workflows for editing and notice if you face any issue while opening any

If you face an error while opening a workflow for editing, you will need to follow these steps: 

1. Shutdown JIRA (as the draft workflow XML could be cached in memory)
2. Run the following SQL:

-- Confirm the draft workflow ID being deleted (should return 1 and only 1 row)
SELECT id, parentname from jiradraftworkflows where id = <workflow_id_with_error>;

-- Run the delete
DELETE from jiradraftworkflows where id = <workflow_id_with_error>;

-- You should get 1 row affected

-- Check that the workflow is now gone (should return 0 rows)
SELECT id, parentname from jiradraftworkflows where id = <workflow_id_with_error>;

-- You may need to run COMMIT if your SQL editor does not do auto-commit
commit;

1. Start JIRA and check that you can now click on JIRA Administration » Issues » Statuses without errors

Resolution 2

1. Run the following SQL query on the JIRA database to identify orphaned schemes associated to a deleted JIRA project. This query should return no results. If you do get any results, you are likely affected by this.

   Diagnosis: orphaned rows in the nodeassociation table

   select * from nodeassociation where SOURCE_NODE_ENTITY='Project' AND SOURCE_NODE_ID not in (select ID from project);

2. Run the following query to delete these orphaned schemes for non-existent projects: 

   Remove orphaned rows in the nodeassociation table

   delete from nodeassociation where SOURCE_NODE_ENTITY='Project' AND SOURCE_NODE_ID not in (select ID from project);

3. Restart JIRA.
4. Run a re-index of your instance.

Resolution 3

Resolution 4

Incase you are using script-runner plugin then issue can be resolved by executing below code in script runner console:

Navigator produces a 500 error page in JIRA and you have no clue why?

At Bobcares, we offer solutions for every query, big and small, as a part of our Server Management Service.

Let’s take a look at how our Support Team recently helped a customer when their Issue Navigator produced a 500 error page in JIRA.

Why does Issue Navigator Produce a 500 error page in JIRA?

The 500 error page often appears after modifying an agile simplified workflow for a specific project by deleting it rather than recreating one manually and associating it with the Project that still had issues. This results in no access to the Issue Navigator as well as the 500 error page.

For instance, you will see a warning similar to the one below:

"Generated by JIRA Agile version 6.6.0-D20140904T040435. This workflow is managed internally by JIRA Agile. 
Do not manually modify this workflow."

Although we do not have access to the cloud instance’s logs, we can still observe the following in the atlassian-jira.log file:

2021-11-10 11:12:13.794451500 Sep 10, 2014 11:12:13 AM org.apache.catalina.core.ApplicationDispatcher invoke

2021-11-10 11:12:13.794453500 SEVERE: Servlet.service() for servlet action threw exception

2021-11-10 11:12:13.794453500 java.lang.NullPointerException

An unknown exception occurred executing Validator com.atlassian.jira.workflow.SkippableValidator@130d55: root cause: java.lang.NullPointerException

What to do if Navigator produces a 500 error page in JIRA

According to our Support Engineers, this error is due to deleting the simplified workflow without moving all the associated issues to the project to a new project. Furthermore, the status of these issues is stuck in the “To Do, In Progress, Done” status.

However, the statuses no longer exist after deleting the project key association. Thereby, resulting in the 500 error page.

Fortunately, our team of skilled Support Techs has come up with an innovative solution that involves bulk editing the status of these issues.

1. First, we will head to View All Projects under Projects.
2. Then, we have to select the project causing the error.
3. Next, we will select Issues in the Summary section.
4. Finally, we have to click All Issues in order to be able to perform a bulk edit.

[Need for a solution to another query? We are just a click away.]

Conclusion

In essence, the skilled Support Engineers at Bobcares demonstrated what to do when the Issue Navigator produces a 500 error page in JIRA.

Dashboard error gadget.common.error.500

after all the updates on the way from JIRA V6.1 to JIRA V8.4 I got an error on the dashboard of the activity stream gadget » gadget.common.error.500″.

Also this error I found in error.log:

2019-09-11 09:00:58,224 http-nio-8080-exec-11 ERROR jira_admin 540x632x2 1jmz0yk /plugins/servlet/gadgets/makeRequest [c.a.g.r.internal.http.HttpClientFetcher] Unable to perform a request to: https:// /jira_neu/rest/webResources/1.0/resources

SSL certificate is signed and imported correctly in Apache.

Whats going wrong here?

2 answers

1 accepted

Sorry to hear you are facing a problem.

Per the description of your error, it seems that you are being impacted by the problem mentioned in the article below:

basically, an invalid or absence of a certificate can lead to such errors. Could you please double-check if you are using the correct certificate? Also, check if the correct baseUrl is set in the System -> General Configuration.

If that’s not the problem, I checked another customer facing the same problem after configuring direct SSL with self-signed certificates in JIRA 8.0.1 tomcat. As you can see in this thread, he managed to fix it by adding his 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 -validity 3650
keytool -importkeystore -destkeystore cacerts -srckeystore /opt/certs/keystore.p12 -srcstoretype pkcs12 -alias ca -deststorepass changeit -srcstorepass -validity 3650

Let me know if those suggestions work for you.

Источник

gadget.common.error.500 using nginx and HTTPS

Hello, I recently installed Jira 8.2.0 on a RHEL8 server and I’m with issues about gadgets on System Dashboard.

It appears to be an widespread problem:

I gone through all those topics and tried everything, even mimicking configurations, but I wasn’t able to solve this issue by myself.

So I’m here for help.

Here’s my configurations:

I tried adding the web certificates to the keystore located on /opt/atlassian/jira/jre/lib/security/cacerts and it doesn’t solved the issue too.

And yes, my base URL is set to: https://jira.domain.tld.

Thanks for your help.

4 answers

1 accepted

I solved this changing the JRE to the system JRE instead of the shipped JRE. Everything worked flawlessly after the change.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

I did not understand the change you made. Do you have any step-by-step instructions?

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.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

I have exactly the same config and problem. Has anyone managed to solve it? I’m using F5 to avoid loading the certificate into the Jira application.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Hi! I have exactly the same config and problem.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

@Polybio FernandesDid the guide solve your problem? After upgrading I am having the same issue. 🙁 Other than that, Jira does work flawless. Just having that gadget URL error.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

This may be because the update has replaced the «server.xml» file for the default settings.

Mine resolved as follows:

For SSH, enter the / opt / atlassian / jira / conf folder
# vi server.xml

1) Comment all jira configuration block DEFAULT:

2) Enable the HTTPS block settings as example remembering to enter the domain name of your certificate that is in F5 in the «proxy name».

If you’re proxying traffic to Jira over HTTPS, uncomment the below connector and comment out the others.
Ensure the proxyName and proxyPort are updated with the appropriate information if necessary as per the docs.

See the following for more information:

«
maxThreads=»150″ minSpareThreads=»25″ connectionTimeout=»20000″ enableLookups=»false»
maxHttpHeaderSize=»8192″ protocol=»HTTP/1.1″ useBodyEncodingForURI=»true» redirectPort=»8443″
acceptCount=»100″ disableUploadTimeout=»true» bindOnInit=»true» secure=»true» scheme=»https»
proxyName=»jira.domain.com» proxyPort=»443″/>

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Источник

gadget.common.error.500 LAN DNS no https

Just launched self-hosted Jira instance. Get gadget.common.error.500 on the project summary page when I access the site from via the DNS route I set up, but not when I use the virtual machine IP address.

Setup (ips changed for security reasons):

VM Ubuntu 18.02-LTS Server with .bin installation of Jira/Confluence (10.0.0.2 for example)

VM Windows Server 2016 running DNS Server (10.0.0.3 for example).

—DNS ResourceRecordA -name jira.company.local -IPv4Address 10.0.0.2

In Jira, set baseURL to jira.company.local or jira.company.local:8080 and access via browser address (see note, jira.company.local port forward not working)

-Site works fine besides the gadget problem.

In Jira, set baseURL to 10.0.0.2 or 10.0.0.2:8080 and access via browser address (see note, jira.company.local port forward not working)

-Site works fine besides the gadget problem.

*Temporarily solving problem:

In Jira, set baseURL to 10.0.0.2 or 10.0.0.2:8080 and access via browser address (see note, 10.0.0.2 80 to 8080 port forward not working)

**Couple problems also arise

Port forwarding in the Tomcat server doesn’t seem to be working. I must create shortcuts for LAN users using :8080 port (Jira) or :8090 (Confluence). Maybe I need to set explicit traffic redirection in Ubuntu?

When accessing via jira.company.local, some features don’t work (adding comment gives stream error)

https has NOT been enabled yet while testing. No certificate present.

1 answer

1 accepted

Since you do not have a port forwarding and there is no proxy or web server in front of your JIRA and Confluence application servers, the best way is to set up base URL for JIRA as,

This way the incoming requests will hit your application server on the respective port (i.e 8080). I understand with this in place, the site works fine besides the gadget problem. You may have to now conquer the issues with gadgets. Check the logs and see what errors are throwing with respect to gadgets.

Do the application links set up correctly and working between JIRA / Confluence? Please see below link for further help.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

I think, since the gadgets use a REST API, we just need to enable reverse lookups on company.local and the gadgets should work.

Confluence would not talk to Jira or vice versa via lookup using LAN IP addresses or fqdn. They are hosted on the same VM, though (so same IP). What did work was localhost:8080, localhost:8090 (127.0.0.1:8080 and 127.0.0.1:8090).

We have multiple intranet web applications. We’ll examine a few options.

One, I think, is having windows server portproxy all traffic to jira.company.local:80 to jira.company.local:8080 and confluence.company.local:8090. Not super excited about that as windows portproxy doesn’t have an allowupdate parameter, but that’s ok. Should be static for our use case.

Another is adjusting IP tables in the ubuntu VM hosting the application:

But, then I can’t host both applications on the same VM. This is Ok. but I really don’t want to deal with two databases for effectively the same package. So we’ll need spin up ANOTHER container to run postgresql. I’m hoping I can figure out portproxy or create some kind of inner redirect.

Источник

gadget.common.error.500

I am runing Jira out of a docker container on my Synology NAS.

The NAS uses an SSL certificate from Let’s Encrypt.

In the System Dashboard Gadgets are not shown, instead there is a

I read about importing the certificate somehow but I only have basic Linux knowledge. Is there a fix for this?

1 answer

1 accepted

I would run through https://confluence.atlassian.com/jirakb/gadgets-failing-to-load-in-jira-server-behind-a-proxy-218276785.html just to check that it is SSL related and not one of the other possible causes of that error.

For what it’s worth, I can tell you that Letsencrypt certificates can work fine, I run some Atlassian stuff at home with them. My usual trick is forgetting to import the client certificate into the jvm keystore on upgrade (System information page does not list that as a changed file, otherwise I’d remember)

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

thanks for your hint.

In the jira logs I could confirm an SSL error.

I could import the unsigned certificate of my NAS.

After a restart of the docker container the gadgets now work fine.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Источник

gadget.common.error.500

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 -validity 3650
keytool -importkeystore -destkeystore cacerts -srckeystore /opt/certs/keystore.p12 -srcstoretype pkcs12 -alias ca -deststorepass changeit -srcstorepass -validity 3650

BTW Confluence 6.14 does not have this problem and works without this configuration.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Have not tried this out but makes sense, thanks!

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

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

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

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.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

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.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

Yes, I can see the certificate:

]# 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.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

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:

the command identical to Mindaugas

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.

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

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

You must be a registered user to add a comment. If you’ve already registered, sign in. Otherwise, register and sign in.

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 $ is the DNS name of the load balancer);

Источник