Confluence Documentation

Confluence 4.1.x
Confluence 4.0.x
Confluence 3.5.x
Confluence 3.4.x
More...

Search the Knowledge Base and Documentation Spaces

Browse Content

You're visiting the Confluence Knowledge Base. Visit the Confluence Knowledge Base Home for an overview.

Skip to end of metadata
Comment: subjectAlternativeName support is not actually a Confluence bug
Go to start of metadata

Symptoms

When Connecting to LDAP or JIRA or Other Services via SSL or Setting Up Trusted Communication between JIRA and Confluence, you must import the cert into your keystore. If this hasn't happened, the following error appears in the logs:

(info) This is different from adding SSL to your server.

Cause

The cert from the keystore does not match the cert from the server.

If are using a Subject Alternative Name (SAN) record in the certificate to apply to your server, then you have probably hit this Java bug: 6668231. Upgrading to the most recent Java version should help, or alternatively you can use a certificate that contains the approrpiate server name in the Common Name (CN) field.

Resolution

  1. Make sure you have imported your certificates into the keystore accoring to the Connect to LDAP or Other Services Via SSL instructions.
  2. Make sure any certificates have been imported into the correct keystore; you may have multiple JDKs. See Installing Java for Confluence.
  3. Check to see that the correct keystore is in use. It should be in your JDK, not your JRE. Make sure the system is picking up the correct JDK. Try echo %JAVA_HOME% (Windows) or export $JAVA_HOME (Linux), and compare it to the value shown in Administration >> System Information.
Still having problems?

Try SSLPoke to see if your keystore has the right certificates. It simply connects to a SSL service, sends a byte of input, and watches the output.

  1. Download SSLPoke.class. Note the (source) is useful for debugging.

  2. Run 'java SSLPoke localhost 443' for instance, connecting to a local HTTPS server on port 443 (the HTTPS default) with a untrusted (self-signed) certificate. You should see:

  3. To connect to a CA-verified certificate, run:

  4. Move now to test port 636 for LDAPS connections.

    1. Make sure that the version of Java you are using is the same as that used in your production Java application

      On Linux systems
      On Windows systems

    2. Check for the presence of a -Djavax.net.ssl.trustStore parameter. If -Djavax.net.ssl.trustStore is present in the command, this may well be the cause of your problems. You can verify whether the -Djavax.net.ssl.trustStore parameter is causing problems by running the SSLPoketest utility above with it, eg:

    3. If this fails (confirming the problem), the solution is to remove the -Djavax.net.ssl.trustStore parameter, import your custom keystore certificates into the main keystore with keytool -importkeystore -srckeystore /my/custom/keystore -destkeystore $JAVA_HOME/jre/lib/security/cacerts, and restart the application.
    4. If you are sure the certificate is trusted and found by Java, and you are having low-level SSL problems, you can get debug information in the stdout logs by setting the -Djavax.net.debug=all property.
Still having problems after that?

A copy of Andreas Sterben's original blog describes a process for importing the certificates automatically. The source is are attached to this page. To use it:

  1. Download the source.
  2. From a command line prompt, cd to the directory where you downloaded the source.
  3. Run 'javac InstallCert'. Make sure java is on your path. See Installing Java for Confluence.
  4. Run 'java InstallCert'. Check the response and add the correct destination.

Add your vote to have Confluence detect SSL certificates automatically.

Related Content

Help us improve!
Is this article helpful?
Is the content complete?
Is it well written?

 

 

 

 

 

 

 

 

 

 

 

Labels:
Edit Labels

8 Comments

Hide/Show Comments

  1. Jun 30, 2010

    Vincent Choy [Atlassian]

    If issue happens from Confluence Administrator Console -> Plugin Repository,

    The SSL certificate to add to the key chain is: https://studio.plugins.atlassian.com

  2. Nov 04, 2010

    Brendan Patterson

    The current version of Java1.6_x on Linux seems to expect the cacerts file to live in:

    $JAVA_HOME/jre/lib/security
    not
    $JAVA_HOME/lib/security

    That threw me, but this page and SSLPoke saved me - thanks for writing it!!

  3. Feb 09, 2011

    Shrike

    Section "Still having problems?" isn't clear:
    p.4
    "Move now to test port 636 for LDAPS connections". What is it about?
    b. "Check for the presence of a -Djavax.net.ssl.trustStore parameter. " - check where?

    1. Aug 31, 2011

      Greg Redl

      This article should help you locate the startup parameters - http://confluence.atlassian.com/display/JIRA/Setting+Properties+and+Options+on+Startup

  4. Aug 31, 2011

    Greg Redl

    Excellent article.

    Where exactly am I saving the SSLPoke.class file to so that I can run the listed commands?

  5. Sep 01, 2011

    Greg Warner

    The link to Andreas Sterben's article is no longer valid.

    1. Sep 07, 2011

      Jeremy Largman [Atlassian]

      Thanks. It got moved when Oracle took over. I've update the page.

  6. Dec 07, 2011

    Fujitsu Karlskrona

    We found that adding the cert from https://studio.plugins.atlassian.com wasn't enough

    We had to add the cert from https://plugins.atlassian.com as well

    I got the certificate using
    openssl s_client -connect plugins.atlassian.com:443

    I added the certificare info to a file and imported to both my confluence user's private keystore and java's keystore
    keytool -import -alias plugins.atlassian.com -file confPluginExch.cer -keystore .keystore
    keytool -import -alias plugins.atlassian.com -file confPluginExch.cer -keystore $JAVA_HOME/jre/lib/security/cacerts