[Date Prev][Date Next]
Re: SSL server certificate that has an intermediary certificate in the chain
2011/8/2 Howard Chu <firstname.lastname@example.org>:
> David Hawes wrote:
>> 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.
Who's talking about authorization? Here, the pointed problem is that
you cannot have a CA used to prove the server's identity to clients,
and a different CA so that clients can prove their identity. In your
scheme, all the CAs are of equal value/trust.
The clients trust a set of CAs, your server needs to have a
certificate signed by one of them.
If your server accepts clients authenticated by a CA, they have to get
a certificate delivered by that CA.
Who decided that the CA used to identify the server must be the very
same CA used to identify the clients?
> 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.
Again, nowhere in the message you're replying to is mentioned
"authorization". Everything we're talking about is authentication.
I can have a server identified by a Comodo/VeriSign/GoDaddy
certificate, while in the same time accept only clients authenticated
by my own CA. The X.509 model doesn't prevent this. Your construction
And as a side effect, even if I use the same CA for both uses,
OpenLDAP will send the root CA to clients in the TLS negociation
phase, and this is absolutely useless (some milliseconds lost for each