upgrade old confluence
Asked by Eugene Chu:

I need to upgrade confluence 5.3.4 to deal with the recently announced security problems with webdav and web connector. What is the latest version I can upgrade to directly from 5.3.4.

Do I need to upgrade Jira at the same time?


Answers:
author: Daniel Eads
body: Hey [@Eugene Chu](/t5/user/viewprofilepage/user-id/723338) ,

As Petr mentioned, the plugin compatibility checker is a very helpful tool as it will check all your installed plugins for compatibility with newer versions of Confluence by fetching their most recent version information from Marketplace. It is accessible from the admin panel:

1. From the top navigation bar in your application, choose ![](https://confluence.atlassian.com/upm/files/624034373/957494777/1/1536557922045/cog.png)**\> Add-ons** or **Manage apps**.
2. Click **Confluence update check** from the bottom of the page.

[More info on the compatibility checker is here](https://confluence.atlassian.com/upm/checking-app-compatibility-with-application-updates-273875705.html) if you're interested in reading up.

Cheers and best wishes for your upgrade,  
Daniel

comments: author: Eugene Chu
body: Thank you Danial, Petr,

I have copied my Confluence installation onto another host and was able to bring it up, sort of. I need to get my users onto this server instance so they can check it out, but I can not log into it with anyone other than the local admin account I had set up.

I checked the LDAP settings (under User Directories -\> which I had been using on the original server, and there were no errors from the copy. But when I try to test the LDAP connection, I get:

++LDAP_SERVER:636 nested exception is javax.naming.CommunicationException: LDAP_SERVER:636 \[Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target++

I thought maybe this was caused by my copying the host SSL certs and keys from the old server, so I generated new versions for this new host, but that did not help.

I tried various solutions on the Atlassian web site that addressed the above error messages, but they did not help either. So now, I seek assistance from those with more experience.


author: Daniel Eads
body: We typically see this error when your LDAP servers / domain controllers are using self-signed certs or certificates issued by a provider like GoDaddy which may not be in the Java trust store.

The fastest way to address this (so you don't have to change things on the LDAP server side) is to import the certificate into the trust store in the Java that Confluence is using to run. [We've got an article explaining how to do that here for various operating systems](https://confluence.atlassian.com/kb/how-to-import-a-public-ssl-certificate-into-a-jvm-867025849.html).


author: Eugene Chu
body: Thank you Daniel,

The new host references its Java truststore in /etc/pki/java/cacerts, and that was one of the things I tried; updating it with the new self-signed certs I got from our institutional cert server. That did not help. In addition to the PKIX error messages, I'm also getting these from the LDAP test function:

++Test user rename is configured and tracked : Not performed++

++Test get user's memberships : Not performed++

++Test retrieve group : Not performed++

++Test get group members : Not performed++

++Test user can authenticate : Not performed++

Maybe they're all just a result of not being able to connect to our LDAP server.


author: Daniel Eads
body: Yes, I can confirm that those tests failing are the result of the initial SSL connection not being trusted.

From the System Information page in Confluence, can you check what it's got listed for **JAVA_HOME**? That's the path Confluence thinks it's using as its JRE, and if it's something like ".../confluence/jre/bin" then it's using the java that came bundled with the Confluence installer rather than your system java. If this is the case, the keystore path is local to the Confluence install directory rather than the system path you listed.

Outside of that, we have some[generic java SSL troubleshooting steps on this article](https://confluence.atlassian.com/applinks/ssl-and-application-link-troubleshooting-guide-790632063.html). This definitely sounds like a trust issue, so the next step might be using openssl on the Confluence server to see what certificate is returning from the LDAP server and make sure it matches the certificate you're trying to install. This would help you find any firewalls in the way that might be trying to rewrite the connection with a different certificate. You can run this command (updating your server address) from the Confluence server to see what certificates are being sent to Confluence:

```
openssl s_client -connect yourLDAPserver:636
```


author: Eugene Chu
body: Thank you Daniel, we've finally solved our problem.

First, the old server was using a custom version of Java, where all the CA certs were stored. I did not know this when I copied confluence to the new host, which was running the default java installed with CentOS. I thought I needed to update its CA certs, so I requested one from our SSL server. It turned out that we needed that custom java that we had built, and it also had the CA cert file that contained actual Certificate Authority listings, which the other files I got did not.

So running the correct version of java, with the correct CA certs file, finally allowed our confluence to talk to our LDAP server.

Thanks to all for your assistance.


author: Eugene Chu
body: Now I face part 2 of the upgrade. From above, I was able to create a copy of my confluence server on another host, apply the upgrade to 6.15.2, and got my users to verify that everything was working. So I deployed it on our production system. Now the users say the upgraded production system is not supplying the functionality of the plug-ins: "Send email to page" and "Team Calendars". I also noticed that my 3rd purchased plug-in, "Play SQL spreadsheets", is also not being enabled.

I tried to follow the plug-in checking instructions on this page:

<https://confluence.atlassian.com/upm/checking-app-compatibility-with-application-updates-273875705.html>

But I do not see the option for "**(Product name) update check**" on the bottom of the page as instructed. Is there something that has to be enabled to see this?

The catalina.out shows this message:

22-Apr-2019 21:20:20.763 WARNING \[ContainerBackgroundProcessor\[StandardEngine\[Standalone\]\]\] org.apache.catalina.valves.StuckThreadDetectionValve.notifyStuckThreadCompleted Thread \[http-nio-8090-exec-7\] (id=\[240\]) was previously reported to be stuck but has completed. It was active for approximately \[179,232\] milliseconds.

thanks for any help you can provide


author: Petr Van??ek
body: Hi,

as you can see in documentation (<https://confluence.atlassian.com/doc/upgrading-confluence-4578.html#UpgradingConfluence-Planyourupgrade>) you can upgrade to latest version (if you have valid maintenance), but be carefull regarding plugins.

First check compatibility with UPM (CONFLUENCE-DOMAIN/plugins/servlet/upm/check?source=manage) if therr will be some incompatible plugin for latest version try one version before or something like that or check Atlassian Marketplace if plugin is still in development.

Then take backup and try it in test environment. If everything will be ok on test then upgrade your production.

You don't need upgrade Jira in same time, but why don't do it. :-)

comments: author: Eugene Chu
body: Thank you Petr for your answer. I'm not sure how to do this check:

"CONFLUENCE-DOMAIN/plugins/servlet/upm/check?source=manage"

Is that from the confluence administration console?

I am running a couple of add-ons:

#### Play SQL Spreadsheets {#toc-hId--740983619}

#### Send EMail To Page Plugin {#toc-hId-1746529214}

#### Team Calendars {#toc-hId--60925249}

So I will have to check with their authors to see if their plugins will work in the latest version of confluence.

Sorry for the late response, but we are handling an incident with our instrument on the ISS, and I may not be able to devote my full attention to this update for a few days.

Eugene Chu


Tags: atl-confsec