331111 - SSL3 "extended" tests all failing on Windows Tinderbox

Status: RESOLVED FIXED

(NSS :: Test, defect, P1)

Description

[Nelson Bolyard (seldom reads bugmail)]

NSS tinderbox is now continuously failing on Windows.
The failing test cases are the SSL3 "extended" tests.

The extended tests are simply tests that use a server cert chain
with 3 certs in it, a root CA, an intermediate CA, and the server EE cert.
The failures are all the same:
tstclnt: write to SSL socket failed: Peer's Certificate issuer is not recognized.

The most likely cause of this is that the server process and client process
are not using cert DBs from the same test run.  Perhaps the selfserv is 
still running from a previous all.sh run?  Or perhaps the script is running
the client or server pointing it to the wrong directory for the cert DBs.

If the problem is that selfserv is an old process that wasn't killed,
that's a problem with the test scripts, and this is a "test" bug.
Likewise, if the problem is that selfserv (or testclnt) is being started
from the wrong cert DB, that's also a test script bug.

On the ohter hand, if this problem is not caused by old processes or wrong
test scripts, and really is because of some functional problem with the 
cert library code, then please change this bug's component from "test" to 
"libraries", and diagnose that.  

This problem is Specific to the Windows platform, and so no other platform
should be used as a substitute for Windows in the diagnosis.

This is highest severity because it makes tinderbox output useless.  
Please treat this with top priority today.

Comment 1

[Neil Williams]

These failures are caused by a server cert DB which is missing the intermediate certs of a 4 cert chain (root CA-chain 1-chain 2-server). In such cases selfserv, without complaining, sends its leaf cert as the entire chain. Tstclnt then fails with

tstclnt: write to SSL socket failed: Peer's Certificate issuer is not recognized.

The next step is to find where the extended SSL tests' DBs are created and discover 1) why it isn't adding all the certs in the chain (possibly minus the root cert?) and 2) why it isn't complaining about its problems.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #1)
> The next step is to find where the extended SSL tests' DBs are created and
> discover 
> 1) why it isn't adding all the certs in the chain (minus the root cert?) and 
> 2) why it isn't complaining about its problems.

and 3) why is the behavior different on windows than on other platforms

Comment 3

[Neil Williams]

This is really a tinderbox environment problem. The PATH variable for the tinderbox script was set so that the Windows find command was being run instead of the MKS (Unix-style) find. This caused cert chains to be skipped during a copy operation of cert.sh which kept the cert from being verifiable. I changed the setenv.bat file used to set up the environment for the tinderbox script and restarted it. Will leave this open until the tinderbox goes green.

Comment 4

[Neil Williams]

Tinderbox is green.

Comment 5

[Julien Pierre]

Could we have a test that checks for the proper tools installed on the system required for QA , such as find ?

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Yeah, a pre-NSS-test QA test script whose only purpose is to verify that
the tools and PATH are correct would be good.  

I'm reopening this bug for a different reason.  ALL the scripts used in 
tinderbox on all tinderbox test platforms MUST be checked in.  
The script that was fixed for this bug report was (I'm told) a personal
script that belonged to Sandeep, and was in his personal home directory.

Tinderbox must not depend on anyone's personal home directories or files.
All the files that are used for Tinderbox, to set it up, restart it, etc,
including any crontab entries, must be checked in, and must be usable by
any NSS developer.  

So, Sandeep's personal shell script that sets PATH has been fixed, but 
this problem isn't resolved until the scripts are all checked in and 
usable by others.  

Comment 7

[Neil Williams]

I opened bug 333597 to(In reply to comment #6)
> Yeah, a pre-NSS-test QA test script whose only purpose is to verify that
> the tools and PATH are correct would be good.  
> 
> I'm reopening this bug for a different reason.  ALL the scripts used in 
> tinderbox on all tinderbox test platforms MUST be checked in.  
> The script that was fixed for this bug report was (I'm told) a personal
> script that belonged to Sandeep, and was in his personal home directory.
> 
> Tinderbox must not depend on anyone's personal home directories or files.
> All the files that are used for Tinderbox, to set it up, restart it, etc,
> including any crontab entries, must be checked in, and must be usable by
> any NSS developer.  
> 
> So, Sandeep's personal shell script that sets PATH has been fixed, but 
> this problem isn't resolved until the scripts are all checked in and 
> usable by others.  
> 

I opened bug 333597 for this specific, uh, enhancement? oversight? Can we close this one now?

Comment 8

[Julien Pierre]

What about my request from comment 5 ? That doesn't seem to be covered under bug 333597 . So I'm reopening this again.

Comment 9

[Neil Williams]

(In reply to comment #8)

I agree a script that verifies the environment would be good, but surely this isn't a P1 blocker?

Comment 10

[Julien Pierre]

Neil,

Correct, it should be a P2 RFE in the tests category for all platforms.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Neil, please attach to this bug a copy of each of the files that was modified
to correct the problems.  IIRC, that would include (at least) a .bat file
or shell script that sets the PATH environment variable.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

I will make a separate RFE from comments 5 and 6, about a platform tools test.

Comment 13

[Neil Williams]

Attachment: setup files changed to fix the problem

The fix was to move %MKSBASE%\mksnt ahead of %PATH% in the SET PATH command line.