cert-manager supports generating PKCS#12 and JKS keystores with "passwords", which are not really security features but are required for some applications to be able to parse the files.

As part of our security audit, we stopped using a deprecated function in go-pkcs12 - and during that we noticed that we were using RC2 encryption and that go-pkcs12 was now recommending using DES for the widest compatibility.

cert-manager is now choosing to use RC2 to keep backwards compatibility with what we did previously. But there's a clear need to support DES for future compatibility now that openssl has dropped rc2, and some users might want to use AES which the library exposes.

After a discussion in the biweekly meeting on 2023-11-30, we concluded that the safest thing to do is to allow users to choose. This would likely be a new option in the Certificate resource:

Example

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-cert
  namespace: sandbox
spec:
  isCA: true
  commonName: my-cert
  secretName: cert-secret
  duration: 43800h
  privateKey:
    algorithm: ECDSA
    size: 256
  keystores:
    pkcs12:
      create: true
      algorithm: aes | des | rc2
      passwordSecretRef:
        name: notreallysecret
        key: password
  issuerRef:
    name: my-issuer
    kind: ClusterIssuer
    group: cert-manager.io

This adds a new field for PKCS#12 keystores: algorithm, exposing the options in go-pkcs12.

JKS might have something similar under the hood and we should change it if possible - but the library we use currently doesn't seem to expose any options for this.

See also

This comment which sparked this discussion.

/kind feature