SCEP provisioner always require challenge, can renew revoked certs

[michael-lincata]

I'm running step-ca in a local container, with a SCEP provisioner and RSA CA chain. I've built a Java test client based on XiPKI scep-client library that operates as follows:

• Enroll
  • create a key pair
  • create short-lived self-signed cert
  • use self-signed cert to sign the enroll request to step-ca
  • store key pair and received signed cert from step-ca (to be used for renewal)
• Renewal
  • load existing key pair and cert
  • create new key pair
  • create CSR with the new key pair
  • send renewal request to step-ca, using exiting key/cert for signing

I've noticed 2 behaviors that I'm not sure are expected:

1. step-ca requires the SCEP challenge password to be included in the renewal CSR, but I thought this was optional and the fact that the renewal request is signed by the existing cert would be authentication enough
2. if I revoke the existing cert, my Java client is still able to renew the certificate (note that because of point 1, the CSR used for renewal contains the challenge password)

Are these behaviors exepected, or am I doing something wrong?
Thanks.

[andrico21]

@michael-lincata hit the same issue: according to RFC 8894: Simple Certificate Enrolment Protocol "2.4. Enrolment Authorisation" section:

A client that is performing certificate renewal as per Section 2.5 SHOULD omit the challengePassword but MAY send the originally distributed shared secret in the challengePassword attribute. The SCEP CA MAY authenticate the request using the challengePassword in addition to the previously issued certificate that signs the request

So yep, it's nice to have this setting to control there in step-ca bcuz now its behavior is conflicting with RFC's client part.

btw made yet another version of scepclient with better verbosity - believe it will be a way more useful for understanding how SCEP flow works: https://github.com/andrico21/scepclient

[Trevinlc1997]

I also came across this issue when using the RouterOS scep client, renewing will fail because RouterOS will not send the initial password in renew requests.

[hslatman]

Hey, I might give this a look sometime soon.

The breadth of our SCEP support in step-ca has been growing incrementally based on real-life usage patterns. Most clients that integrate with our stack don't renew through the "native" renew method, but do so by obtaining a new challenge. This is what our implementation is currently optimized for.

[Trevinlc1997]

I appreciate that, it would be nice for a simple json option for the SCEP provisioner to change this functionality to allow the native way or use how its implemented now.