fix WillHaveCertificateForServerName check to be strict match for derived cert name

[wasaga]

Summary

An Ingress Controller has the following runtime environment specifics:

• port-mapped (8443:443) due to non-root container requirements,
• the authenticate service URL may not be accessible from inside the cluster - one example is performing Quickstart with https://authenticate.localhost.pomerium.io in a popular Docker Desktop environment

The authenticate endpoint is essential as it hosts /.well-known/pomerium/hpke-public-key which is consumed by Proxy and Authorize components.

In order to overcome that limitation, IC sets authenticate_internal_service_url to https://localhost:8443.

There are two issues this PR addresses:

Current implementation of the WillHaveCert assumed that it was sufficient just to check whether autoTLS is enabled, as in that case there would be a wildcard cert, signed by the derived CA.

The wildcard CA is indeed installed, however, if there are other wildcard certs added to the config, they would be presented instead. I think it might be related to full_scan_certs_on_tls_mismatch

If no cert is selected from certs that matches wildcard name, the candidate cert is selected for handshake if it is present. If there is no candidate, check full_scan_certs_on_sni_mismatch, go to full scan all certificates if it is enabled, otherwise pick the first certificate for handshake.

This PR changes the behaviour of the WillHaveCertificateForServerName (which is only currently used by HPKE Key Fetcher) to only promise the.

Couple notes:

1. Maybe we should return a full set of certificates via cfg.AllCertificates(), moving derived cert generation out of the Envoy Config Builder to Config, and making this function only check the certs returned by the cfg.AllCertificates() so that it would be deterministic.
2. The cryptutil.MatchesServerName used by tests naturally cannot reflect how the actual Envoy would perform TLS matching. We may want to do something about it as well.
3. This issue does not seem to be unit testable, requires an integration test.

Related issues

Fixes pomerium/ingress-controller#629

User Explanation

Checklist

• reference any related issues
• updated docs
• updated unit tests
• updated UPGRADING.md
• add appropriate tag (improvement / bug / etc)
• ready for review

[coveralls]

Coverage: 63.751% (+0.07%) from 63.68% when pulling 66d4a8c on wasaga/fix-will-have-cert into 794298c on main.