Do you also experience a test failure on cas-webapp for "testWiring"? Did a pull on master and ran a build. This is what I currently get:
Running org.jasig.cas.WiringTests Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.753 sec <<< FAILURE! Tests in error: testWiring(org.jasig.cas.WiringTests): Failed to load ApplicationContext Tests run: 2, Failures: 0, Errors: 1, Skipped: 0 [INFO] JA-SIG CAS Web Application ........................ FAILURE [4.088s] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) on project cas-server-webapp: There are test failures. -Misagh From: Scott Battaglia [mailto:[email protected]] Sent: Monday, April 16, 2012 7:14 AM To: [email protected] Subject: Re: [cas-dev] Tests Failing on Build of cas master Branch Yes, github.com would be a good short term fix. :-) Long term we need to turn it from an integration test to a proper unit test (though I don't know if its worth the dev effort) On Mon, Apr 16, 2012 at 10:11 AM, Marvin S. Addison <[email protected]> wrote: That error may be because you didn't run "install" to make sure its in your local repository (unless you had run "install" previoulsy). Though I don't understand why the extension is currently a dependency for the webapp. I thought ClearPass was not being enabled by default. Thanks for pointing that out. One error down, 4 to go. I started looking into the other failures. Honestly I don't understand how org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAu thenticationHandlerTests#testAcceptsProperCertificateCredentials is working for anyone. It's pointing at https://wwws.mint.com/, and OpenSSL is clearly showing an incomplete certificate chain for that host: $ openssl s_client -connect wwws.mint.com:443 -showcerts CONNECTED(00000003) depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)06, CN = VeriSign Class 3 Extended Validation SSL SGC CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessC ategory=Private Organization/serialNumber=2324451/C=US/postalCode=92129/ST=California/L=Sa n Diego/street=7535 Torrey Santa FE Rd/O=INTUIT INC./OU=Technology Operations/CN=wwws.mint.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 The JSSE PKI validation routines are very picky about proper cert chain ordering, and the chain above is clearly lacking the root cert. I suppose this could still pass validation if there's an explicit trust entry for the G5 authority. I'm guessing that the JRE on OSX has such an entry in the default truststore, while there is no such entry on Linux. Actually, it's more than a guess: my Linux workstation lacks an entry in the default system truststore, and my colleague verified there is an entry for the G5 authority in that of OSX. We've run into this problem at least once in the past, and we're likely to run into it again. Ideally we'd have a test fixture that didn't depend on the vagaries of remote hosts, but that's admittedly a big undertaking. For now I will simply change the host to something that presents a cert with a common issuer. Changing to https://github.com resolved all core test failures for me, so I'll commit that one-liner. Guess we'll chalk this up to platform-specific behavior. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
