Add a "subject" flag to certificate generator

[jpeach]

trafficstars

"contour certgen" always generates a Contour certificate whose subject is "contour". This means that when the xDS client connects, it needs to expect the "contour" subject, but that won't always happen, depending on how the operator is deploying Contour.

For example, could be useful to deploy multiple Contours with different service names, e.g. "contour-internal" and "contour-external". In this case, we want to generate separate certificates for each Contour and specify the subject names.

root@envoy-external-srbsm:/# curl -v -H "Host: contour-external" --cacert /ca/cacert.pem --cert /certs/tls.crt --key /certs/tls.key https://contour-external:8001/
*   Trying 10.105.12.123...
* Connected to contour-external (10.105.12.123) port 8001 (#0)
* found 1 certificates in /ca/cacert.pem
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* SSL: certificate subject name (contour) does not match target host name 'contour-external'
* Closing connection 0
curl: (51) SSL: certificate subject name (contour) does not match target host name 'contour-external'

So, it would be useful to add a flag to "contour certgen" to specify the subject name of the Contour certificate.

This is a nice-to-have, since AFAICT the envoy xDS client never checks the server certificate's subject name.

[jpeach]

FWIW, xDS client validation is:

                "verify_subject_alt_name": [
                  "contour"
                ]

[danehans]

The same issue exists in the envoy TLS cert:

$ openssl x509 -in envoy-tls.crt -text -noout
...
        Subject: CN=envoy
...
            X509v3 Subject Alternative Name: 
                DNS:envoy, DNS:envoy.projectcontour, DNS:envoy.projectcontour.svc, DNS:envoy.projectcontour.svc.cluster.local
...

[stevesloka]

Another option to solve the cert generation issues might be to export the cert-gen logic from Contour's internal package into pkg package such that the operator can create certs the same way that contour cert-gen is run currently from the job.

Also as @jpeach pointed out, there's another spot that needs updated which tells how the subject_alt_name is verified.

[youngnick]

Yes, the thing to remember for the certs used by certgen is that it's a full TLS handshake, and the Envoys will verify the xDS server name (that is, the Contour server cert name) matches what's configured in Envoy.

In this case, that's more complicated, because we use contour bootstrap to create the config that tells Envoy what it should talk to, including the server name. So, probably, it will be a change to contour certgen to allow the generation of a different name, and a change to contour bootstrap to allow Envoy to set that name (instead of the current hard-coded setting of contour).

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack