Closed Bug 1631404 Opened 4 years ago Closed 4 years ago

Client Certificate not correctly being selected

Categories

(Core :: Security: PSM, defect, P1)

77 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla77
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:

  1. Open Firefox, in Preferences → View Certificates install a TLS client certificate.
  2. 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.

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.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Security: PSM
Product: Firefox → Core
Has Regression Range: --- → yes

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!

Flags: needinfo?(dancingsandwich)
Attached file moz.log.moz_log

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.

Flags: needinfo?(dancingsandwich)

Thanks! What extended key usages does your client certificate have? (and, if applicable, what extended key usages does its issuing certificate have?)

Flags: needinfo?(dancingsandwich)

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

Flags: needinfo?(dancingsandwich)

Does it work if you remove the OCSP signing eku?

Flags: needinfo?(dancingsandwich)

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.

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.

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.

Flags: needinfo?(dancingsandwich)

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.

Assignee: nobody → dkeeler
Priority: -- → P1
Whiteboard: [psm-assigned]
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
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: