7

I've got 389 Directory Server running on RHEL 5 with groups, users, posix etc. RHEL clients are authenticating users with LDAP - no problems, everything works perfect, but passwords are sent in plaintext and are visible with network sniffer. So, decided to run with SSL:

  1. Created CA - got both private and public CA certificates
  2. Using CA certs: generated both of private and public certificates and combined (1st file) for 389DS according to 389DS certificate request, imported with CA public cert to 389DS from graphical console (2nd file).
  3. Enabled SSL in 389DS
  4. On the client, using authconfig-gtk enabled SSL for LDAP, specified only CA public certificate

Doesn't work.

Howto? What is the best way to integrate safely?

Improve this question
10
  • Typically LDAP over SSL is done over port 636, which port is your client trying against?
    – SpacemanSpiff
    Jul 4, 2012 at 14:25
  • Sure it's 636. The question is why SSL handshake won't work, what is wrong, how it should be done and why CA public key is enough.
    – GioMac
    Jul 4, 2012 at 15:10
  • 3
    You can check your ssl configuration with this : openssl s_client -connect fqdn.of.the.ldap.server.or.ip:636. The server should answer back with the certificates. If not, there is a problem with your server's configuration. Update your question with the results.
    – ixe013
    Jul 4, 2012 at 17:13
  • Hopefully someone familiar with 389DS can chime in, but surely both server and client keep logs?
    – SpacemanSpiff
    Jul 4, 2012 at 20:01
  • ixe013: 389 side looks fine: server is answering with public certificate and proposing TLSv1
    – GioMac
    Jul 6, 2012 at 12:22

3 Answers 3

Reset to default
8
+100

The first thing you may want to do is check that your server is presenting it's certificates properly. You can do this by trying to connect to your server using OpenSSL. On a client machine with access, run:

openssl s_client –connect target_server_fqdn:636

This should return a nice print out of the server's certificate. The key here is checking the "Verify return code" printed at the end. You may get different codes, but generally speaking, you should get 0 for a valid certificate, and possibly 19 if you're self-signing.

If this fails, go back and check to ensure you have imported your server side certificates properly.

If you've passed this test, move on to testing your TLS connections from the client side.

On a client machine, run

ldapsearch -z -ZZ '(uid=<testusername>)'

This will force an LDAP lookup over an encrypted connection. If that's successful, you should get some user information back, and a check into the DS logs should yield the following:

[23/Sep/2011:07:48:57 -0500] conn=1631 op=0 EXT oid="X.X.X.X.XX.X.XX" name="startTLS" [23/Sep/2011:07:48:57 -0500] conn=1631 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [23/Sep/2011:07:48:57 -0500] conn=1631 SSL 256-bit AES

If this fails, you'll want to ensure the certificates were properly imported on the client side.

When troubleshooting, some common areas I've found myself looking frequently are:

1.) On the clients, in some cases (which someone here may be able to better explain), you might try to require signing by editing ldap.conf and including the line

TLS_REQCERT allow

2.) If the authentication GUI is giving you problems, you might try just explicitly turning on TLS for LDAP with

authconfig --enableldaptls --update

I've had problems with the GUI before, so I tend to stick to using CLI commands.

3.) And a final thing you might try (again , just for testing), is calling 

cacertdir_rehash <dir where certs are stored>

Update

If you're looking for more help in actually creating self sign certificates, try the following:

1.) Create your own, self-signed CA Certificate:

certutil -S -n "<CA Certificate Name Here>" -s "cn=<CN Name Here>, dc=<Your DC's FQDN>" -2 -x -t "CT,," -m 1000 -v 120 -d . -k rsa

2.) Create a server certificate for the directory server

certutil -S -n "Cert-Name" -s "cn=<Server FQDN>" -c "<Name of CA Certificate>" -t "u,u,u" -m 1001 -v 120 -d . -k rsa

3.) Import both of these certificates into the directory server in the "Manage Certificates" section, selected under "Tasks"

4.) Enable TLS encryption

5.) Create an exportable certificate for clients and output it to a .pem file

certutil -d . -L -n "<CA Certificate Name>" -a > cacert.pem

6.) By means of your choosing - download the client certificate onto each client.

7.) Rehash the certificates by using the previously mentioned command

cacertdir_rehash <dir where certs are stored>
Improve this answer
5
  • Looks like server certificates are still not properly generated, also, seems like format has changed. I tried to generate and import certificates with howto's I've found, but no success.
    – GioMac
    Jul 10, 2012 at 8:19
  • Cool, narrowing it down - So you're trying to generate self-signed certificates? Or did you purchase one from a larger CA?
    – Univ426
    Jul 10, 2012 at 13:01
  • If you want, I can update my answer with the process I've used to create certificates using CertUtil, hopefully that will help.
    – Univ426
    Jul 10, 2012 at 17:34
  • Isn't this guy on Fedora or something and certutil an MS proprietary tool?
    – Ram
    Jul 10, 2012 at 21:14
  • Think he said he's on RHEL5. I think MS has a build of certutil too, might be the same thing, might be different, but I know that certutil comes packaged with Directory Server and we use it on our RHEL systems. docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.1/html/…
    – Univ426
    Jul 11, 2012 at 13:01
2

I had no luck configuring SSL for the 389 directory or admin servers following the howtos I found (I figured it was because I was using Centos 6, and most of the howtos targeted Redhat specifically).

What finally worked for me was to initiate cert requests from the 389-console (admin|dir) server interfaces, sign these reqs with a tinyCA installation (just a frontend to openssl, I'm lazy), export the signed PEM certs and CA certs, and import those back using 389-console.

389 console -> Server Group --> (admin/directory) server -> Open -> Manage Certificates

Hope this helps...

Improve this answer
2
  • Thanks for post: Same here... I tried all the howtos and manuals, but these are targeting RHDS, not 389 (there IS a difference). I'll try tomorrow to generate certificates same way and reply back.
    – GioMac
    Jul 11, 2012 at 21:34
  • tinyCA is a good thing (c). I've created CA, exported CA certificate, imported into 389DS, created request with 389DS, imported request certificate into tinyCA, signed request with tinyCA, created server certificate using this request, exported and then imported into 389DS, created client cert, exported and copied to certificate directory of client, also copied cacert too. No luck. All options were default. So, I've got cacert and server cert in 389DS, also cacert and client cert in openldap. Any tip?
    – GioMac
    Jul 13, 2012 at 7:59
0

Could you use below link to setup RHDS/389-ds on SSL.

http://lists.fedoraproject.org/pipermail/389-users/2012-March/014200.html

Hope that helps.

Improve this answer
1
  • Thanks, will check for LDAP sever next time. Goal was achieved with FreeIPA, but for 389 I still couldnt run LDAPS.
    – GioMac
    Aug 26, 2012 at 19:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .