Currently Pomerium will always generate a wildcard certificate for use
as a fallback certificate.
If any other certificate is configured, this fallback certificate will
not normally be presented, except in the case of a TLS connection where
the client does not include the Server Name Indication (SNI) extension.
All modern browsers support SNI, so in practice this certificate should
never be presented to end users.
However, some network scanning tools will probe connections by IP
addresses (without SNI), and so this fallback certificate may be
presented. The presence of this certificate may be flagged as a problem
in some automated vulnerability scans.
Let's avoid generating this fallback certificate if Pomerium has any
other certificate configured (unless specifically requested by the Auto
TLS option). This should prevent false positive reports from these
particular vulnerability scans.
* envoyconfig: cleanup
* remove listener access log for mtls for insecure server which can't use mtls
* use new functions
* rename method
* refactor common code
When building an upstream validation context for a particular URL, check
whether the hostname is an IP address. If so, configure the SAN match to
use type IP_ADDRESS rather than DNS.
* envoy: check certificates for must-staple flag and drop them if they are missing the response
* Update config/envoyconfig/tls_test.go
Co-authored-by: Denis Mishin <dmishin@pomerium.com>
Co-authored-by: Denis Mishin <dmishin@pomerium.com>
* wip
* wip
* handle wildcards in override name
* remove wait for ready, add comment about sync, force initial sync complete in test
* address comments
