With my newsgroup/mailing list moderator hat on, I write:
PLEASE DO NOT reply to this list by multiple addresses.
Please reply to no more than one of the following addresses:
mozilla-dev-tech-cry...@lists.mozilla.org
dev-tech-crypto@lists.mozilla.org
mozilla.dev.tech.crypto newsgroup
Now, with my moderator hat off, I write:
> Hmm it's really weird - the code references seem to indicate that the
> missing (extended) key usage extension is not the reason for the
> certificate being filtered out.
Correct.
> But I again checked the trust settings for the CA certificates. They're
> fine...
The browser's trust settings have NO ROLE in the choosing of a client auth
certificate when requested by a server. Setting the client's trust
flag on a CA, indicating that the CLIENT trusts it for client certificates
does not, by itself, make the certificates issued by that CA eligible to
be sent by the client to the server in response to server requests for
client auth certs.
What matters most in such requests is the list of CA that the SERVER
trusts to issue client certs. When the server requests that the client
authenticate itself by sending a client certificate, within that request
the server MUST send the list of CA names that it trusts to issue client
certs. The client MUST NOT send back a cert unless that cert is directly
issued by, or chains up to, one of the CAs named in the server's list of
trusted client CAs. It is a violation of the protocol to do otherwise.
So, you can set trust flags in the client until the cows come home, but
until the SERVER sends out that CA name in its list of trusted client CAs,
an RFC-compliant client will not send any certs from that CA.
--
/Nelson Bolyard
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
