Jira server Base URL health check fails
This article only applies to Atlassian's server products. Learn more about the differences between cloud and server.
After upgrading to JIRA 7.1 or newer versions, gadget titles start showing as
__MSG_gadget.filter, and so on as per the example below:
Understanding the Results
What this means
JIRA is able to access itself through the configured Base URL
Your dashboard gadgets should be generated and loaded correctly.
||JIRA is not able to access itself through the configured Base URL. This is necessary so that dashboard gadgets can be generated successfully. Please verify the current Base URL and if necessary, review your network configurations to resolve the problem||
Your dashboard gadgets may not be loading properly. Please follow the diagnosis and resolution steps below to resolve the problem.
- Affects JIRA 7.1.x instances.
- iptables has been configured to forward packets from 80 to 8080 and/or 443 to 8443
- From the JIRA server itself, try curl -v <baseurl> to verify if JIRA is able to communicate with itself.
- Run SSLPoke from the JIRA server itself and see if it returns successfully.
- Additionally run the httpclienttest from the JIRA server itself to confirm if the SSL configuration is okay, as this will verify if you're affected by - JRA-47568Getting issue details... STATUS .
- There are application links configured on the instance but they seem to be having some issue.
- As the symptoms for both environments are different, diagnosis and resolution steps are segregated into multiple sections below.
When accessing the Dashboard, the gadgets serves a response which is processed by the client (ie the browser) to generate gadgets. Whilst this happens, the server also connects to itself to provide the gadget's translated strings. JIRA uses the URL the instance is connected to, so the JIRA instance needs to be able to access itself.
- User sends request towards JIRA on loading the Dashboard
- JIRA will perform a call towards itself, through the gadget URL.
- JIRA reply with the completed page + gadget's translated strings
1. User sends request towards JIRA on loading the Dashboard
2. Proxy forwarded this request to JIRA
3. JIRA will perform a call back to itself through the gadget URL to get the gadget's title. Performing request to Proxy
4. Proxy forwarded this request back to JIRA itself to provide the gadget's translated strings
5. JIRA replies gadget's translated strings to proxy
6. Proxy forwarded this accordingly to JIRA
7. JIRA replies with the completed page to proxy
8. Proxy forwarded this accordingly to use
If it's not able to do so this error will occur. Some known causes are:
- Basic or certificate-based auth on a proxy layer that JIRA is behind
- The domain name is not resolvable
- JIRA is served on an IP that's in a separate restricted subnet to the server JIRA is running on
- JIRA is served with a self-signed certificate that doesn't exist in its own trust store
- There are more than 3 redirects between the entry point and the final JIRA server (this is tested in the base URL check and also configured in our gadgets).
The recommended best practice is to have JIRA served on one domain name only. This can have different IPs (for example internal and external) configured by different DNS, however will only resolve to one domain. For example https://jira.atlassian.com has an external IP of
188.8.131.52 (mapped to by external DNS) and an internal IP of
192.168.1.2 (mapped with an internal DNS). It has one certificate for that FQDN, and all users access it on that domain only.
Additionally, there are some environmental-specific causes to this problem. Please see below for further information.
Cause 1: Jira applications with SSL Configured
The following appears in the
2016-02-26 14:22:28,843 http-bio-8443-exec-11 ERROR admin 862x395x1 m32d6k xx.xx.xx.xx /secure/MyJiraHome.jspa [c.a.g.r.internal.http.HttpClientFetcher] Unable to retrieve response 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 at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)Cause
This is a known problem issue the certificate is not trusted by the Java trust store.
If using SNI on the certificate, we have an open bug for this being tracked under - JRA-47568Getting issue details... STATUS . A fix for this bug is present in JIRA Core 7.1.6 and above. Currently the most simple workaround for this issue is to use a non-SNI SSL certificate for your JIRA instance. You can confirm if you are affected by this bug by using httpclienttest in conjunction with the SSLPoke tool linked below. If theSSLPoke test works without error and thehttpclienttest reports an exception, you are experiencing the bug as above.
- Follow our instructions in our Unable to connect to SSL services due to "PKIX Path Building Failed" error knowledge base article to resolve the problem.
Additionally verify the configuration with httpclienttest as described in the readme of that repository.
Cause 2: JIRA Applications with port forwarding configured
Applies to environments that are using port forwarding, such as iptables:
If iptables has been configured to forward packets from 80 to 8080 and/or 443 to 8443, you may see gadget titles be broken and show as
__MSG_gadget.xxxxxxx. This can happen if the rules are configured only to forward packets from external sources.
You need to create a rule both for packets coming froman external IP sourcesAND for local packets eg.
iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-ports 8080
Cause 3: Jira applications with a broken Proxy configuration
Applies to environments configured to use a Web Proxy. This can be determined by checking the "JVM Arguments" in the
atlassian-jira.logforan existing proxy configurations.
JIRA is unable to communicate with itself due to a Web Proxy not able to correctly resolve the JIRA Server.
Add the JIRA Server's hostname to the
-Dhttps.nonProxyHosts arguments as in Configure an outbound proxy for use in Jira server.
Make sure that the same domain is not being mentioned twice in an argument, e.g.
.nonProxyHosts = jira|confluence|jira
Cause 4: JIRA configured with Apache in front with BasicAuth password restriction
JIRA is unable to communicate with itself due to a Web Proxy requiring authentication.
Add the Server IP itself for access without password:
Allow from <hostname>
If using Shibbolethauthentication ,
- leave the /rest URLs outside theshibbolethauthentication.
- /rest URL must not be shibboleth protected.
- Example :
<LocationMatch "^(/rest)/[^/]+"> AuthType None Require all granted </LocationMatch> <LocationMatch "/"> AuthType Shibboleth ShibRequireSession On require valid-user ShibUseEnvironment On Order allow,deny Allow from all </LocationMatch>