Client Certificate not correctly being selected
Categories
(Core :: Security: PSM, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox75 | --- | unaffected |
firefox76 | --- | unaffected |
firefox77 | --- | fixed |
People
(Reporter: dancingsandwich, Assigned: keeler)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [psm-assigned])
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0
Steps to reproduce:
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0
security.osclientcerts.autoload: false
security.enterprise_roots.enabled: false
Steps:
- Open Firefox, in Preferences → View Certificates install a TLS client certificate.
- Attempt to view a website which during TLS connectivity requests a client certificate.
Actual results:
User is given an "SSL_ERROR_HANDSHAKE_FAILURE_ALERT" error page.
During the final part of TLS handshake the browser is sending an empty certificate field and no certificate verification message.
Expected results:
User should be prompted to use the installed TLS client certificate.
During the final part of TLS handshake the browser sends the client certificate and certificate verification.
Reporter | ||
Comment 1•4 years ago
|
||
Using mozregression it appears the source of changes for this issue occured as part of https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=78b2c3e9c125e40d9bd29f87f5278ea8e7bbfa88&tochange=5b42186a46c8ca67a6af446e0bde36a144ffdc68 one of these two commits.
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
Can you run with the environment variable MOZ_LOG
set to pipnss:4
, attempt to connect to the server, and attach the output here? Thanks!
Reporter | ||
Comment 4•4 years ago
|
||
This was collected with MOZ_LOG_FILE="$HOME/moz.log" MOZ_LOG="pipnss:4" open /Applications/Firefox\ Nightly.app
. I have had to redact certain pieces of information.
Assignee | ||
Comment 5•4 years ago
|
||
Thanks! What extended key usages does your client certificate have? (and, if applicable, what extended key usages does its issuing certificate have?)
Reporter | ||
Comment 6•4 years ago
|
||
Client certificate:
2.5.29.37.0, Server Authentication, Client Authentication, Code Signing, E-mail Protection, Timestamping, OCSP Signing, 1.3.6.1.5.5.7.3.15, 1.3.6.1.5.5.7.3.16, 1.3.6.1.5.5.7.3.17, Smartcard Login, EFS Encryption, EFS Recovery
Issuing intermediate & root certificate:
Certificate Signing, CRL Signing
Server certificate:
Server Authentication, Client Authentication
Assignee | ||
Comment 7•4 years ago
|
||
Does it work if you remove the OCSP signing eku?
Reporter | ||
Comment 8•4 years ago
|
||
Unfortunately as this is directly tied to a large corporate PKI setup, it may take some considerable amount of time before I'm able to provide you an answer as reissuing certificates with changes to key usage will either be difficult or not possible. Attempting to recreate this infrastructure and configuration would also take a lot of my time as I am only an end user and not part of any teams responsible for my organisation's PKI. I will raise this internally to see if it can be expedited, and I can assist you in other lines of enquiry in the meantime.
Assignee | ||
Comment 9•4 years ago
|
||
You should probably mention to them that your personal certificate having that eku means it can sign OCSP responses for other certificates issued by that intermediate and make them appear to be revoked or not revoked.
Assignee | ||
Comment 10•4 years ago
|
||
If you use this build with your PKI setup as it is now, does it work? https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JRNnntGdQ1qdrmWBdLfcyQ/runs/0/artifacts/public/build/target.dmg
Reporter | ||
Comment 11•4 years ago
|
||
I can confirm that build does work with our PKI setup, and that the debug message you have left does print out when debug logging is enabled.
Assignee | ||
Comment 12•4 years ago
|
||
mozilla::pkix treats the id-kp-OCSPSigning extended key usage as forbidden
unless specifically required. Client authentication certificate filtering in
gecko uses mozilla::pkix, so before this patch, certificates with this EKU would
be filtered out. Normally this is correct, because client authentication
certificates should never have this EKU. However, there is at least one private
PKI where client certificates have this EKU. For interoperability, this patch
works around this restriction by falling back to requiring id-kp-OCSPSigning if
path building initially fails.
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 13•4 years ago
|
||
Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6ae0111402ff work around mozilla::pkix forbidding id-kp-OCSPSigning unless specifically required r=bbeurdouche
Comment 14•4 years ago
|
||
bugherder |
Description
•