4 ms·

This is a common server misconfiguration that clients can often work in spite of, due to certificate caching and explicit workarounds (AIA Fetching), and I sort

This is a common server misconfiguration that clients can often work in spite of, due to certificate caching and explicit workarounds (AIA Fetching), and I sort of wish they wouldn't. I'm no expert so I'm sure people will tell me why this isn't workable, but it seems to me that if browsers were to actively require that a server provides any required intermediate certificates people would fix their servers, as they wouldn't work at all.

tinus_hn 4y ago
It seems extremely easy to detect this problem and pop-up an annoying, ugly but dismissible warning.
jeroenhd 4y ago
I don't think servers should be breaking working websites just to be pedantic if they can already work around these issues. They should definitely put warnings about these kinds of faults in the dev console, though. I don't think developers that don't get their certs in order will even bother with opening the dev tools on their website, but it's the best place I can think of. Google and other partnering websites also have a position to prevent these failures. Many websites decide to include Google's stalking scripts and it should be trivial for Google to put scan the domains these scripts run on and warn the website administrators about their bad configuration. This poses a problem for split horizon intranet websites, but in those cases you'll probably never run into the issue due to the weird setup anyway.
- mschuster91 4y ago
  > Many websites decide to include Google's stalking scripts and it should be trivial for Google to put scan the domains these scripts run on and warn the website administrators about their bad configuration. The Google Webmaster Console actually does warn you about all issues regarding your site's ability to be indexed, including SSL issues.
mcpherrinm 4y ago
One issue is that there’s no “one true list of intermediates” for a server to include in the handshake, as it’s not possible to always know what roots a client trusts. The client authors (of browsers) tend to care about making their software easy to use and avoid errors. And there’s a pretty small set of clients. TLS servers on the other hand often just serve whatever you put in a config file. A chain that works for them on an up to date Firefox may not work for an older android phone, but the server administrator may not be aware of the trade off they’ve made. My personal opinion is that the tools for debugging for server authors aren’t good enough yet. I’m one of the authors of the certigo tool mentioned in the article, which was written out of frustration from a lack of other tools. Even then, I think it’s not good enough and I hope this class of issue is one we can illustrate better. SSL Labs probably does the best here.
- hamburglar 4y ago
  > One issue is that there’s no “one true list of intermediates” for a server to include in the handshake This doesn't make sense. Given a cert that was issued from an intermediate, there is exactly one intermediate that issued it, and that intermediate must be in the handshake. If that intermediate was issued from another intermediate, that next intermediate must also be in the handshake. And so on. There's no ambiguity here. Your server is required to send a fully-formed cert chain whose final cert is signed by one of the roots the client trusts. It's entirely possible to run a PKI where the set of intermediates is known by nobody and is unbounded and ephemeral, so long as everyone who is given a cert is given the intermediate chain that issued it. The burden is on the bearer of the cert to include it in the handshake. All problems here have arisen from a misunderstanding that causes people to think the intermediates should be well-known or obtainable publicly. That is simply not true. > it’s not possible to always know what roots a client trusts It doesn't matter. You send the chain that issued your cert, not what you expect the client to trust. If the client trusts it, you're good. If not, you're not.
  - hamburglar 4y ago
    TFA complains about browser intermediate cache behavior but doesn't seem to realize that if you're relying on browser intermediate caching at all, your server is misconfigured. The lesson should be "fix your server", not "those darn browsers."

tinus_hn 4y ago

It seems extremely easy to detect this problem and pop-up an annoying, ugly but dismissible warning.

jeroenhd 4y ago

I don't think servers should be breaking working websites just to be pedantic if they can already work around these issues. They should definitely put warnings about these kinds of faults in the dev console, though. I don't think developers that don't get their certs in order will even bother with opening the dev tools on their website, but it's the best place I can think of. Google and other partnering websites also have a position to prevent these failures. Many websites decide to include Google's stalking scripts and it should be trivial for Google to put scan the domains these scripts run on and warn the website administrators about their bad configuration. This poses a problem for split horizon intranet websites, but in those cases you'll probably never run into the issue due to the weird setup anyway.

mschuster91 4y ago
> Many websites decide to include Google's stalking scripts and it should be trivial for Google to put scan the domains these scripts run on and warn the website administrators about their bad configuration. The Google Webmaster Console actually does warn you about all issues regarding your site's ability to be indexed, including SSL issues.

mcpherrinm 4y ago

One issue is that there’s no “one true list of intermediates” for a server to include in the handshake, as it’s not possible to always know what roots a client trusts. The client authors (of browsers) tend to care about making their software easy to use and avoid errors. And there’s a pretty small set of clients. TLS servers on the other hand often just serve whatever you put in a config file. A chain that works for them on an up to date Firefox may not work for an older android phone, but the server administrator may not be aware of the trade off they’ve made. My personal opinion is that the tools for debugging for server authors aren’t good enough yet. I’m one of the authors of the certigo tool mentioned in the article, which was written out of frustration from a lack of other tools. Even then, I think it’s not good enough and I hope this class of issue is one we can illustrate better. SSL Labs probably does the best here.

hamburglar 4y ago
> One issue is that there’s no “one true list of intermediates” for a server to include in the handshake This doesn't make sense. Given a cert that was issued from an intermediate, there is exactly one intermediate that issued it, and that intermediate must be in the handshake. If that intermediate was issued from another intermediate, that next intermediate must also be in the handshake. And so on. There's no ambiguity here. Your server is required to send a fully-formed cert chain whose final cert is signed by one of the roots the client trusts. It's entirely possible to run a PKI where the set of intermediates is known by nobody and is unbounded and ephemeral, so long as everyone who is given a cert is given the intermediate chain that issued it. The burden is on the bearer of the cert to include it in the handshake. All problems here have arisen from a misunderstanding that causes people to think the intermediates should be well-known or obtainable publicly. That is simply not true. > it’s not possible to always know what roots a client trusts It doesn't matter. You send the chain that issued your cert, not what you expect the client to trust. If the client trusts it, you're good. If not, you're not.
- hamburglar 4y ago
  TFA complains about browser intermediate cache behavior but doesn't seem to realize that if you're relying on browser intermediate caching at all, your server is misconfigured. The lesson should be "fix your server", not "those darn browsers."