Oh sorry, I think I was using the wrong terminology.

Let me see if I have this straight.

If my client requires a client cert, this is mutual SSL.  Here the client 
proves 
to the server that it is allowed to communicate with the server via it's client 
cert.

In order to get encrypted network traffic, the server cert is transfered to the 
client, then the client must accept or reject it.  If they accept the server 
cert, then there is encrypted network traffic.  This is known as server side 
SSL.

Is that right?




________________________________
From: Rene Hollan <rene.hol...@watchguard.com>
To: openssl-users@openssl.org; openssl-users@openssl.org
Sent: Mon, July 26, 2010 2:31:20 PM
Subject: RE: Simple question about SSL certs


Again, the purpose of the client cert is to authenticate you to the remote (in 
this case LDAP) server. It can be used to restrict WHO can access the server 
REGARDLESS of what credentials (account and password) they might have. It can 
also be used as a substitute to provide those credentials (at least X509 
supports this, whether your LDAP server does is another question). It is NOT 
necessary to use a client cert to achieve secure communications. A server cert 
is enough. However, unless your LDAP browser client has a trusted list of CA 
certificates, one of which signed the LDAP server cert, someone will have to 
decide whether to trust the server cert provided by the LDAP server. This is 
why 
you are prompted for this before authenticating. You are expected to examine it 
(likely checking its fingerprint), and decide if you are connecting to the REAL 
LDAP server, or if someone is spoofing it, trying to get you to give up your 
authentication credentials to them.

When you say "account and password", I'm guessing you mean a DN and password 
used to bind with the LDAP server, and which determines what you may or may not 
read, modify, add, or delete, right? Something like cn=Manager,dc=fubar,dc=com, 
right? That's not what I was thinking of when I meant "authenticate to get a 
client cert". I was thinking of some COMPLETELY DIFFERENT authentication 
mechanism you have, that can be used to establish your identity, and then 
safely 
provide you with a client cert for use with the LDAP server. That said, I can't 
see any overwhelming NEED for you to have to use a client cert to contact an 
LDAP server (unless it is configured that way).

One possibility is to have bind information to the LDAP server encoded in the 
client certificate (say the CN part of the Subject), so you don't have to 
separately provide credentials, but I'm not sure if your LDAP server supports 
that.

It may simply be the case that your LDAP browser SUPPORTS the use of client 
certs because the LDAP server might. That does not mean you have to use them 
unless the LDAP server is configured to require them.



-----Original Message-----
From: owner-openssl-us...@openssl.org on behalf of Bryan Boone
Sent: Mon 7/26/2010 2:09 PM
To: openssl-users@openssl.org
Subject: Re: Simple question about SSL certs

Hi Rene, thanks for the reply.

Well I am not sure really how this works.  Here is why I am confused.

I have two windows LDAP browser clients that I did not write.  One is called
Jxplorer and the other is called LDAPEditor.  I also have a regular openldap
server running on a suse box that is using TLS.

The Jxplorer client, alows me to manually load the client SSL certs into the
program so that I can connect using SSL.

the LDAPEditor allows me to put in my user name and password, then check a box
that says "SSL".  When I hit connect, a message pops up and says that I am
trying to connect to a LDAP server that is using a self signed cert, and if I
want to accept or reject it.

I am not sure if you are familiar with LDAP but, unsecured LDAP transferes user
name and password in clear text over the network.  I need to enable SSL so that
the data is encrypted.  So if I authenticate before I push the client cert down
to the client and ask for acceptance, doesn't that defeat the purpose of SSL? 
At that point there is no need to use SSL because I have already transfered the
user name and password in clear text.

So wouldn't it be better for my client program, to download the client cert
first.  Then prompt a user to accept or reject the cert.  Then do the
authentication?

Obviously having my customer manually upload the client cert to their computer
is the best thing, but I would like to mimic the behavior of the LDAPEditor, not
the Jxplorer.

thanks




________________________________
From: Rene Hollan <rene.hol...@watchguard.com>
To: openssl-users@openssl.org; openssl-users@openssl.org
Sent: Mon, July 26, 2010 1:43:19 PM
Subject: RE: Simple question about SSL certs


What you are asking for does not make sense. The point of the client cert is to
establish the identify of the client. If the server bootstraps this, ANY client
can connect and receive the identity.

Now, what you MAY want to do is authenticate via a different mechanism (say
account and password on a secure web server), and have it push the client cert
to you.


-----Original Message-----
From: owner-openssl-us...@openssl.org on behalf of Bryan Boone
Sent: Mon 7/26/2010 12:55 PM
To: openssl-users@openssl.org
Subject: Simple question about SSL certs

Hi everyone, I am a noob when it comes to SSL and I have an easy question but I
don't have the time to look up the answer myself.

I am trying to write an LDAP client.  I need this client to use SSL as well.  I
am using the openldap server and C libraries.  Here is what the openldap web
page says...

OpenLDAP clients and servers are capable of using the Transport Layer Security
(TLS) framework to provide integrity and confidentiality protections and to
support LDAP authentication using the SASL EXTERNAL mechanism. TLS is defined in
RFC4346.
 
I would like to write an LDAP client that when a user connects to an LDAP server
with SSL, that the client cert is automatically downloaded to the client.  Then
a prompt asks the client to accept or reject the cert.  Is this possible when
using the OpenSSL C libraries?
 
thanks


      

Reply via email to