Cipher order prevents certs pod from starting

[wilsondy]

Subject of the issue

Cipher order complaints from step-certificates nixes startup

Environment

• Kubernetes version: 1.19 Server
• Cloud provider or hardware configuration: EKS/Fargate
• OS (e.g., from /etc/os-release):
  NAME="Alpine Linux"
  ID=alpine
  VERSION_ID=3.11.11
  PRETTY_NAME="Alpine Linux v3.11"
• Kernel: Linux 4.14.243-185.433.amzn2.x86_64 Autocert for updating the secret that has the certificates #1 SMP x86_64 Linux
• Install tools: Helm via AWS CDK
• Other:

Steps to reproduce

Deploy Autocert Helm Chart with

(in step-certificates chart)
ca.db.enabled = false
ca.db.persistent = false

Expected behaviour

Step certs pod should boot with default HELM chart ?

Actual behaviour

Pod dies after this error:
2021/09/13 19:24:02 unexpected error: http2: TLSConfig.CipherSuites index 1 contains an HTTP/2-approved cipher suite (0xc02b), but it comes after unapproved cipher suites. With this configuration, clients that don't support previous, approved cipher suites may be given an unapproved one and reject the connection.

Additional context

This order is the default and problematic:
"tls": { "cipherSuites": [ "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256", "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256" ],
If I patch the ConfigMap (step/configmaps/autocert-step-certificates-config) and reverse the Ciphers, all is well. I'm trying to do this in CDK as a permanent workaround, but not successful yet. I'm struggling to make out where ca.json comes from in the first place.

[maraino]

The problematic code is in the older version of CA and in the way Go was handling the order of cipher suites (see golang/net@16afe75)

It's very possible that recompiling this with Go 1.17 will automatically solve the issue.