As is too often the case I discovered the difference while trying to isolate a
test case. With Java 10 I had extra JVM args to deal with module path and that
appeared to cause the problem. I’m not 100% sure what’s happening in my app,
but the test case is working so there likely isn’t any issue to bother you guys
about. Sorry.
Scott
> On Oct 6, 2018, at 12:24 AM, Scott Palmer <swpal...@gmail.com> wrote:
>
> Sean asked:
>> On what version of Java 8 does it work?
>>
>
> Up to 8u181 at least.
>> I am not sure what the problem is without additional information.
>>
>> What do you need? I will try to sign something trivial with the same cert
>> and create a test case for a bug report.
>>
>> Also, have you tried running with -Djava.security.debug=all? Did
>> anything unusual (exceptions, etc) get logged?
> No. All I notice is that on Java 10.0.2 it shows this (names sanitized for
> public consumption):
> scl: getPermissions ProtectionDomain (file:/full/path/to/my/signed.jar <no
> signer certificates>)
> jdk.internal.loader.ClassLoaders$AppClassLoader@57536d79
> <no principals>
> java.security.Permissions@ba2f4ec (
> ("java.io.FilePermission” "/full/path/to/my/signed.jar" "read")
> ("java.lang.RuntimePermission" "exitVM")
> )
>
> and on Java 8u181 it shows this:
> scl: getPermissions ProtectionDomain (file:/full/path/to/my/signed.jar
> (Signer: [
> [
> Version: V3
> Subject: CN=My Company Corp., OU=Development, O=My Company Corp.,
> L=Markham, ST=Ontario, C=CA
> Signature Algorithm: SHA1withDSA, OID = 1.2.840.10040.4.3
>
> Key: Sun DSA Public Key
> Parameters:DSA
> p: fd7f5381 1d751229 52df4a9c 2eece4e7 f611b752 3cef4400 c31e3f80
> b6512669
> 455d4022 51fb593d 8d58fabf c5f5ba30 f6cb9b55 6cd7813b 801d346f f26660b7
> 6b9950a5 a49f9fe8 047b1022 c24fbba9 d7feb7c6 1bf83b57 e7c6a8a6 150f04fb
> 83f6d3c5 1ec30235 54135a16 9132f675 f3ae2b61 d72aeff2 2203199d d14801c7
> q: 9760508f 15230bcc b292b982 a2eb840b f0581cf5
> g: f7e1a085 d69b3dde cbbcab5c 36b857b9 7994afbb fa3aea82 f9574c0b
> 3d078267
> 5159578e bad4594f e6710710 8180b449 167123e8 4c281613 b7cf0932 8cc8a6e1
> 3c167a8b 547c8d28 e0a3ae1e 2bb3a675 916ea37f 0bfa2135 62f1fb62 7a01243b
> cca4f1be a8519089 a883dfe1 5ae59f06 928b665e 807b5525 64014c3b fecf492a
>
> y:
> 4d96a9d5 2b20f1f7 f12decd1 4b5ba0e8 4a98d40a 7d745661 b12f661f 84eae997
> 071d3619 308961f8 6879f76a 0feba11f e08a63fe b044441a fbd33b3c 30ba3e96
> e1ac938b bb19ec59 89422123 6b15ad53 ed33e791 a616a61e c6fda1d5 bf95657e
> 399bb7a1 2ae77ce1 d1806666 5d68c61a 80f967db 525e36c5 a011594a 382ca7aa
>
> Validity: [From: Thu May 31 16:16:20 EDT 2012,
> To: Wed Aug 29 16:16:20 EDT 2012]
> Issuer: CN=My Company Corp., OU=Development, O=My Company Corp., L=Markham,
> ST=Ontario, C=CA
> SerialNumber: [ 4daa8ba0]
>
> Certificate Extensions: 1
> [1]: ObjectId: 2.5.29.14 Criticality=false
> SubjectKeyIdentifier [
> KeyIdentifier [
> 0000: 89 81 49 B9 64 68 72 52 18 39 CE 77 97 7A E9 C9 ..I.dhrR.9.w.z..
> 0010: 0C C1 C0 5D ...]
> ]
> ]
>
> ]
> Algorithm: [SHA1withDSA]
> Signature:
> 0000: 30 2C 02 14 3A FE E1 48 12 0A 02 86 D2 C2 17 56 0,..:..H.......V
> 0010: 98 88 76 B6 E7 10 C6 0B 02 14 7C 59 CC AF F6 8E ..v........Y....
> 0020: BF ED 27 59 42 E1 78 6E 5C 5E E6 E4 A7 53 ..'YB.xn\^...S
>
> ]))
> sun.misc.Launcher$AppClassLoader@3d4eac69
> <no principals>
> java.security.Permissions@5cb0d902 (
> ("java.io.FilePermission" "/full/path/to/my/signed.jar" "read")
> ("java.lang.RuntimePermission" "exitVM")
> )
>
>>
>> I would also suggest filing a bug with a reproducible test case, if
>> possible: https://bugreport.java.com/bugreport/
> I’ll try to put something together.
> Bernd asked:
>> What are the Hashes, signatures algorithms and key Sizes? Maybe one of the
>> newer security properties turning those off? Does it have a timestamp?
>
> SHA1withDSA 1024 bit. There is no timestamp.
>
> I checked the $JAVA_HOME/conf/security/java.security file and the key size
> and algorithm appear to allowed. But there is a lot in there and I’m not
> 100% sure - What property are you thinking of? I did comment out two of the
> restrictions that I thought could be related even though they looked okay
> (jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms) and it had
> no effect
>
>
> *please include me in replies, I’m not subscribed to the list*
>
> Regards,
>
> Scott
>
>
> Excuse me if this isn’t the right place to ask this.
>
>
> I have the following code to check the signature:
>
> private static boolean signedByMe(Class<?> c) {
> ProtectionDomain protectionDomain = c.getProtectionDomain();
> if ( codeSource == null ) return false;
> if (codeSigners != null) {
> byte[] sigKey = cp.getPublicKey().getEncoded();
> return true;
> }
> }
> }
> }
> return false;
>
>
> On Java 8 this works fine.
>
> On Java 10.0.2 codeSigners is null.
>
>
> Is this a bug or a specific change to how the expired certificate is handled?
>
> Regards,
