Browser's accepting certificates that Java does not

[Mark A. Claassen]

Wow.  Thank you so much!  I need to read this all more thoroughly.  I really appreciate the suggestions and the help getting this on the correct mailing list.

Mark Claassen
Senior Software Engineer

Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN  46601
E-mail: mailto:mclaassen at ocie.net
Voice: (574)232-3784
Fax: (574)232-4014
  
Disclaimer:
The opinions provided herein do not necessarily state or reflect 
those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and 
assumes no legal liability or responsibility for the posting.

-----Original Message-----
From: net-dev <net-dev-retn at openjdk.java.net> On Behalf Of Sean Mullan
Sent: Wednesday, July 8, 2020 9:38 AM
To: Bernd Eckenfels <ecki at zusammenkunft.net>; OpenJDK <security-dev at openjdk.java.net>
Cc: net-dev at openjdk.java.net
Subject: Re: Browser's accepting certificates that Java does not

Also, in case you did not know, the JDK "PKIX" CertPathBuilder implementation (which is also the default used by the JSSE TrustManager) supports retrieving certificates via the AIA extension, but it is disabled by default. To enable it, set the "com.sun.security.enableAIAcaIssuers" system property to the value "true".

--Sean

On 7/8/20 5:27 AM, Bernd Eckenfels wrote:
> Note that many browsers also download certs from the AIA and even 
> "well known" mechanisms. It won't help to access more truststores, 
> that would be a function you need to prove directly. Also the dynamic 
> installation from Windows Updates or offline from crypt32.dll is not 
> triggered when only browsing the existing stores.
> 
> If you need that kind of integration it's probably better do not use 
> java :)
> 
> Chrome does install those dynamically loaded intermiates to Windows 
> truststores, I think - it would not hurt to get access to it.
> 
> 
> --
> http://bernd.eckenfels.net
> ----------------------------------------------------------------------
> --
> *Von:* security-dev <security-dev-retn at openjdk.java.net> im Auftrag 
> von Daniel Fuchs <daniel.fuchs at oracle.com>
> *Gesendet:* Wednesday, July 8, 2020 11:09:26 AM
> *An:* Mark A. Claassen <MClaassen at ocie.net>; OpenJDK 
> <security-dev at openjdk.java.net>
> *Cc:* net-dev at openjdk.java.net <net-dev at openjdk.java.net>
> *Betreff:* Re: Browser's accepting certificates that Java does not Hi 
> Mark,
> 
> This is probably a question for the security-dev mailing list, which I 
> have put in the to: of my reply.
> 
> best regards,
> 
> -- daniel
> 
> On 07/07/2020 20:24, Mark A. Claassen wrote:
>> I was curious if there has been any thought to allowing accessing to 
>> other certificate stores in Windows besides the "Trusted Root 
>> Certification Authorities" and the "Personal" ones.  It seems like 
>> web servers omitting intermediate certificates in the certificate  
>> chain is pretty common.  Browsers seems to fill in the gaps, but Java
> does not.
>> 
>> We very recently encountered this again when a customer started 
>> proxying their SSL requests, creating a new certificate on the fly, 
>> resigning ours with their corporate CA.  (The browser handled this 
>> fine, but our Java app detected a chain length of 2, instead  of 4 
>> like in the browser.)  Having them put their intermediate
> certificates in the "Trusted Root Certification Authorities" solved 
> the issue, but they are unwilling to do this on a corporate-wide basis.
>> 
>> If Java was able to access more keystores through the MSCAPI 
>> interface, is seems like it would fill in the gaps as well and remove 
>> a pain point we are experiencing where Java does not accept a 
>> certificate even though all their browsers will.  I think all  
>> intermediate certificates are supposed to be in the chain sent from
> the server (https://tools.ietf.org/html/rfc5246) in the TLS 
> negotiation, but since browser's don't enforce care, people are left 
> thinking everything is great (until Java tries to connect).
>> 
>> Thanks,
>> 
>> Mark Claassen
>> Senior Software Engineer
>> 
>> Donnell Systems, Inc.
>> 130 South Main Street
>> Leighton Plaza Suite 375
>> South Bend, IN  46601
>> E-mail: mailto:mclaassen at ocie.net
>> Voice: (574)232-3784
>> Fax: (574)232-4014
>> 
>> Disclaimer:
>> The opinions provided herein do not necessarily state or reflect 
>> those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and 
>> assumes no legal liability or responsibility for the posting.
>> 
>