-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intermediate certificates required to be in CA store #118
Comments
It doesn't though: the certificate chains is traversed and at each step, the certificate is checked against the trusted store. |
Oh, hmm. So maybe we are not getting the intermediate cert from the server for some reason, whereas those browsers are retrieving it. Could that be it? Is this part of TLS negotiation? FYI we are using http-client-tls via http-conduit. |
No, usually the certificates that the server is going to send doesn't depend on the clients. chrome has it own CA store, AFAIK, so it's not surprising. IE on the other hand should use the same source (registry). it would probably be a good idea to have an utility to test which certificates are available in the store. |
This appears to be an older issue but I'd thought I'd add some more (hopefully useful) information. I'm not intimately familiar with the TLS specification so I can't say for sure whether the vendor is at fault and whether or not it is their responsibility to correctly return the intermediate certificates during the SSL negotiation. I believe reason that some web browsers are able to correctly validate the certification chain is due to the "Authority Information Access (1.3.6.1.5.5.7.1.1)" TLS extension being present on the leaf certificate. This extension provides information allowing for missing intermediate certificates to be obtained during the chain validation process, thereby allowing the validation to succeed. I lieu of this extension being implemented in
|
TLS servers are required to return a complete chain up to, but not always including the trusted root CA. https://tools.ietf.org/html/rfc5246#section-7.4.2
https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.4.1
|
Excellent, thanks for the clarity on the specific parts of the TLS specification. I was hoping that would be the case so that we can point out that the vendors are misconfigured. I added the code example workaround in my original message just in case anybody finds themselves working with a truculent vendor and need an alternative solution. Thanks. |
Given this certificate path:
GeoTrust Global CA (issued 2002-05-21) > GeoTrust SSL CA - G3 (issued 2013-11-06) > user certificate
On Windows, browsers (at least Chrome and IE) can access the site without error, but our Haskell program that tries to access the site programmatically fails with a "CA unknown" error. We can resolve the problem by manually installing the intermediate certificate into the Windows system CA store. But that causes serious difficulties when deploying our software inside corporate networks.
Why does tls require also the intermediate certificate to be in the CA store, when standard browsers do not? How would you suggest working around this problem?
The text was updated successfully, but these errors were encountered: