[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SSL server certificate that has an intermediary certificate in the chain

David Hawes wrote:

On 2011-08-01 13:07, Howard Chu wrote:

David Hawes wrote:

On 2011-07-30 14:14, Howard Chu wrote:

Erwann ABALEA wrote:

Actual OpenLDAP configuration would be to place B (and maybe B1)
certificate in TLSCACertificateFile/Path element, to be able to verify
the Client certificate. The Server must also place A1 in this element,
so it can be sent to the Client to help it verify the Server
certificate.



So, during the TLS negotiation, B, A1, maybe B1, maybe A are sent to
the Client for it to verify the Server certificate? (remember, this
certificate is signed by A1, and A must already be known by the
Client). That's a waste of bandwidth.


The TLS library doesn't do anything so stupid, it only sends the
certificates that are part of the chain from the subject's cert up to
the root CA.


I think the real question here is if the CA chain that the server sends
and the CA chain that the server uses to verify client certificates can
be different.

In Apache, this is done with the SSLCertificateChainFile and
SSLCACertificateFile directives.  This makes it possible to have the
server send a certificate chain that differs from the CAs it uses to
verify clients.  This is useful if you want to have a server certificate
signed by one CA, but only accept client certificates signed by
another CA.

This sounds like an OpenLDAP feature request to me.


Think about why you would configure such a setup, and what it actually
means. When you have a certificate of your own, signed by a particular
CA, that obviously means that you must trust that CA. If you're going to
accept a cert from another party that is signed by a different CA that
obviously means that you must also trust the other CA. There is
absolutely nothing gained from isolating these two CAs, on either side
of the session.


What is gained is that the server can be explicit about what client
certificates it will accept.  This is useful if you want to use a
separate CA for client auth and do not want to accept certs from the CA
that signed the server's cert.



Suppose my server has a Verisign cert.  If I add the Verisign CA chain
to TLSCACertificateFile, I have just allowed all certs signed by any CA
in that chain to do TLS client auth.  If I want to allow clients signed
by my own CA and not those signed by Verisign, I'm out of luck.



Again, Apache does this by having separate directives for assembling the
certificate chain and specifying which CAs to trust for clients.
Irrelevant. You're taking a mechanism designed for authentication and trying to use it for authorization, which is clearly a misuse of the technology.
A certificate is merely an assertion that an entity is the user they claim to be, nothing more. If you trust a given CA to issue certs at all, then you must trust users presenting certs issued by that CA are who they claim to be. That says nothing about whether they have any privileges on a system, only that their identity has been proven. 

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/