novitski / bitcoinj

Automatically exported from code.google.com/p/bitcoinj
Apache License 2.0
0 stars 0 forks source link

Java doesn't trust StartCom by default #515

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This is stupid. It means Gavin's personal email cert doesn't verify on the 
Oracle JVM. I found a discussion where the StartCom guys claim it's some kind 
of personal vendetta by someone inside Oracle (?!?).

Anyway, it's easy to fix, though I wonder which fix we should prefer. I have 
more confidence in Mozilla / Microsoft/ Apple / Debian / anyone but Oracle to 
verify CA's properly, so I think rather than patching this by adding the 
StartCom certs at runtime, we should just rebuild our internal CA set to be a 
copy of the Mozilla set, and then use that if we can't find a native keystore.

On some platforms there are native KeyStore implementations available that use 
the OS provided set, which is much preferable. We already do this for Android, 
and I tried the Mac key store but it seems to be buggy and doesn't provide the 
root certs for me just other certs. Windows has a native store but we need to 
test it and Linux I think it varies by desktop environment :(

Original issue reported on code.google.com by mh.in.en...@gmail.com on 7 Feb 2014 at 5:16

GoogleCodeExporter commented 9 years ago
This issue was closed by revision 4eb6bdad883c.

Original comment by mh.in.en...@gmail.com on 25 Feb 2014 at 10:44

GoogleCodeExporter commented 9 years ago
Binary file changes like this are near impossible to audit. Can we somehow 
switch to a text based format for the trust store that gets converted to binary 
to the build process (if needed as a binary at all).

Original comment by andreas....@gmail.com on 25 Feb 2014 at 11:02

GoogleCodeExporter commented 9 years ago
Auditing is simple. Run:

keytool -list -keystore cacerts -storepass changeit

You can do a textual diff from the prev and next binaries to see the 
difference. Doing better is tricky because certificates are inherently binary: 
key stores represented as text just end up including lots of data as base64 
encoded, which isn't much better.

The "real" solutions are still as described above - I want to switch to the 
Mozilla set of roots as I trust them to do a better job. Mozilla uses a bizarre 
custom format to represent their CA certs. The fix is probably to have a build 
step that downloads their source file from their web interface to their version 
control, run it through a script helpfully provided by the curl guys to convert 
it into a PEM file, and then convert the PEM into a JKS file.

I fiddled a bit with this over the weekend but it turned out to be complicated. 
I'll open up a separate issue for it.

Original comment by mh.in.en...@gmail.com on 25 Feb 2014 at 11:12