Description:
Envoy docs/examples mention some common Linux-distro specific filepaths, especially for the system CA bundle /etc/ssl/certs/ca-certificates.crt. These paths are of course not relevant on Windows. This showed up explicitly in #13534 when trying to test/validate all configs from docs. Right now validation of a few examples is disabled on Windows.

What makes this a little complicated on Windows is that the trusted certificate store is not entirely represented with the filesystem, you can get some info, but to get a PEM encoded x509 back out of Windows you need to do some registry querying.

From a quick grep, we use the system CA bundle path a few times in docs examples:

$ pwd
/c/workspace/envoy
$ grep -r ca-certificates.crt .
./docs/BUILD:#       dns-cache-circuit-breaker: "Error: unable to read file: /etc/ssl/certs/ca-certificates.crt"
./docs/root/configuration/http/http_filters/_include/dns-cache-circuit-breaker.yaml:            trusted_ca: {filename: /etc/ssl/certs/ca-certificates.crt}
./docs/root/intro/arch_overview/security/ssl.rst:*/etc/ssl/certs/ca-certificates.crt* is the default path for the system CA bundle on Debian systems.
./docs/root/intro/arch_overview/security/ssl.rst:* /etc/ssl/certs/ca-certificates.crt (Debian/Ubuntu/Gentoo etc.)
./docs/root/intro/arch_overview/security/_include/ssl.yaml:              filename: /etc/ssl/certs/ca-certificates.crt

Should we simply use a cert/filepath that we generate with Bazel in the example and offer a suggestion via comment in the YAML embedded in the docs that mentions the typical Debian/Ubuntu cert path? Template the config files in question and insert a different path on Windows, use a Linux/Windows tab structure in docs to display the differences? Another solution?

Another question is around how we would want to load system trusted certs into Envoy (which should possibly be a separate issue, let me know what you think and I will make one). Adding a new DataSource type could be possible, maybe we could maybe accept a cert store path like powershell (e.g. Cert:\LocalMachine\Root) to load from but detecting changes like we do with files to reload configuration may not be similarly possible (haven't looked into it). Do we want to instead force Windows users to extract certificates and write them to disk as PEM encoded x509 certs? (this is what they would have to do today)

Relevant Links:

• Example of a docs page that uses the typical Debian/Ubuntu/etc. system CA bundle: https://www.envoyproxy.io/docs/envoy/v1.16.0/intro/arch_overview/security/ssl#example-configuration
• Original PR that brought this issue up: docs: Unexclude remaining configs from validation #13534
  • See this diff: https://github.com/envoyproxy/envoy/pull/13534/files#diff-92ae908436b530a281eddfb50321c5a055ad4fa90e0194f0651b58ac39341800R20-R21