The latest build report can be found at [1]. There are other 4 failures. Although it passes, SSLSocketRemoteTest#testUsingDefaultConfig is taking 49 seconds to complete. I am investigating. [1] http://tinyurl.com/logback-tr8 Since that particular test is really just verifying default SSLContext creation, I suspect the underlying culprit is SecureRandom. The default seed for SecureRandom is typically implemented using an entropy source such as /dev/urandom, and a call to read from /dev/urandom could block with arbitrary duration while awaiting sufficient entropy. Generally, this takes a few hundred milliseconds, but I've seen outliers in which the delay is greater by a couple of orders of magnitude. During tests, we can probably avoid blocking when an SSLContext is created by seeding the SecureRandom instance directly rather than letting the SecureRandom implementation seed itself using a source that potentially blocks. Obviously, we wouldn't want to inadvertently allow the SecureRandom instance to be (insecurely) seeded outside of test time, so a careful approach will be required. carl