Fixes #2800 [SCEP] Drop redundant signer creation from SCEP decrypter key

[tarokon]

Name of feature:

Not a new feature — removes redundant signer creation from the SCEP provisioner.

Pain or issue this feature alleviates:

Previously, SCEP.Init() built both a crypto.Decrypter and a separate crypto.Signer from the configured DecrypterKeyPEM/DecrypterKeyURI (and set signerCertificate to the decrypter certificate). This signer/certificate pair was never actually needed in the normal path, since authority.go's selectSigner() already falls back to the CA's own default signer (a.signerCertificate, a.defaultSigner) whenever a provisioner doesn't supply one via GetSigner(). Building an extra signer from the decrypter key on every Init() was wasted work (an unnecessary KMS/key operation) and added confusing surface area suggesting SCEP responses were signed with the decrypter key rather than the CA's intermediate.

Why is this important to the project (if not answered above):

Reduces unnecessary key-manager calls during provisioner initialization and simplifies the SCEP provisioner's responsibility to just decryption, making the signing path unambiguous (CA's default signer is always used for signing SCEP responses unless a future distinct-signer option is added).

Is there documentation on how to use this feature? If so, where?

N/A — no user-facing behavior or configuration changes; the signer/signerCertificate/GetSigner() still exist and work as before (returning nil, nil when unset, in which case authority.go falls back to the default signer).

In what environments or workflows is this feature supported?

All environments using the SCEP provisioner with decrypterKeyPEM or decrypterKey (URI) configured — no change in supported platforms/workflows.

In what environments or workflows is this feature explicitly NOT supported (if any)?

Supporting links/other PRs/issues:

💔Thank you!

[hslatman]

This looks like too big of a hammer to support the FIPS-specific requirement to me. We depend on the current configuration, and it has been successfully used on many platforms so far. Ripping the RSA signer out is thus quite risky without extensive multi-platform testing.

My TODOs that were removed in this PR hint at the proper solution: it needs a separate signer certificate and key.

Going to close this with additional remarks in #2800.

[tarokon]

Hi @hslatman ,

Understood, and I agree with your concerns. Let me put together another PR that preserves the current backward-compatible behavior by default, while adding configuration to support separate signing and decryption key pairs.