Description
SCEP messages with messageType 17 (RENEWAL_REQ, RFC 8894 §3.3.1) are not implemented. ScepServiceImpl.processPkiOperation recognizes the type in the challenge password / renewal validation branch, but the issuance dispatch below it only handles PKCS_REQ (19) and CERT_POLL (20), so a type 17 message falls through to the final else and is answered with Unsupported Operation. The requested operation is not supported and failInfo=badRequest.
Only the draft-nourse-scep-23 §3.1.1.2 renewal flow works today — a PKCS_REQ signed with the key of the certificate being replaced, which is what sscep and jscep send. GetCACaps already advertises Renewal, so a client that implements the RFC 8894 message type is told the capability exists and then rejected.
Found while fixing #1887 (renewal PKCSReq crashed on a missing challenge password); the fix there covers the PKCS_REQ renewal path only.
Use Case
A SCEP client that implements RFC 8894 rather than the 2011 draft sends RENEWAL_REQ to renew its certificate. It should be served, not rejected, given the platform advertises Renewal in GetCACaps.
Acceptance Criteria
- A
RENEWAL_REQ (17) message carrying a valid PKCS#10 request and signed with the key of the certificate being replaced results in an issued certificate returned in a SUCCESS CertRep.
- Renewal authentication and policy for type 17 reuse the same path as the PKCS_REQ renewal flow (
ScepServiceImpl.authenticateRenewal): signer certificate resolved from the inventory, CMS signature verified, archived / pending state rejected, subject DN matched, renewal timeframe enforced.
- Manual approval configured on the SCEP profile produces a CSR and a PENDING response for type 17, consistent with
PKCS_REQ.
- A
RENEWAL_REQ whose signer certificate is unknown to the platform is rejected with a SCEP FAILURE, not treated as an initial enrollment.
GetCACaps continues to advertise Renewal, and the advertised capability is now truthful for both message types.- Test coverage for the type 17 dispatch path.
Description
SCEP messages with
messageType17 (RENEWAL_REQ, RFC 8894 §3.3.1) are not implemented.ScepServiceImpl.processPkiOperationrecognizes the type in the challenge password / renewal validation branch, but the issuance dispatch below it only handlesPKCS_REQ(19) andCERT_POLL(20), so a type 17 message falls through to the finalelseand is answered withUnsupported Operation. The requested operation is not supportedandfailInfo=badRequest.Only the draft-nourse-scep-23 §3.1.1.2 renewal flow works today — a
PKCS_REQsigned with the key of the certificate being replaced, which is what sscep and jscep send.GetCACapsalready advertisesRenewal, so a client that implements the RFC 8894 message type is told the capability exists and then rejected.Found while fixing #1887 (renewal PKCSReq crashed on a missing challenge password); the fix there covers the PKCS_REQ renewal path only.
Use Case
A SCEP client that implements RFC 8894 rather than the 2011 draft sends
RENEWAL_REQto renew its certificate. It should be served, not rejected, given the platform advertisesRenewalinGetCACaps.Acceptance Criteria
RENEWAL_REQ(17) message carrying a valid PKCS#10 request and signed with the key of the certificate being replaced results in an issued certificate returned in a SUCCESSCertRep.ScepServiceImpl.authenticateRenewal): signer certificate resolved from the inventory, CMS signature verified, archived / pending state rejected, subject DN matched, renewal timeframe enforced.PKCS_REQ.RENEWAL_REQwhose signer certificate is unknown to the platform is rejected with a SCEP FAILURE, not treated as an initial enrollment.GetCACapscontinues to advertiseRenewal, and the advertised capability is now truthful for both message types.