Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
Typically LDAP over SSL is done over port 636, which port is your client trying against? –  SpacemanSpiff Jul 4 '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 4 '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 4 '12 at 17:13
    
Hopefully someone familiar with 389DS can chime in, but surely both server and client keep logs? –  SpacemanSpiff Jul 4 '12 at 20:01
    
ixe013: 389 side looks fine: server is answering with public certificate and proposing TLSv1 –  GioMac Jul 6 '12 at 12:22
show 5 more comments

4 Answers

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>
share|improve this answer
    
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 8:19
    
Cool, narrowing it down - So you're trying to generate self-signed certificates? Or did you purchase one from a larger CA? –  John K 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. –  John K 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. docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.1/html/… –  John K Jul 11 '12 at 13:01
add comment

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...

share|improve this answer
    
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 7:59
add comment
up vote 0 down vote accepted

Probably a better way is to use FreeIPA.

share|improve this answer
    
Done with FreeIPA. –  GioMac Jul 25 '12 at 11:04
    
FreeIPA is good till you dont want to add custom schema. Adding custom schema is not supported by FreeIPA community & Red Hat. –  atolani Nov 15 '12 at 13:28
add comment

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.

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.