Closed Bug 470479 Opened 11 years ago Closed 11 years ago

IO timeout during cert fetching makes libpkix abort validation.

Categories

(NSS :: Libraries, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED
3.12.4

People

(Reporter: alvolkov.bgs, Assigned: slavomir.katuscak+mozilla)

References

Details

(Whiteboard: PKIX SUN_MUST_HAVE)

Attachments

(2 files)

It seems that PKIX_BuildChain stops all operation and immediately returns error
when IO occurs during cert chain fetching. Neet to follow up this bug.

vfychain -d UserDB -pp -vv -f UserCA2.der CA2CA1.der -t Root.der
Chain is bad, -5990 = I/O operation timed out.
PROBLEM WITH THE CERT CHAIN:
CERT 2. CN=CA2 Intermediate,O=CA2,C=US [Certificate Authority]:
  ERROR -5990: I/O operation timed out.
execution completed, exit code is 1
Returned value is 1, expected result is pass
chains.sh: #1036: AIA: Verifying certificate(s)  UserCA2.der CA2CA1.der with flags -d UserDB -f   -t Root.der - FAILED
Whiteboard: PKIX SUN_MUST_HAVE
Summary: IO timeout during cert fetching makes libpkix about validation. → IO timeout during cert fetching makes libpkix abort validation.
Priority: -- → P1
Target Milestone: 3.12.2 → 3.12.3
Duplicate of this bug: 464702
I've just verified, that libpkix correctly continues path building in case of connection error that happens during cert fetching failure. But we need to have a test that supports this finding.

Slavo, please create a chain test with the following conditions:
          Bridge Cert 2 with invalid AIA url
        /
EE - CA 
        \ Bridge Cert 1 with valid AIA url - Root CA

The issuing time of Bridge Cert 2 should indicate that the cert is newer than
Bridge Cert 1. With this conditions libpkix will try to fetch a cert from
invalid location before it will be able to construct a valid chain.
Assignee: alexei.volkov.bugs → slavomir.katuscak
Status: UNCONFIRMED → NEW
Ever confirmed: true
Patch to workaround this failure. If network connection times out, then special unknown status is reported, that would be not reported as error (tree stays green) but can be reported via TinderboxPrint as text message. 

Patch also contains some modifications required for screnario suggested in comment #2. I'm going to prepare this scenario as a separate bug id.
Attachment #366556 - Flags: review?(alexei.volkov.bugs)
Created bug 482471 for comment #2.
Comment on attachment 366556 [details] [diff] [review]
Patch v1. (checked in)

r=alexei
Attachment #366556 - Flags: review?(alexei.volkov.bugs) → review+
Comment on attachment 366556 [details] [diff] [review]
Patch v1. (checked in)

Checking in chains/chains.sh;
/cvsroot/mozilla/security/nss/tests/chains/chains.sh,v  <--  chains.sh
new revision: 1.14; previous revision: 1.13
done
Checking in common/init.sh;
/cvsroot/mozilla/security/nss/tests/common/init.sh,v  <--  init.sh
new revision: 1.71; previous revision: 1.70
done
Attachment #366556 - Attachment description: Patch v1. → Patch v1. (checked in)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Today I found out on Tinderbox results that previous patch doesn't work correctly on standard tests (memory leak testing is OK) because error messages sent to error output are not detected.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Added checking on error output and also checking for error 8030.
Attachment #371424 - Flags: review?(alexei.volkov.bugs)
Priority: P1 → P2
Target Milestone: 3.12.3 → 3.12.4
Attachment #371424 - Flags: review?(alexei.volkov.bugs) → review+
Comment on attachment 371424 [details] [diff] [review]
Patch v2. (checked in)

Checking in chains.sh;
/cvsroot/mozilla/security/nss/tests/chains/chains.sh,v  <--  chains.sh
new revision: 1.16; previous revision: 1.15
done
Attachment #371424 - Attachment description: Patch v2. → Patch v2. (checked in)
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.