Asking about this in IRC, and was told that the MRI tests for JRuby9k are run in CI via mvn -Prake -Dtask=test:mri. I ran that and grepped all of the output for "openssl" and "x509" and didn't see any matches, leading me to believe that the openssl tests may not be getting run in CI for JRuby9k.

I did a bisect and it appears to me that the src/test/ossl/1.9/test_x509store.rb test was passing prior to this commit, and has been failing since then:

ef7a170

UPDATE - the test failure that started showing up in v0.9.14 appears to be an ArrayIndexOutOfBoundsException. The ClassCastException seems like it may not have started happening until v0.9.18. I'm going to keep focusing on the ClassCastException for now, but it seems like there may be some additional bugs that warrant separate tickets.

@cprice404 Thank you for digging.

About the next version (after 1.54):

BouncyCastle 1.55 release notes had this perhaps-interesting line:

Change Warning (users of 1.52 or earlier): The PEM Parser now returns an X509TrustedCertificate block when parsing an openssl trusted certificate, the new object was required to allow the proper return of the trusted certificate's attribute block. Please also see the porting guide for advice on porting to this release from much earlier ones (release 1.45 or earlier).

w/rt the BC version:

• If I build the current HEAD of jruby-openssl against BC 1.52, I still get this ClassCastException when I run the tests.
• The current jruby-openssl code will not compile against BC 1.51.
• Based on the BouncyCastle release notes, I suspect that the change that is causing the ClassCastException was introduced in 1.51, but I can't tell for certain since jruby-openssl won't compile against that version.

Here is a minimal reproducer test that I've been using in case anyone else looks into this:

def test_foo
    now = Time.at(Time.now.to_i)
    ca_exts = [
        ["basicConstraints","CA:TRUE",true],
        ["keyUsage","cRLSign,keyCertSign",true],
    ]
    ee_exts = [
        ["keyUsage","keyEncipherment,digitalSignature",true],
    ]
    ca1_cert = issue_cert(@ca1, @rsa2048, 1, now, now+3600, ca_exts,
                          nil, nil, OpenSSL::Digest::SHA1.new)
    ca2_cert = issue_cert(@ca2, @rsa1024, 2, now, now+1800, ca_exts,
                          ca1_cert, @rsa2048, OpenSSL::Digest::SHA1.new)
    ee1_cert = issue_cert(@ee1, @dsa256, 10, now, now+1800, ee_exts,
                          ca2_cert, @rsa1024, OpenSSL::Digest::SHA1.new)

    puts "EE1CERT: #{ee1_cert.class}"
    puts "CA2CERT: #{ca2_cert.class}"

    # puts "EE1CERT.to_java: #{ee1_cert.to_java.class}"
    # puts "CA2CERT.to_java: #{ca2_cert.to_java.class}"
    # puts "[EE1CERT].to_java: #{[ee1_cert].to_java(java.util.List)[0].to_java.class}"
    # puts "[CA2CERT].to_java: #{[ca2_cert].to_java(java.util.List)[0].to_java.class}"

    store = OpenSSL::X509::Store.new
    store.verify(ee1_cert, [ca2_cert])
    # store.verify(ee1_cert, [ee1_cert])
  end

A few more interesting things that I've learned:

1. Given the above test, on jruby-openssl v0.9.13 before the BC upgrade, if I add this line before the call to verify, I get a ClassCastException:

    [ca2_cert].to_java(java.util.List)

2. On jruby-openssl v0.9.18, in the implementation for X509StoreContext.initialize, there is some code that iterates over the chain array. Doing so seems to implicitly call the toJava method of X509Cert, which gives us back a BC object rather than an instance of org.jruby.ext.openssl.X509Cert. The current implementation of that toJava method was introduced in this commit ecc1a05 , which only exists in v0.9.18.

I still don't understand exactly what's going on here but it seems like the implicit calls to toJava during an array iteration are at least partly to blame. The specific implementation of toJava that was added in v0.9.18 seems likely to cause some problems when called implicitly, but since this type of test will also fail on v0.9.14 (where that toJava doesn't exist), the current toJava implementation doesn't explain the full situation.

fixed with #114 ... (in >= 0.9.19)