Support for ECDSA ciphers

[mariusz-gomse-centra]

Hello,

I would like to have my NIC release configuration as:

controller:
  config:
    entries:
      ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384"

I've got also my VirtualServer configured this way:

spec:
  cert-manager:
    cluster-issuer: my-issuer

Right now only 3/6 ciphers are working (RSA) and afaik the reason is that certificate generated by VirtualServer is an RSA certfiicate (Signature Algorithm: sha256WithRSAEncryption).

What I would like to do is to add 2nd certificate for ECDSA. I've got one idea (below) but before I'll implement I wanted to ask you is there any simpler way to do it? (maybe I'm missing something)

My idea is to use https://github.com/nginxinc/kubernetes-ingress/tree/v3.4.2/examples/shared-examples/custom-templates and somehow (not sure yet how) add to the virtualserver-template another ssl_certificate and ssl_certificate_key (before create on my side ecdsa certificate - https://cert-manager.io/docs/faq/#is-ecc-elliptic-curve-cryptography-supported). As you can see it is quite complicated - much better will be to have possibility:

• to add to VS (.spec.tls) array of tls definitions
• to add to VS (.spec.tls.cert-manager) privateKey.algorythm

[mariusz-gomse-centra]

ℹ️ I managed to have hybrid certificates (RSA & ECDSA) by:

• adding manually certificate (I'm using cert-manager)

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ecdsa
spec:
  dnsNames:
    - example.com
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt
  secretName: ecdsa
  privateKey:
    algorithm: ECDSA
    size: 384

• adding kind of dummy VirtualServer (so NIC will have secrets in the /etc/nginx/secrets

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: ecdsa
spec:
  host: ecdsa.example.com
  tls:
    secret: ecdsa
  ingressClassName: ${ingress_class_name}

• adding server-snippets in my original VS:

  server-snippets: |
    ssl_certificate /etc/nginx/secrets/default-ecdsa;
    ssl_certificate_key /etc/nginx/secrets/${namespace}-ecdsa;

I tested it with oneliner:

string=ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384; IFS=":"; for c in $string; do echo "${c}: "; curl --tlsv1.2 --tls-max 1.2 https://<MY_URL> --ciphers "${c}"; echo; done

However still it is kind of hacking - do you think I should create an issue for it?

[jasonwilliams14]

@mariusz-gomse-centra Hello there.

Just a small note:

is that certificate generated by VirtualServer is an RSA certfiicate

We do not actually generate the certificate. That would be the provider generating the certificate. In this case you are using cert-manager.
We just "load in" the certificate into the server block and use the NGINX ssl_ directives for the .cert and .key. For this scenario, it sounds like you want a ECDSA cert (second cert) to be used within your virtualServer resource.

I am assuming you want to have two entires for ssl_certificate and ssl_certificate_key in your server block, the second cert focused for elliptical curve support?
If your goal is to support multiple certificates, this would be a request for enhancement (RFE) for virtualServer resource to support multiple certificates in the .yaml syntax.

The way you have it now using snippets, would be the current way to implement your goal.

Let me know if that helps.

[mariusz-gomse-centra]

@jasonwilliams14 yes - everything is clear :) thank you very much

I am assuming you want to have two entires for ssl_certificate and ssl_certificate_key in your server block, the second cert focused for elliptical curve support?

Yes, you are assmming well

[mariusz-gomse-centra]

PS: I created #5118

[jasonwilliams14]

sounds good.
We will take a look and review on our side.
Thank you very much. We appreciate it.

[shaun-nx]

Closing this discussion as it has been answered, and the follow up discussion is here: #5133