What can I do to troubleshoot this? OpenLDAP client says ldap_simple_bind Can't contact LDAP server but it can resolve the name, ping the server, connect to port 636... and I have no details as to why it thinks it cannot contact the server. Many other clients authenticate to the same server, and I'm using the same ldap.conf, nsswitch.conf, and pam.d/system-auth files.
John Oliver wrote:
What can I do to troubleshoot this? OpenLDAP client says ldap_simple_bind Can't contact LDAP server but it can resolve the name, ping the server, connect to port 636... and I have no details as to why it thinks it cannot contact the server. Many other clients authenticate to the same server, and I'm using the same ldap.conf, nsswitch.conf, and pam.d/system-auth files.
I'd recommend that you provide more information. But before try to test with all needed parameters given on the command-line instead of assuming that a certain ldap.conf is used.
Ciao, Michael.
--On Monday, July 21, 2008 8:30 AM -0700 John Oliver joliver@john-oliver.net wrote:
What can I do to troubleshoot this? OpenLDAP client says ldap_simple_bind Can't contact LDAP server but it can resolve the name, ping the server, connect to port 636... and I have no details as to why it thinks it cannot contact the server. Many other clients authenticate to the same server, and I'm using the same ldap.conf, nsswitch.conf, and pam.d/system-auth files.
I'd note that port 636 is ldaps://, if you are using an ldap:// URL, it is unlikely to be able to connect, because it'll try and use port 389.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Mon, Jul 21, 2008 at 8:30 AM, John Oliver joliver@john-oliver.net wrote:
What can I do to troubleshoot this? OpenLDAP client says ldap_simple_bind Can't contact LDAP server but it can resolve the name, ping the server, connect to port 636... and I have no details as to why it thinks it cannot contact the server. Many other clients authenticate to the same server, and I'm using the same ldap.conf, nsswitch.conf, and pam.d/system-auth files.
Apart from seeing configurations and command lines, I have found the full output of the openssl client to be useful for diagnosing my own ldaps issues: echo | openssl s_client -debug -showcerts -connect SERVER:636 2>&1 | tee /tmp/ssl.log
The openssl client connects to the server and negotiates SSL. Along the way it verifies the certificate path. If it encounters an error, it usually gives a useful error message.
Sean Burford wrote:
On Mon, Jul 21, 2008 at 8:30 AM, John Oliverjoliver@john-oliver.net wrote:
What can I do to troubleshoot this? OpenLDAP client says ldap_simple_bind Can't contact LDAP server but it can resolve the name, ping the server, connect to port 636... and I have no details as to why it thinks it cannot contact the server. Many other clients authenticate to the same server, and I'm using the same ldap.conf, nsswitch.conf, and pam.d/system-auth files.
Apart from seeing configurations and command lines, I have found the full output of the openssl client to be useful for diagnosing my own ldaps issues: echo | openssl s_client -debug -showcerts -connect SERVER:636 2>&1 | tee /tmp/ssl.log
The openssl client connects to the server and negotiates SSL. Along the way it verifies the certificate path. If it encounters an error, it usually gives a useful error message.
Just use -d1 on ldapsearch and you'll get the OpenSSL diagnostic messages.
On Thu, Jul 24, 2008 at 03:14:33PM -0700, Howard Chu wrote:
Just use -d1 on ldapsearch and you'll get the OpenSSL diagnostic messages.
Now we're getting somewhere!
It tells me:
TLS trace: SSL3 alert write:fatal:unknown CA
I'm using a self-signed certificate, and it worked just fine when this machine was a master LDAP server. I moved /var/lib/ldap, created a new /var/lib/ldap, added the synrepl stuff, and started ldap I've also recreated my certificate a couple of different ways... I'm not sure if this scertificate needs to be 100% unique, or if the OU in the certificate needs to be the same as the OU in the cert on the master server, or ??? neither worked, though.
--On Thursday, July 24, 2008 3:59 PM -0700 John Oliver joliver@john-oliver.net wrote:
On Thu, Jul 24, 2008 at 03:14:33PM -0700, Howard Chu wrote:
Just use -d1 on ldapsearch and you'll get the OpenSSL diagnostic messages.
Now we're getting somewhere!
It tells me:
TLS trace: SSL3 alert write:fatal:unknown CA
Any client will need to know about the CA that signed your self-signed cert.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Thu, Jul 24, 2008 at 04:04:10PM -0700, Quanah Gibson-Mount wrote:
Any client will need to know about the CA that signed your self-signed cert.
I created my certificate with:
openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
In slapd.conf I have:
TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem
What do I need to do differently?
--On Thursday, July 24, 2008 4:13 PM -0700 John Oliver joliver@john-oliver.net wrote:
On Thu, Jul 24, 2008 at 04:04:10PM -0700, Quanah Gibson-Mount wrote:
Any client will need to know about the CA that signed your self-signed cert.
I created my certificate with:
openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
In slapd.conf I have:
TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem
What do I need to do differently?
Create your own CA first? Then sign your own certs with it.
http://www.tc.umn.edu/~brams006/selfsign.html
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Thu, Jul 24, 2008 at 04:20:02PM -0700, Quanah Gibson-Mount wrote:
--On Thursday, July 24, 2008 4:13 PM -0700 John Oliver joliver@john-oliver.net wrote:
On Thu, Jul 24, 2008 at 04:04:10PM -0700, Quanah Gibson-Mount wrote:
Any client will need to know about the CA that signed your self-signed cert.
I created my certificate with:
openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
In slapd.conf I have:
TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem
What do I need to do differently?
Create your own CA first? Then sign your own certs with it.
I don't understand why I must handle certs one way on one server, and another way on the other. The self-signed cert works just fine on the other, and I foresee problems if one is self-signed and the other isn't... one day, there's going to be some bizzare SSL issue that'll have me tearing my hair out for a week, until someone finally discovers what's going on and says "You fscking dummy, why the hell are you doing this?"
And I'm not particularly keen to break the working server so it can be in the same state of borkenness as the one I'm fighting now.
It would be absolutely fantastic if someone could tell me why one self-signed cert works and the other doesn't.
On Friday 25 July 2008 01:29:39 John Oliver wrote:
On Thu, Jul 24, 2008 at 04:20:02PM -0700, Quanah Gibson-Mount wrote:
--On Thursday, July 24, 2008 4:13 PM -0700 John Oliver
joliver@john-oliver.net wrote:
On Thu, Jul 24, 2008 at 04:04:10PM -0700, Quanah Gibson-Mount wrote:
Any client will need to know about the CA that signed your self-signed cert.
I created my certificate with:
openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
In slapd.conf I have:
TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem
What do I need to do differently?
Create your own CA first? Then sign your own certs with it.
I don't understand why I must handle certs one way on one server, and another way on the other. The self-signed cert works just fine on the other, and I foresee problems if one is self-signed and the other isn't...
No more than having them both self-singed.
one day, there's going to be some bizzare SSL issue that'll have me tearing my hair out for a week, until someone finally discovers what's going on and says "You fscking dummy, why the hell are you doing this?"
No more likely than someone asking the same questions about actually using self-signed certs at all.
And I'm not particularly keen to break the working server so it can be in the same state of borkenness as the one I'm fighting now.
It would be absolutely fantastic if someone could tell me why one self-signed cert works and the other doesn't.
It would be more fantastic if you could actually provide more details of your environment, up to now we've not known that you have more than one server, and we don't know how your clients are set up.
For example, if you have multiple servers and multiple clients, you really are defeating the point of SSL and increasing your administrative burden by not creating a CA cert.
Now, if you need to re-create a cert, you will have to update the "CA cert" on all clients. If you add another server, you will have to append the new server's cert to the "CA cert".
However, IMHO, this is starting to get off-topic even for this list, almost none of this is specific to OpenLDAP, it would be equally applicable to Apache/Firefox3 or IIS/IE7 (with their new draconian cert validation "features").
Regards, Buchan
On Friday 25 July 2008 01:13:37 John Oliver wrote:
On Thu, Jul 24, 2008 at 04:04:10PM -0700, Quanah Gibson-Mount wrote:
Any client will need to know about the CA that signed your self-signed cert.
I created my certificate with:
openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
In slapd.conf I have:
TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem
What do I need to do differently?
Configure the *client* ??? Look at the TLS_CACERT directive in the ldap.conf(5) man page, and the tls_cacertfile directive in the pam_ldap(5) and nss_ldap(5) man pages (if your pam_ldap/nss_ldap is new enough to have man pages).
Now, unless you've split the cert out separately, you're most likely going to be exposing the private key as well, which means there's pretty much no point to your encryption ....
Regards, Buchan
On Fri, Jul 25, 2008 at 10:20:55AM +0200, Buchan Milne wrote:
On Friday 25 July 2008 01:13:37 John Oliver wrote:
On Thu, Jul 24, 2008 at 04:04:10PM -0700, Quanah Gibson-Mount wrote:
Any client will need to know about the CA that signed your self-signed cert.
I created my certificate with:
openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
In slapd.conf I have:
TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem
What do I need to do differently?
Configure the *client* ???
The clients work perfectly with the working server. Why would they have to have a different configuration to talk to the backup LDAP server? That would pretty much defeat the purpose of having multiple LDAP servers ;-)
Now, unless you've split the cert out separately, you're most likely going to be exposing the private key as well, which means there's pretty much no point to your encryption ....
To be honest, I have no idea about "splitting the cert". I know nothing about OpenSSL. At the moment, I'm far more interested in getting the second LDAP server working than I am in having perfect security. None of these systems are on a public network.
On Friday 25 July 2008 17:16:12 John Oliver wrote:
On Fri, Jul 25, 2008 at 10:20:55AM +0200, Buchan Milne wrote:
On Friday 25 July 2008 01:13:37 John Oliver wrote:
On Thu, Jul 24, 2008 at 04:04:10PM -0700, Quanah Gibson-Mount wrote:
Any client will need to know about the CA that signed your self-signed cert.
I created my certificate with:
openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
In slapd.conf I have:
TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem
What do I need to do differently?
Configure the *client* ???
The clients work perfectly with the working server. Why would they have to have a different configuration to talk to the backup LDAP server?
They don't necessarily need a different configuration, but it being valid for one server doesn't guarantee it will be valid for another server, especially when it comes to ssl, certificate validation etc.
At the moment, I'm far more interested in getting the second LDAP server working than I am in having perfect security.
Then it's easy, turn off SSL.
If you don't want to do that, turn of certificate validation. It's better than exposing keys.
Or, ensure that the "CA certificate" that the clients use contains the certificates of the issuer of both of the server certificates, and that the value of the subject CN on both certificates matches the name you use to connect to the servers.
Regards, Buchan
On Mon, Jul 28, 2008 at 09:20:23AM +0200, Buchan Milne wrote:
Or, ensure that the "CA certificate" that the clients use contains the certificates of the issuer of both of the server certificates, and that the value of the subject CN on both certificates matches the name you use to connect to the servers.
I've tried:
openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 3650
That should create a file with keys and certs all in one, right? No possible misunderstanding about which is where.
For the OU, I put the domain name. I have also tried using the FQDN in a few variations.
For the CN, I put the FQDN.
I pointed TLSCertificateFile, TLSCertificateKeyFile, and TLSCACertificateFile at that file in slapd.conf, and restarted the LDAP service.
And it doesn't work.
On my test client, ldap.conf has:
host 10.99.16.7 base dc=mydomain,dc=com url ldaps://unix-services2.mydomain.com:636 timelimit 120 bind_timelimit 120 idle_timelimit 3600 ssl yes tls_cacertdir /etc/openldap/cacerts tls_checkpeer no pam_password md5
If I change the "host" and "url" to the other LDAP server, it works perfectly.
On the working server, in slapd.conf I have:
TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem
Those files were created with:
openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
I created a second set of keys with that line on the non-working server in the same directories (/etc/ssl and /etc/openldap/ssl). That didn't work either.
On both servers, I can do:
openssl s_client -connect localhost:636 -showcerts
And get identical results (except for the FQDNs, of course, and the jumble of characters in the certificate).
On a client pointed to the non-working server:
[root@localhost ~]# ldapsearch -x # extended LDIF # # LDAPv3 # base <> with scope sub # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1
Supposedly, that means "it works", even though it doesn't. I don't know what to make of that.
I just don't know where to go from here. I've created certificates over and over and over again. Even if by accident, I'd have had to have done it right at least once. On the other server, I did it once, and it worked.
It looks like there must be some other variable... a config file, something, that has something else to do with this.
--On Monday, July 28, 2008 11:30 AM -0700 John Oliver joliver@john-oliver.net wrote:
On Mon, Jul 28, 2008 at 09:20:23AM +0200, Buchan Milne wrote:
Or, ensure that the "CA certificate" that the clients use contains the certificates of the issuer of both of the server certificates, and that the value of the subject CN on both certificates matches the name you use to connect to the servers.
I've tried:
openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 3650
This generates a self-signed cert without a CA. That's part of the root of your problem. By your own email, you have no concept of how SSL signing and authority works. Yet you reject the advice that's been given out of hand. Go back to the link I sent you, and set up your certs correctly, which a valid self-generated CA, or do as others have suggested, stop using SSL until you understand how it works.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Mon, Jul 28, 2008 at 11:55:28AM -0700, Quanah Gibson-Mount wrote:
--On Monday, July 28, 2008 11:30 AM -0700 John Oliver joliver@john-oliver.net wrote:
On Mon, Jul 28, 2008 at 09:20:23AM +0200, Buchan Milne wrote:
Or, ensure that the "CA certificate" that the clients use contains the certificates of the issuer of both of the server certificates, and that the value of the subject CN on both certificates matches the name you use to connect to the servers.
I've tried:
openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 3650
This generates a self-signed cert without a CA. That's part of the root of your problem. By your own email, you have no concept of how SSL signing and authority works. Yet you reject the advice that's been given out of hand. Go back to the link I sent you, and set up your certs correctly, which a valid self-generated CA, or do as others have suggested, stop using SSL until you understand how it works.
I'm sorry, I'll try to be clearer. You're absolutely right in that I don't understand the intricacies of SSL. I fully understand that's a big part of the problem. But the issue in front of me is that I have a current setup that works. I'm trying to get that same functionality out of a second server. You seem to be saying that self-signed certificates just will not work, but that clearly isn't the case... the currently working system uses a self-signed cert, and works perfectly. I understand that's far from ideal. But authentication *works*. At some point, when I have time, I'd love to learn enough about this to create a working CA, and generate certificates with it, and do everything "right". But if I try to do this "right", right now, I'm far more likely to wind up with no working authentication at all.
John Oliver wrote:
On Mon, Jul 28, 2008 at 09:20:23AM +0200, Buchan Milne wrote:
Or, ensure that the "CA certificate" that the clients use contains the certificates of the issuer of both of the server certificates, and that the value of the subject CN on both certificates matches the name you use to connect to the servers.
I've tried:
openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 3650
That should create a file with keys and certs all in one, right? No possible misunderstanding about which is where.
Have you tried actually reading the OpenLDAP documentation? It appears you haven't. Start here and read the whole chapter: http://www.openldap.org/doc/admin24/tls.html
It's a really stupid idea to keep the key and cert in the same file. The point of public-key cryptography is that you generate two pieces, and allow one piece to be distributed publically while requiring the other piece to be kept private.
For the OU, I put the domain name. I have also tried using the FQDN in a few variations.
Irrelevant, the software will only look at the CN in the DN.
For the CN, I put the FQDN.
I pointed TLSCertificateFile, TLSCertificateKeyFile, and TLSCACertificateFile at that file in slapd.conf, and restarted the LDAP service.
And it doesn't work.
What "it"?
On my test client, ldap.conf has:
host 10.99.16.7 base dc=mydomain,dc=com url ldaps://unix-services2.mydomain.com:636 timelimit 120 bind_timelimit 120 idle_timelimit 3600 ssl yes tls_cacertdir /etc/openldap/cacerts tls_checkpeer no pam_password md5
The above is not valid for an OpenLDAP ldap.conf. (See the ldap.conf(5) manpage for what's valid.) It appears to be a PADL nss_ldap config file, but it's still invalid for that purpose. Make sure you're actually looking at the correct config file...
If I change the "host" and "url" to the other LDAP server, it works perfectly.
On the working server, in slapd.conf I have:
TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem
Those files were created with:
openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
I created a second set of keys with that line on the non-working server in the same directories (/etc/ssl and /etc/openldap/ssl). That didn't work either.
On both servers, I can do:
openssl s_client -connect localhost:636 -showcerts
And get identical results (except for the FQDNs, of course, and the jumble of characters in the certificate).
That tells you that the server was able to use the certs you specified, but it doesn't tell you if the client is correctly configured. (Which it obviously is not.)
On a client pointed to the non-working server:
[root@localhost ~]# ldapsearch -x # extended LDIF # # LDAPv3 # base<> with scope sub # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1
Supposedly, that means "it works", even though it doesn't. I don't know what to make of that.
What exactly do you think "ldapsearch -x" was *supposed* to do? It looks like it's working perfectly well, given that you haven't fully configured the client.
I just don't know where to go from here. I've created certificates over and over and over again. Even if by accident, I'd have had to have done it right at least once. On the other server, I did it once, and it worked.
It looks like there must be some other variable... a config file, something, that has something else to do with this.
On Mon, Jul 28, 2008 at 12:02:44PM -0700, Howard Chu wrote:
John Oliver wrote:
On my test client, ldap.conf has:
host 10.99.16.7 base dc=mydomain,dc=com url ldaps://unix-services2.mydomain.com:636 timelimit 120 bind_timelimit 120 idle_timelimit 3600 ssl yes tls_cacertdir /etc/openldap/cacerts tls_checkpeer no pam_password md5
The above is not valid for an OpenLDAP ldap.conf. (See the ldap.conf(5) manpage for what's valid.) It appears to be a PADL nss_ldap config file, but it's still invalid for that purpose. Make sure you're actually looking at the correct config file...
If I change the "host" and "url" to the other LDAP server, it works perfectly.
I'm looking at that page now. But if that config "isn't valid", why does it work perfectly if I change it to:
host 10.99.16.5 base dc=mydomain,dc=com url ldaps://unix-services.mydomain.com:636 timelimit 120 bind_timelimit 120 idle_timelimit 3600 ssl yes tls_cacertdir /etc/openldap/cacerts tls_checkpeer no pam_password md5
That results in perfectly working authentication. Yes, I understand that that may mean that my working server is borken, and my borken ldap.conf just happens to be borken in just the right way to work.
I do appreciate all of the help, and apologize if I seem dense. I know that the root cause is my lack of knowledge here. I'm reading as fast as I can, but an awful lot of this documentation assumes a lot of things. I've never worked with SSL before, and my eyes are rolling back in my head :-) On top of that, I have people breathing down the back of my neck to make this work on a short deadline. Very frustrating :-(
--On Monday, July 28, 2008 12:44 PM -0700 John Oliver joliver@john-oliver.net wrote:
I do appreciate all of the help, and apologize if I seem dense. I know that the root cause is my lack of knowledge here. I'm reading as fast as I can, but an awful lot of this documentation assumes a lot of things. I've never worked with SSL before, and my eyes are rolling back in my head :-) On top of that, I have people breathing down the back of my neck to make this work on a short deadline. Very frustrating :-(
You continue to do things incorrectly, and be unhappy when they don't work because of it. Again, to set up your LDAP servers *correctly* with SSL/TLS, you will need to create your own CA and sign your certs with it, or order commercial certs, and install their CA. Period. Can you do a single server easily the way you've done things? Yes, but it is still broken. Can you do *multiple* servers the way you've done it, easily? No, you cannot. Take the time to do it right. If you'd simply done that from when I first emailed you on 7/24, you'd be 4 days further ahead of where you are now.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Monday, July 28, 2008 12:44 PM -0700 John Oliver joliver@john-oliver.net wrote:
I do appreciate all of the help, and apologize if I seem dense. I know
You continue to do things incorrectly, and be unhappy when they don't work because of it. Again, to set up your LDAP servers *correctly* with
At some point I created a small script to generate self signed certificates. Mostly for Apache2's sake. But of course this works for anything needing a certificate. Apache's site has very useful documentation: http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#ownca
#!/bin/sh # # JvA # Generate self sgined certificate # And remove the passphrase (so services will start without prompting for a password) # # Takes one argument, the name of the key
# check if any argument has been given, if not exit if test -z "$1" then echo 'Please give the name of the key, exiting...' exit fi
echo "Generating key..." openssl genrsa -des3 -out $1.key 1024 echo "" echo "Generating self signed certificate..." openssl req -new -x509 -nodes -sha1 -days 999 -key $1.key -out $1.crt
# Remove passphrase echo "" echo "Removing passphrase..." openssl rsa -in $1.key -out $1.key
# Display results echo "" echo "Displaying details..." openssl x509 -noout -text -in $1.crt
echo "Check the file permissions and make sure "$1".key is only readable by root and if necessary the system account using it." chmod a-r,u+r $1.key ls -l $1.key ls -l $1.crt
On Monday 28 July 2008 20:30:54 John Oliver wrote:
On Mon, Jul 28, 2008 at 09:20:23AM +0200, Buchan Milne wrote:
Or, ensure that the "CA certificate" that the clients use contains the certificates of the issuer of both of the server certificates, and that the value of the subject CN on both certificates matches the name you use to connect to the servers.
I've tried:
openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 3650
That should create a file with keys and certs all in one, right? No possible misunderstanding about which is where.
For the OU, I put the domain name. I have also tried using the FQDN in a few variations.
For the CN, I put the FQDN.
Just give us the output of:
openssl x509 -noout -subject -in server.pem
I pointed TLSCertificateFile, TLSCertificateKeyFile, and TLSCACertificateFile at that file in slapd.conf, and restarted the LDAP service.
And it doesn't work.
What? Provide the command that isn't working.
On my test client, ldap.conf has:
Which ldap.conf ? The one
host 10.99.16.7
Please remove this from your configuration file, it is most likely going to confuse someone or something.
base dc=mydomain,dc=com url ldaps://unix-services2.mydomain.com:636 timelimit 120 bind_timelimit 120 idle_timelimit 3600 ssl yes tls_cacertdir /etc/openldap/cacerts tls_checkpeer no pam_password md5
If I change the "host" and "url" to the other LDAP server, it works perfectly.
On the working server, in slapd.conf I have:
TLSCertificateFile /etc/ssl/ldap.pem
Provide the output of openssl x509 -noout -subject -in /etc/ssl/ldap.pem
TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem
Those files were created with:
openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout /etc/openldap/ssl/ldap.pem -days 3650
I created a second set of keys with that line on the non-working server in the same directories (/etc/ssl and /etc/openldap/ssl). That didn't work either.
On both servers, I can do:
openssl s_client -connect localhost:636 -showcerts
And get identical results (except for the FQDNs, of course, and the jumble of characters in the certificate).
On a client pointed to the non-working server:
[root@localhost ~]# ldapsearch -x # extended LDIF # # LDAPv3 # base <> with scope sub # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1
Supposedly, that means "it works", even though it doesn't.
You've provided a configuration file that looks ilke it is for nss_ldap/pam_ldap, then you conclude that something is working by running 'ldapsearch -x'. I think most people on this list aren't following this logic ...
I don't know what to make of that.
I just don't know where to go from here. I've created certificates over and over and over again.
Why waste your time on creating bad certs? One or two are enough.
Even if by accident, I'd have had to have done it right at least once. On the other server, I did it once, and it worked.
You're assuming that the certificate itself is the problem.
It looks like there must be some other variable... a config file, something, that has something else to do with this.
But, you provide very little information on what you have actually done, how you are determining that something is or isn't working, and the config files you have provided don't match the tools you are apparently testing with.
If you don't explain what you feel isn't working, we're going to have to guess.
Regards, Buchan
openldap-technical@openldap.org