NO-JIRA: Add ECDSA P-256 support for certificates and CAs

[fabiendupont]

Extends the crypto package to generate ECDSA P-256 key pairs and certificates in addition to existing RSA support, enabling OpenShift components to use modern elliptic curve cryptography.

Changes

Key generation:

• KeyAlgorithm type for algorithm selection (AlgorithmRSA, AlgorithmECDSA)
• ECDSA P-256 key pair generation with proper SubjectKeyIdentifier hashing (SHA-1 per RFC 5280)
• newKeyPairWithAlgorithm() for unified key generation dispatch

Server certificates:

• CA.MakeServerCertWithAlgorithm() and CA.MakeServerCertForDurationWithAlgorithm()

CA certificates:

• MakeSelfSignedCAConfigForDurationWithAlgorithm() for ECDSA root CAs
• MakeCAConfigForDurationWithAlgorithm() for ECDSA intermediate CAs

Template cleanup:

• Removed hardcoded SignatureAlgorithm: x509.SHA256WithRSA from certificate templates
• x509.CreateCertificate infers the correct algorithm from the signing key (SHA256WithRSA for RSA, ECDSAWithSHA256 for ECDSA P-256)
• This is backward compatible and enables correct cross-algorithm signing (e.g. RSA CA signing ECDSA leaf certs)

All existing APIs remain unchanged — new functionality is opt-in through *WithAlgorithm variants.

Test coverage

• Key generation, signature algorithm detection, and ECDSA PEM encoding
• Server certs: RSA CA + ECDSA leaf, ECDSA CA + RSA leaf, ECDSA CA + ECDSA leaf
• MakeServerCertForDurationWithAlgorithm (production code path from certrotation/target.go)
• Self-signed ECDSA CAs and mixed-algorithm intermediate CA chains
• Backwards compatibility: all existing RSA tests pass unchanged

[openshift-ci-robot]

@fabiendupont: This pull request explicitly references no jira issue.

Details

In response to this:

Extends the crypto package to generate ECDSA P-256 key pairs in addition to existing RSA support, enabling OpenShift components to use modern elliptic curve cryptography.

Adds:

• KeyAlgorithm type for algorithm selection (RSA, ECDSA)
• newECDSAKeyPair() and newECDSAKeyPairWithHash() functions using P-256 curve
• newKeyPairWithAlgorithm() for unified key generation
• signatureAlgorithmForKey() for automatic algorithm detection
• CA.MakeServerCertWithAlgorithm() and CA.MakeServerCertForDurationWithAlgorithm()

All existing APIs remain unchanged, preserving 100% backwards compatibility. New functionality is opt-in through *WithAlgorithm functions.

ECDSA P-256 provides equivalent security to 3072-bit RSA with smaller keys (~87% smaller), faster operations, and better performance. This prepares OpenShift for modern TLS deployments and aligns with industry best practices.

Test coverage includes:

• Unit tests for key generation, signature algorithm detection, and encoding
• Integration tests for RSA CA + ECDSA server and vice versa
• Backwards compatibility tests verifying existing RSA functionality

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: fabiendupont
Once this PR has been reviewed and has the lgtm label, please assign p0lyn0mial for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[p0lyn0mial]

Hmm, I might be wrong, but it looks like MakeServerCert and MakeServerCertWithAlgorithm are very similar. There are two differences. The first is the key algorithm, and the second is that MakeServerCertWithAlgorithm sets the signature algorithm.

I’m wondering if it would make sense to create a private common function for both. I think something like the following could work:

func (ca *CA) MakeServerCertWithAlgorithm(hostnames sets.Set[string], lifetime time.Duration, algorithm KeyAlgorithm, fns ...CertificateExtensionFunc) (*TLSCertificateConfig, error) {
	sigFn := func(template *x509.Certificate) error {
		template.SignatureAlgorithm = signatureAlgorithmForKey(ca.Config.Key)
		return nil
	}
	fns = append([]CertificateExtensionFunc{sigFn}, fns...)
	return ca.makeServerCertWithAlgorithm(hostnames, lifetime, algorithm, fns...)
}

and

func (ca *CA) MakeServerCert(hostnames sets.Set[string], lifetime time.Duration, fns ...CertificateExtensionFunc) (*TLSCertificateConfig, error) {
	return ca.makeServerCertWithAlgorithm(hostnames, lifetime, AlgorithmRSA, fns...)
}

[p0lyn0mial]

Since this is a private method I think we could return an error for unsupported algorithms.

[p0lyn0mial]

am I right that the differences between MakeServerCertForDuration and MakeServerCertForDurationWithAlgorithm mirror those between MakeServerCert and MakeServerCertWithAlgorithm (key algorithm and signature algorithm)? If so, could we refactor them in the same way?

[fabiendupont]

Good feedback. Makes sense.

[fabiendupont]

@p0lyn0mial, I extended the changes to add the ECDSA CA support as well, so we can have a full ECDSA chain.

[p0lyn0mial]

OK. I think that the SignatureAlgorithm will be set by x509.CreateCertificate and our unit tests assert this. Is that correct ?

[fabiendupont]

Yes, that's correct. When SignatureAlgorithm is zero-valued in the template, x509.CreateCertificate infers it from the signing key — SHA256WithRSA for RSA keys, ECDSAWithSHA256 for ECDSA P-256 keys. Our tests assert the resulting SignatureAlgorithm on the generated certs for all combinations (RSA CA + RSA leaf, RSA CA + ECDSA leaf, ECDSA CA + RSA leaf, ECDSA CA + ECDSA leaf).

[p0lyn0mial]

It looks like the error message will take the form of unsupported key algorithm: 2, which isn't meaningful to someone debugging. Is there a way to make it more descriptive ?

[fabiendupont]

Good point. This default branch can only be reached if a new KeyAlgorithm constant is added to the const block (e.g. AlgorithmEd25519) without adding a corresponding case in this switch.

Since newKeyPairWithAlgorithm is private and the callers always pass one of the defined constants, a developer hitting this error would know they forgot to wire up their new algorithm.

I added a comment to clarify that, and kept %d so the numeric value is visible for debugging.

[p0lyn0mial]

I might be wrong but
MakeSelfSignedCAConfigForDurationWithAlgorithm & MakeCAConfigForDurationWithAlgorithm use newSigningCertificateTemplateForDuration which sets

KeyUsage: x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature | x509.KeyUsageCertSign,

I found RFC 5480 where Section 3 says:

If the keyUsage extension is present in a Certification Authority
   (CA) certificate that indicates id-ecPublicKey in
   SubjectPublicKeyInfo, then any combination of the following values
   MAY be present:

     digitalSignature;
     nonRepudiation;
     keyAgreement;
     keyCertSign; and
     cRLSign.

which tells me that x509.KeyUsageKeyEncipherment (in newSigningCertificateTemplateForDuration) should not be used for ECDSA only for RSA.

[fabiendupont]

Added a keyUsageForAlgorithm helper that returns:

• RSA: KeyEncipherment | DigitalSignature
• ECDSA: DigitalSignature only

Per RFC 5480 Section 3, KeyEncipherment is not valid for ECDSA keys. The CA, server, and intermediate cert templates now receive the algorithm and set KeyUsage accordingly. Tests assert the correct KeyUsage for both RSA and ECDSA certs.

The public client cert template functions (NewClientCertificateTemplate / NewClientCertificateTemplateForDuration) are unchanged since client cert creation currently always uses RSA.

[p0lyn0mial]

I think the issue described at https://github.com/openshift/library-go/pull/2116/changes#r2826380341 is also applicable to the server, client cert template.

[openshift-ci]

@fabiendupont: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.