Timeline for Why do I need to add intermediate CA certificates to JVM's cacerts file?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 23, 2017 at 14:29 | comment | added | Mike Ounsworth | @SteffenUllrich Yup, that makes a lot of sense. I hadn't really thought through that cert validation is a "roll-your-own" kind of thing in most contexts. | |
| Aug 23, 2017 at 14:28 | comment | added | Steffen Ullrich | @MikeOunsworth: this problem is actually similar to the (more important) problem of doing OCSP lookups. In this case also HTTP lookups are needed - which of course must be integrated with the handling inside the application, with proxy settings etc. | |
| Aug 23, 2017 at 14:26 | comment | added | Steffen Ullrich | @MikeOunsworth: doubt that AIA is done by any implementations which just use OpenSSL, GnuTLS, Botan, PolarSSL or similar "lower" level libraries. Not only would the AIA extension to be automatically extracted during certificate verification but there must be also some HTTP stack somewhere so that the actual request can be made. And, given that these libraries are often used in a non-blocking way this HTTP stack would need to be integrated with the applications event loop etc. I'm not aware of any interface existing in these TLS stacks for this. | |
| Aug 23, 2017 at 14:21 | comment | added | Mike Ounsworth | @SteffenUllrich Is AIA really not supported by all TLS engines? That wouldn't be surprising, but would be ... dissapointing. | |
| Jun 23, 2017 at 12:59 | comment | added | Steffen Ullrich | @Utku: it might be that IE works around the problem by Downloading the missing certificate based on the CA issuers information in the AIA part of the certificate (see my response) while Firefox does not. There is a lot of undocumented magic going on in the different TLS stacks and apps and checking with a desktop browser often works while it does not work with other TLS clients. | |
| Jun 23, 2017 at 12:42 | comment | added | Utku | On the other hand, I can reproduce the problem exactly in Firefox. Since Firefox uses its own certificate store, I have first added the root certificate and still was not able to connect. Only after I have added the intermediate CA's certificate, I was able to connect with Firefox. | |
| Jun 23, 2017 at 12:29 | comment | added | Utku | By the way, the weird thing is the following: I am able to reproduce the problem in IE if I remove both the intermediate cacert and the root cacert. However, if I add the root cacert but not add the intermediate cacert, IE is able to connect. If the server is not sending the intermediate cacert, IE should not be able to connect. However, it does. I have used InPrivate browsing while trying these in order to disable SSL cache. | |
| Jun 23, 2017 at 12:00 | comment | added | Steffen Ullrich | @Utku: in this case this confirms that the server is misconfigured. | |
| Jun 23, 2017 at 11:19 | comment | added | Utku | The section that starts with "Certificate chain" right? That section contains only a single certificate, which is the leaf certificate. I guess that this means that the server is sending only the leaf certificate. | |
| Jun 23, 2017 at 11:16 | comment | added | Steffen Ullrich | @Utku: This line does not say much by itself. It can also be that openssl does not know the root CA. A short description (subject and issuer) of the certificates sent by the server is shown right at the beginning of the output. | |
| Jun 23, 2017 at 11:05 | vote | accept | Utku | ||
| Jun 23, 2017 at 11:05 | comment | added | Utku |
I ran the command. The output includes the following: verify error:num=20:unable to get local issuer certificate and verify error:num=21:unable to verify the first certificate. I guess that these mean that the server is indeed not sending the chain certificates.
|
|
| Jun 23, 2017 at 10:32 | comment | added | Steffen Ullrich |
@Utku: I don't think that clearing the history clears cached certificates. What is really be sent from the server can be seen by doing a packet capture or using openssl s_client.
|
|
| Jun 23, 2017 at 10:26 | comment | added | Utku | The intermediate certificate was in Windows' certificate store. I have removed the intermediate certificate from Windows' certificate store and the browser was still able to access it. This means that the browser somehow "cached" the intermediate certificate. I have cleared all browser history of Internet Explorer but it was still able to access it. Does clearing the browser history clear any "cached" certificates as well? If yes, then this should mean that the server's configuration is correct right? (that is, the server sends intermediate certificates). | |
| Jun 23, 2017 at 10:18 | history | answered | Steffen Ullrich | CC BY-SA 3.0 |