Missing root CAs in cacerts
ebresie at gmail.com
Fri May 22 15:26:04 UTC 2020
So as I understand this so far:
(1) openjdk has removed or has outdated root ca in its cacerts files
(2) possibility of updating it with another source of certificates (i.e. Mozilla [open], MS/Apple [less open] is being suggested
(3) there may be differences between sources which may have extra or missing items
(4) browsers and more able to reach trusted sites while less so with open JDK (and possible java apps)
(5) each OS and application may have its own methods and cert management mechanism which adds to the mix as well.
I had a few other comments:
(6) I am behind a corporate firewall/ proxy which provides internal certs (With it’s own concerns configured) which adds another use case to consider. I assume part of this may be a concern of the Corp IT management so maybe the problem is new jdks or SW is added outside normal IT expectations which doesn’t account for certs in the same corporate cert:proxy way.
(7) Not even sure if fire walls and other security controls may also further confuse things.
(8) Based on experiences trying to troubleshoot a basic java IDE download issues (not even taking in to account non IDE apps but would wager there are simple problems elsewhere), the solution was to insure the items were added to the store which while doing this was possible, I would argue this is more an admin/ advanced user activity that normal users would be confused and give up in some way.
So for this I think it advisable to make this sort of process of configuring and updating more user friendly to ensure JDK remains acceptable to the community as a whole.
Maybe could be added a UI (maybe in console) enhancements to allow easier configuration.
Maybe could have some security mechanisms to send/receive security specific updates updates.
Maybe make at the JDK level (not app level) to be responsible for this so each app doesn’t have to manage this independently
Maybe some form of security consortium could start being source of managing this (this may be out of scope here but figured I’d throw it out while thinking of these things)
Ebresie at gmail.com
> On May 18, 2020 at 3:11:44 PM CDT, Sean Mullan <sean.mullan at oracle.com> wrote:
> In case you were not aware, the JDK already supports "Windows-ROOT" and
> "KeychainStore" KeyStore implementations that can access the root
> certificates of Windows and MacOS keystores, respectively [1, 2].
> However, it doesn't work out of the box -- for TLS, you need to
> minimally configure the javax.net.ssl.trustStoreType and
> javax.net.ssl.trustStore properties. Other useful options like "keytool
> -trustcacerts" assume the cacerts keystore.
> It would take more thought and some amount of work to make it more
> seamless across the different security components of the JDK.
> That said, this would not necessarily address the root CA consistency
> issues, as these different OSes have their own root CA Programs and thus
> the set of roots can vary across each platform.
> On 5/18/20 6:51 AM, Andreas Ahlenstorf wrote:
> > On Mon, May 18, 2020, at 11:42, Andrew Haley wrote:
> > > What does Windows do? Do they have a system-wide list?
> > Both Microsoft and Apple have their own CA root program and system-wide APIs to access the list trusted of CA certificates. From an admin's POV, it would be great if those lists could be reused.
> > Windows:
> > * https://docs.microsoft.com/en-us/security/trusted-root/program-requirements
> > * https://docs.microsoft.com/en-us/windows/win32/seccrypto/example-c-program-certificate-store-operations
> > macOS:
> > * https://www.apple.com/certificateauthority/ca_program.html
> > * https://developer.apple.com/documentation/security/keychain_services
> > Andreas
More information about the jdk-dev