Bug 474727
| Summary: | ocsp checking incorrectly attempting to use closed connections? | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Nalin Dahyabhai <nalin> | ||||||
| Component: | nss | Assignee: | Kai Engert (:kaie) (inactive account) <kengert> | ||||||
| Status: | CLOSED UPSTREAM | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 5.2 | CC: | ebenes, emaldona, jkurik, rrelyea, shillman | ||||||
| Target Milestone: | rc | Keywords: | Regression | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2010-03-09 21:16:00 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Hmm, commenting out the call to control whether or not PKIX validation is used, the reproducer compiles and works correctly when built and run against 3.11.7 packages, but it begins failing again when I upgrade the NSS package to 3.12.1. Um. So. Regression in nss? It sure looks that way, but I'm holding out hope that it's a bug in the reproducer and thus in my code. In order to reproduce your test, I would require the chain of issuer certs. I don't have the Issuer: O=Red Hat Westford CA XVI, CN=Certificate Authority cert. Created attachment 327277 [details]
root certificate to match the hard-coded example certificates
Oops, here you go.
What output do you get when you run your test tool?
I get:
Verifying "testuser4 (internal copy)" ("UID=testuser4,E=shillman,CN=Test User 4,O=Token Key User"), got error -8179 (NSS 13).
Verifying "testuser5 (internal copy)" ("UID=testuser5,E=jneedle,CN=Test User 5,O=Token Key User"), got error -8179 (NSS 13).
Verifying "testuser6 (internal copy)" ("UID=testuser6,E=rousseau,CN=Test User 6,O=Token Key User"), got error -8179 (NSS 13).
I just tried to use certs from some popular websites (paypal, verisign, gmx) and I have the intermediate and I still get the same error, so something else may be wrong on my testing side, still looking.
thanks, I can reproduce your failure now I reported the failure upstream at: https://bugzilla.mozilla.org/show_bug.cgi?id=470055 The cause is indeed that NSS internal HTTP client for OCSP connection attempts to reuse the socket, despite the fact that the socket has already been closed. I've posted a workaround patch in the upstream bug. That workaround completely disables NSS attempt to cache HTTP socket connections. It fixes the problem reported in this bug. Depending on how urgent this problem is, we can build the workaround patch or wait for a better upstream patch. Please let me know your opinion. |
Created attachment 325765 [details] a cut-down reproducer Description of problem: When pkinit-nss goes to validate client certificates, it only seems to be able to correctly check the OCSP status for one certificate per responder. This appears to be happening because NSS's ocsp client code doesn't notice that the responder's closed its end of the socket, causing the client code to try sending the request over the already-closed connection. Version-Release number of selected component (if applicable): nss-3.12.1.1-3.el5 How reproducible: Always Steps to Reproduce: Call CERT_VerifyCertificate() for two certificates which feature the same OCSP responder. Actual results: The second verification (even if both certificates are valid) will fail. If you change the order in which you're checking them, the second one is still the one that fails. Expected results: Everything's happy. Additional info: This may well be a bug in pkinit-nss. If it is, then I'll be quite happy to bugger off.