Active Directory SSL failures

...

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

...

• You've forgotten the admin user's password because it was so long ago.
  • If so, see reset a user password in the database..
• The 'Internal' directory has been disabled, or there is an identically named user (here, admin) in AD/LDAP, and the AD/LDAP directory is configured to be checked before the Internal directory.
  • In this case youll you'll need to reorder your user directories.

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