Glad you get it working but take a look to my previous post:
This:
SSLCertificateChainFile “/home/pc_apa01/instance/https/ca/fullchain.pem”
Should be:
SSLCertificateChainFile “/home/pc_apa01/instance/https/ca/chain.pem”
1 Like
@sahsanu, can you help explain what has changed here. I have a few servers that show this issue starting last night with no changes made on my end. One is a 3rd party server which has limited configuration options.
We need to understand why something that used to work now doesn’t.
Thank you for your help.
[edit]
After looking into this further I suspect that most clients have traditionally been able to obtain the intermediate certificates when the chain was not provided. For some reason, several clients are unable to do this starting in the last 24 hours or so. As stated earlier in this thread, Firefox still works. As far as I can see, Chrome and Safari (and other derivatives) do not.
On one of my servers, I began including the full chain and everything is happy (the solution @sahsanu gave). I’m sure this is the correct way to proceed but I am very curious why clients suddenly stopped being able to obtain the information for themselves.
@trpropst If the end user has already visited a website that uses a Let’s Encrypt certificate that has configured the chain correctly, their browser will cache it, and it will be able to use it when the user visits another website that hasn’t configured the chain correctly.
If the user hasn’t visited a site that uses Let’s Encrypt recently or has cleared their private data, the intermediate certificate won’t be in the browser’s cache and users will get a security error when visiting a site without the chain configured correctly.
Quite often web developers need to clear their cache to test something else on their website, and then suddenly notice their chain is misconfigured. I often test my websites in completely clean browser profiles (or for IE/Edge, a brand new Windows user account), as caching and weird extensions/settings in your normal browser environment often masks issues like these.
1 Like
Thanks for that information, @Patches. If I understand you, it would seem that many people on this thread saw their caches cleared on the same day. I’ve gotten reports from some customers who also saw this issue so that would mean that their cache was cleared in the same time frame. Is that correct? If so, is it plausible that all these users had their cache cleared at the same time?
[edit]
I just went to my site that is not sending the full chain on Chrome where I see the error. I then went to letsencrypt.org in that browser where I do get the full chain. Then going back to my site, I still see the error indicating that the chain is not cached.
-----BEGIN UNSUBSTANTIATED THEORY-----
I’ve noticed that recently http://cert.int-x3.letsencrypt.org/ has started redirecting to HTTPS. Is it possible that some browsers/clients don’t support that, and they were previously able to use the Authority Information Access field to recover from a missing intermediate, but are now unable to do so?
-----END UNSUBSTANTIATED THEORY-----
5 Likes
That’s a cool theory! I don’t know if it’s true, but it’s cool.
My unsubstantiated theory is that a software update to the browser or TLS library emptied the intermediate cache, or broke caching, or broke fetching.
1 Like
Edit: Ping @jsha or @cpu? Half dozen+ people with incomplete chains are suddenly reporting issues at the same time. @jmorahan has the theory that http://cert.int-x3.letsencrypt.org/ redirecting to HTTPS is breaking AIA chasing on major platforms like iOS Chrome because maybe they only support chasing over HTTP. I think he’s probably right.
I like your theory better than mine, and I think you might be right.
Disclaimer: I don’t know Chrome’s code base AT ALL, and maybe it uses a different library on iOS or something. I just went searching for keywords. That said…
// Policy for which URLs are allowed to be fetched. This is called both for the
// initial URL and for each redirect. Returns OK on success or a net error
// code on failure.
Error CanFetchUrl(const GURL& url) {
if (!url.SchemeIs("http"))
return ERR_DISALLOWED_URL_SCHEME;
return OK;
}
That sounds pretty clear…
9 Likes
That sounds reasonable. I’ll call our ops team.
8 Likes
This appears to be fixed now.
$ curl -s -o /dev/null -v http://cert.int-x3.letsencrypt.org/ 2>&1 | grep HTTP
> GET / HTTP/1.1
< HTTP/1.1 200 OK
1 Like
thank you. this explains what happened Sunday.
all of my web servers were serving the chain cert as well (via Apache httpd SSLCertificateChainFile). but I had a dovecot providing IMAPS that wasn’t (just had the cert and not the chain cert appended at the end).
And that IMAPS worked saturday but suddently failed Sunday. Was using the Apple mail client on IOS 11.2.6. Making dovecot use a chain cert (server cert with the intermediate appended) made Apple mail work again.
And I validated that with the rollback mentioned above, I could change dovecot back to just the server cert and Apple mail still worked. I then put the chain cert back in place since it is more correct.
2 Likes
Following up: Big thanks to our community here, especially @jmorahan and @mnordhoff, for spotting and accurately diagnosing the issue. It makes me happy to have so many smart, dedicated people looking out for each other here. <3
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.