Closed Bug 1267643 Opened 4 years ago Closed 1 year ago
Firefox fails with a handshake error when trying to connect to a site requesting a client certificate signed by a different CA than itself
47 bytes, text/x-phabricator-request
|Details | Review|
We have an SSL server running lighttpd whose server certificate is signed by the etat.lu CA. It accepts client certificates signed by a different CA (AEV). Client certificates are mandatory (ssl.verifyclient.enforce = "enable") Chrome and curl can connect all right in such a setup. However, Firefox, throws an SSL_ERROR_HANDSHAKE_FAILURE_ALERT (despite having a matching client certificate installed). If I temporarily exchange the *server* certificate, and install one signed by AEV, than even Firefox works.
Thanks for filing the bug. Currently, this behaviour is expected: > https://hg.mozilla.org/mozilla-central/annotate/6fc34759465e/security/manager/ssl/nsNSSIOLayer.cpp#l2152 > https://hg.mozilla.org/mozilla-central/annotate/6fc34759465e/security/manager/ssl/nsNSSIOLayer.cpp#l2266 It looks like this behaviour was already present when client auth functionality was added back in 2001: > https://hg.mozilla.org/experimental/gecko-dev/rev/edb2945ef1c7#l1.569 if ^ doesn't work: > https://github.com/mozilla/gecko-dev/commit/3a1a52d207f6935f2d15719f6f5a58daefe57330#diff-1f8efd3d29ccd85c52e1dce6a10f889fR1237 I don't know how valuable this filtering is, and if it's useful to most users of client auth. Unfortunately (and annoyingly), there is no bug number mentioned in the commit message, so I can't find out the original justification for this. I was also unable to find the appropriate corresponding bug (assuming it was even filed).
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Version: 45 Branch → unspecified
keeler: Any opinion on whether we should keep or get rid of the filtering?
Looking at the TLS rfcs, this feature is a SHOULD, but we implemented it incorrectly in the first place. Apparently "If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the [client] certificate chain SHOULD be issued by one of the listed CAs." (rfc 5246 section 7.4.6). So we shouldn't be filtering by the direct issuer of the client certificate but rather by certificates where there exists a chain to a certificate with one of the specified DNs. This is complicated by the fact that NSS doesn't appear to allow PSM to set the chain directly. Instead, it takes the certificate and key and calls CERT_CertChainFromCert, which appears to build a chain by matching issuer to subject until it finds a self-issued certificate (I don't think it even verifies signatures, although it does look like it checks for basic constraints). As I maintain that it's not the browser's job to verify the client certificate (and hence we shouldn't even be building these chains), I'm tempted to say we should just skip this filtering altogether. I guess it comes down to what's better for the user - should we remove this (mostly broken) feature at the cost of showing them potentially unrelated certificates? I guess that experience will be as if the server always sends an empty certificate_authorities. Unfortunately, if the user has opted for the browser automatically selecting a client certificate (why is that even possible? It's terrible for privacy), we're more likely to choose the wrong one if the server does send a non-empty certificate_authorities. Here's maybe what we should do: * Implement a more persistent "remember I chose this client certificate for this site" feature (i.e. make it work across restarts) * Remove the "automatically choose a certificate" option * Remove the filtering based on certificate_authorities Alain - as a temporary workaround, make sure your server is sending a certificate_authorities list that contains the issuer DN of the client certificates you're expecting (AEV, looks like).
Priority: -- → P3
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/9bed62de3d16 Remove client certificate filtering based on CA names r=keeler
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/3eb2d7a85e7b Remove client certificate filtering based on CA names r=keeler
Depends on: 1590888
You need to log in before you can comment on or make changes to this bug.