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?

GioMac
  • 4,444
  • 3
  • 24
  • 41
  • Typically LDAP over SSL is done over port 636, which port is your client trying against? – SpacemanSpiff Jul 04 '12 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 04 '12 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 04 '12 at 17:13
  • Hopefully someone familiar with 389DS can chime in, but surely both server and client keep logs? – SpacemanSpiff Jul 04 '12 at 20:01
  • ixe013: 389 side looks fine: server is answering with public certificate and proposing TLSv1 – GioMac Jul 06 '12 at 12:22
  • Note, that certificate is accepted in logs, but during authentication of any user - at least got delay. TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server certificate request A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client certificate A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read finished A – GioMac Jul 09 '12 at 13:11
  • 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 '12 at 08:19
  • "389 side looks fine: server is answering with public certificate and proposing TLSv1" - that's a config problem. It should not be offering TLS on port 389. Port 389 is for ldap while 636 is for ldaps (ldap through TLS/SSL). Do you mean something by 389DS or is that just a way of writing ldap running on port 389? – Ram Jul 10 '12 at 21:16
  • Ram. nss-ldaps (389 Directory Server) is running with TLS on 636, but still, seems like there IS a problem related with certificates. I tried all RHDS-specific manual, but no success - thins are changed in 389. – GioMac Jul 11 '12 at 21:37
  • Are you saying it is not listening with TLS on 389? In any case the easiest way to ensure that your certs are setup right is to use a webbrowser (say firefox) to connect to the service... just point your web browser at https://host:636 ; if you get a successful connection (click to view the cert) that the SSL/TLS stuff is fine otherwise it is not. – Ram Jul 12 '12 at 22:52

3 Answers3

8

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>
Univ426
  • 2,139
  • 14
  • 26
  • 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 '12 at 08: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 '12 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 '12 at 17:34
  • Isn't this guy on Fedora or something and certutil an MS proprietary tool? – Ram Jul 10 '12 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. http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/Managing_SSL-Using_certutil.html – Univ426 Jul 11 '12 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...

quadruplebucky
  • 5,041
  • 18
  • 23
  • 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 '12 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 '12 at 07: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.

atvt
  • 444
  • 4
  • 11
  • Thanks, will check for LDAP sever next time. Goal was achieved with FreeIPA, but for 389 I still couldnt run LDAPS. – GioMac Aug 26 '12 at 19:14