Bug 780417 (SOA-2848)

Link: Added: This issue is a dependency of SOA-1938

Link: Added: This issue is a dependency of SOA-2718

can you comment on this please, can you also comment on the case where have say a mix of jboss2009 and 2011 keys in the same appserver, ie a system gets patched with a different key

Mark Cox's team who own the keys had been updated about the keys expiring few months back.  During the discussions, it was determined that the JVM does not check for expired certificates.  Also, we need to avoid jars signed by two different keys.

I thought the JVM did check but fell back to treating them as 'unsigned' if the certificate had expired.  I'll do a quick test of it this evening and post results.

Link: Added: This issue related SOA-2287

I ran through a number of scenarios/jvms and always saw the certificates, even when expired.  The jarsigner still allowed me to sign jars with expired certificates (although it did emit a warning).  The certificate comparison is still made for packages, even when expired.

This behaviour can be altered by classloader implementations but doesn't appear to be.

Can you confirm what will happen in the field if the original certificate has expired but a patch is provided that contains a valid later certificate, eg if we apply an eap security patch with a 2011 certificate after the original soa 2009 certificate has expired.

This will be an issue if you have a split package as the classloader will do a comparison of the encoded certificates and see the difference.

The signing must continue with the same certificate, even after it has expired, if this is to be avoided.

So, Thawte will only issue 2-year code signing certificates, and they won't let me renew our one that expires in 2009 yet.

Ideally we'd be using timestamped jar signatures; where supported by the jre that would allow us to continue signing with the old cert right up until the expiry date, but the user would never get a notification of an out of date update.  We have the ability to do this, but timestamping support just didn't work well last time we tried it.

On Friday I experimented to see if I could get the signing server to re-use the key.  So when we renew the 2009 certificate we use the exact same key but get a new replacement cert with the 2 year lifespan.  

Could someone test to see what happens if you have parts signed by certificate #1, and parts by certificate #2 where both share the same private key but differ only in validity dates?

(or in other words is the classloader comparing on the encoded certificate data (bad) or modulus (good)).

It's the encoded (bad) variety, this was one of my tests.

Spoke to Kevin on irc; looks like we don't have any good options here.  Timestamping also doesn't help us for updates after June.

So we're really left with

1 - continue to sign updates to existing products with the expired key.  I've tested the signing server is happy to do this, it is.  We'd need to document exactly what happens to customers, and what to explain to them for why we're stuck having to do this.

2 - sign new complete products/major versions with the 2011 key, which we can have access to after March 24th. 

This matches the FAQ: https://docspace.corp.redhat.com/docs/DOC-24306#comment-15910

Anil recommends that we continue to sign with the 2009 certificate