Generate Consul Connect certificates which are verifiable by HTTP proxies (like Nginx)

[komapa]

Feature Description

We use both Consul Connect with the envoy proxy (via Nomad) but we also have some clients that implement mTLS natively (nginx). It happens that we also have the use case where we talk from Nginx to a connect enabled service via mTLS but one problem we faced is the fact that Nginx cannot validate the SSL certificate of the remote. This seems to happen because the Consul Connect service certificates have only the URI:spiffe:// but not any DNS names that Nginx can validate against.

Use Case(s)

We want to make sure Nginx can validate the mTLS connection fully and not to have to depend on proxy_ssl_verify off;

This currently fails:

proxy_ssl_certificate         /secrets/nginx/connect-client.pem;
proxy_ssl_certificate_key     /secrets/nginx/connect-client.key;
proxy_ssl_trusted_certificate /secrets/nginx/connect-ca.pem;

proxy_ssl_verify on;
proxy_ssl_verify_depth 2;
proxy_ssl_server_name on;
proxy_ssl_name "service.consul.local";

Consul certificates look like this for us:

openssl x509 -in cert.pem -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            5f:0b:22:8a:74:28:d5:0a:49:63:85:9e:01:af:3e:00:51:48:5e:55
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = pri-113w5s9.vault.ca.1a0e6cff.consul
        Validity
            Not Before: Jul 19 16:41:18 2022 GMT
            Not After : Jul 22 16:41:48 2022 GMT
        Subject:
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:b3:15:26:f0:05:61:c8:92:6c:30:d5:f8:7d:fd:
                    b3:41:13:48:0a:2d:f1:39:49:f0:cd:6e:ed:33:0a:
                    b0:2c:2a:37:02:3e:b6:9f:96:90:5b:4e:39:47:42:
                    65:3b:17:b2:24:57:e0:bb:8d:df:63:68:38:ef:6c:
                    f0:96:b2:55:3f
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                78:65:7E:3F:F9:54:05:67:00:27:12:AA:DB:3B:25:CA:AE:AC:C0:7D
            X509v3 Authority Key Identifier:
                keyid:40:CD:F9:42:3B:32:D4:4B:BE:58:CF:0B:7A:35:0F:8E:A6:E5:69:2A

            X509v3 Subject Alternative Name: critical
                URI:spiffe://1a0e6cff-13ab-1866-636e-3f599997dcc4.consul/ns/default/dc/us-east-stag/svc/service
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:20:71:2e:d1:aa:bf:f9:71:f5:e3:17:55:34:c3:37:
         8b:0c:3a:60:4f:1c:05:a4:e5:9a:81:6b:ca:bb:33:2b:44:9a:
         02:21:00:e2:ba:67:46:b4:ae:e0:59:ed:c8:35:a7:66:23:c9:
         4a:c6:5e:74:5c:25:bb:0e:71:77:b2:2c:f7:ef:a3:7d:ba

[Amier3]

hey @kirooshu

I think this is partly intentional -- and this could be solved by creating an ingress gateway to allow nginx to reference services within the service mesh. The ingress gateway creates a DNS subdomain for you to access services.

[komapa]

Thank you for the reply @Amier3 and we are definitely using the ingress gateway (and working with HashiSupport on some issues with it which are unrelated to this ticket).

This is obviously for high performance purposes. We do not want to have to go through yet another hop (proxy) and this is why we are implementing connect native in nginx because we can also just have an envoy sidecar next to nginx and let that sidecar do the mTLS and validation. For some of our mesh setup we want to be able to avoid the envoy sidecar like our load balancers which handle production/customer traffic.

Does this make sense?

[Amier3]

@kirooshu

Yeah that makes perfect sense and I think that's a very valid use case. I'll bring this up with the team in our next meeting and let you know our general thoughts afterwards. Thank you for giving us your feedback 😄