Active Directory SSL failures

It's Friday, and JIRA users report being unable to log in. You check the JIRA logs, and find a colossal stacktrace, the relevant bits of which are:

...

Get your friendly Windows administrator to wrestle with AD to fix the cert. I'm told that Atlassian's page (https://confluence.atlassian.com/display/CROWD/Configuring+an+SSL+Certificate+for+Microsoft+Active+Directory) is out-of-date, but perhaps better than nothing.

In the meanwhile, there's things we can do:

1. Ensure we can still log in as a non-LDAP admin user.
2. Either:
   
   1. If an alternative (e.g. replicated) LDAP/AD is available, switch JIRA to using it.
   2. If a non-SSL port 389 variant of LDAP is available, use that temporarily.
   3. Use a SSL-decrypting, expired-cert-ignoring LDAP wrapper using socat

Each of these is discussed below.

Log in via Internal user

When JIRA/Confluence was initially set up, one of the setup steps was to configure an administrator user:

Image Modified

Let's call this the admin user (the actual name will depend on whatever your initial JIRA configurer chose). This admin account should be able to log in regardless of the status of AD/LDAP.

...

Once logged in as admin you'll be able to tweak settings for the User Directories.

Temporary Fixes

Hopefully one of the next three alternatives will be available to you.

Configuring an alternative LDAP

If your AD replicates elsewhere, your job is simple: go to the User Directories admin screen, edit the relevant directory (or add another) and use the replicated AD URL.

If LDAP breaks, it is sometimes useful to use ldapsearch from the command-line to verify queries. See Testing LDAP connectivity with ldapsearch.

Use a non-SSL port 389 LDAP

Your LDAP server may be able to talk unencrypted on port 389 rather than port 636. If your network policy permits. Check that port 389 is open with telnet (and perhaps ldapsearch):

jturner@jturner-desktop ~ $ telnet tx-dc2.corp.example.com 389
Trying 10.0.10.100...
Connected to tx-dc2.corp.example.com.
Escape character is '^]'.

If this works, untick the 'Use SSL' box and try your luck:

Image Added

Use a SSL expired-cert-ignoring proxy

You know the certificate is correct (just expired), and in a better world, JIRA would have an 'Ignore certificate errors' checkbox. As it doesn't, we have to get creative.

The magical socat Unix utility is able to create a localhost proxy LDAP that forwards requests to the real encrypted LDAP, but ignores the certificate errors.

openssl genrsa -out /tmp/client.key 1024
openssl req -new -key /tmp/client.key -x509 -days 2654 -out /tmp/client.crt
cat /tmp/client.key /tmp/client.crt > /tmp/client.pem
chmod 600 /tmp/client.pem
socat -v TCP4-LISTEN:389,reuseaddr,fork OPENSSL:tx-dc2.corp.example.com:636,cert=/tmp/client.pem,capath=/etc/ssl/certs,verify=0

(This command assumes Debian/Ubuntu's /etc/ssl/certs directory of CA certs.)

Then we configure the User Directory to use the proxy:

Image Added