JIRA, Confluence and Lets Encrypt


I recently had to move a JIRA and Confluence environment to a new infrastructure stack. During the move, we also changed the TLS Certificates and instead of using one of the paid-for incumbents we decided to give Lets Encrypt a go.

Everything with the migration went smoothly. The first hurdle we hit was when we were checking the Application Integration between the two systems. The integration wasnt functioning and no amount of delete, change, recreate would fix it. The admin pages in JIRA and Confluence were both reporting SSL errors. When I dug into the actual Tomcat logs for each instance, the following errors were appearing:


Caused by: 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


Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification
path to requested target

Some quick googlephoo found a few items on the internet about this, not specific to JIRA and Confluence though.



The root cause of the problem is that the JRE thats included with our version JIRA and Confluence is too old and doesn’t include the Lets Encrypt root keychain in its included keystore. The above articles had references and code snippets to help get the Lets Encrypt certificates into the JRE keystore but they were all very ugly.

Its worth mentioning that Oracle JAVA JRE 1.8.0_101 DOES include the Lets Encrypt certificates.

Options at this point were:

  • Find a way to get the required certificates into the JRE keystore (the CLI method to do this is described in the Lets Encrypt community post above).
  • Install a new JRE on the servers and make JIRA and Confluence work with that. Most likely putting us out of support with Atlassian.
  • Find out if current JIRA and Confluence include the required JRE version and then upgrade JIRA and Confluence. This would need another round of testing to properly do the upgrade.

Moving to unsupported configuration was undesirable and I didnt have the time to properly dive into a new round of testing to see if newer JIRA and Confluence had the required JRE version. I did look for some detail on the Atlassian pages to determine the answer to this and wasn’t able to locate anything.

What I did find on an Atlassian page was this article https://confluence.atlassian.com/kb/unable-to-connect-to-ssl-services-due-to-pkix-path-building-failed-779355358.html which shows how to use a free JIRA and Confluence plugin to get third party root certificates into the JRE keystore using a simple web page GUI. Some small CLI steps (a cp) are still required after the plug-in does its thing but it does make the fix less likely to fail.


TechNet Diskspd Utility: A Robust Storage Testing Tool (superseding SQLIO)


A feature-rich and versatile storage testing tool, Diskspd (version 2.0.17) combines robust and granular IO workload definition with flexible runtime and output options, creating an ideal tool for synthetic storage subsystem testing and validation.

Source: TechNet Diskspd Utility: A Robust Storage Testing Tool (superseding SQLIO)

Combining PTP with NTP to Get the Best of Both Worlds – Red Hat Enterprise Linux Blog


There are two supported protocols in Red Hat Enterprise Linux for synchronization of computer clocks over a network. The older and more well-known protocol is the Network Time Protocol (NTP). In it…

Source: Combining PTP with NTP to Get the Best of Both Worlds – Red Hat Enterprise Linux Blog


Summary of approach to storage queue depth diags and config using UCS and vMAX



Edit a hosts file on Max OS 10.0


Open a Terminal prompt.
Open the hosts file for editing: sudo vi /private/etc/hosts
Flush the local DNS cache: dscacheutil -flushcache;sudo killall -HUP mDNSResponder

Home Internet Monitoring Appliance


My home internet has been pretty flakey of late and I needed a way to monitor the performance of the connection over long periods of time so that I could gather evidence to escalate to my ISP for support and troubleshooting.

Due to the absence of a suitable machine at home to run the tools on I decided to build an Ubuntu VM with smokeping and Cacti. This would allow me to build the environment quickly and then move the VM to a temporary laptop running VMware Workstation at home.

The following steps describe the sequence of events and references I used to complete the work.

When 90% just isn’t good enough.


If you’re a sysadmin and/or consultant you should read this and you will probably identify with what the writer is talking about.

Ill admit I know exactly how he feels. I think it applies to consulting as well. Its all too easy in a consultant role to make basic assumptions about an environment only to find out during implementation that that small assumption you made is very wrong and the whole migration is now bollocksed.

If you’re consulting and you’re making assumptions, call them out and call them out early. Its kinda a design document 101 type rule, they always contain an “Assumptions” section but its there for this reason. Oh and don’t be tempted to copy/paste the assumptions from the last engagement. Its important, do it properly.