JSCEP Renewal Flow

[android...@gmail.com]

HI All,

Can anyone tell me how to go through renew flow? I am aware of enrollment done through JSCEP. I was able to do it successfully with EJBIC.

But need to know about renew.

----------------------------------------------

SCEP draft 23 says -- Appendix D.  Client Certificate Renewal

To renew a client certificate, the client uses the PKCSreq message
   and signs it with the existing client certificate.  The client SHOULD
   use a new keypair when requesting a new certificate.  The client MAY
   request a new certicate using the old keypair
-------------------------------------------------------------
So from this my understanding is that
1. We need to create new key pair for renewal, geneate CSR with new private key (without challenge)
2. While creating PKCSreq..sign it with old private key and send it to server along with old public key?
3. 

     Statement1: The client SHOULD use a new keypair when requesting a new certificate. 

     Statement2: The client MAY request a new certicate using the old keypair.

  is this not conflicting? s1 and s2?

Anyone who already implemented please let me know.

[David Grant]

Hi,

On 24 February 2014 05:16, <android...@gmail.com> wrote:

     Statement1: The client SHOULD use a new keypair when requesting a new certificate. 

     Statement2: The client MAY request a new certicate using the old keypair.

  is this not conflicting? s1 and s2?

No: it's fine.  It's basically saying that you should you use a new key pair, but if you can't, then using the old key pair is OK.  This is the difference between MUST and SHOULD.  Points 1 & 2 are both correct.  Otherwise it wouldn't be a renewal. :)

Dave

[android...@gmail.com]

Ok Thanks.

So in both the cases after generating new key pair/old key pair.

1. So CSR should be generated correspondingly with new key or old private key . right?

2. in both the cases PKCSreq should be signed with old/existing key. right?

[David Grant]

I usually use "entity key pair" and "requester key pair" to distinguish.  The entity key pair is the one that is eventually signed by the CA.  The requester key pair is the ephemeral key pair that you usually ditch after the receiving the entity back from the CA.

So, to answer your questions: the CSR should always be signed with the new private key (the new entity and the PKCSReq should be signed with the old entity private key (which switches to become the requester).  The SCEP server may choose to validate your request by verifying that you're using a previously-issued certificate / key pair combination in the request.

Dave

--

 
---
You received this message because you are subscribed to the Google Groups "jscep Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jscep-suppor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Gomathi Sengodan]

Hi David,

Regarding SCEP renewal am getting one strange issue.

i created CSR using existing keypair and signed the PKCSReq with the exisiting keypair.Then Certificate was successfully renewed and got the new certificate.

Again i tried to renew the same certificate (like above renewal request).but instead of getting new certificate am getting the same certificate in response. It happens only second time if renew the certificate.

Kindly help me with this issue.

Thanks

Gomathi S

[David Grant]

As far as I remember, that's the expected behaviour if your certificate is less than halfway through its validity period.

Dave

For more options, visit https://groups.google.com/d/optout.

[Gomathi Sengodan]

 If thats the case first time renewal also should fail. why from second renewal onwards its failing for the same certificate is wat we are not able to get.

 

Also In server side ,renewal period is set to 0 hours (so can be renewed at any time).

Thanks

Gomathi S

[David Grant]

I'm not sure I'm afraid.  It might be worth speaking to your server vendor.

Dave

[Gomathi Sengodan]

:) Thank You

[Bipin Jethwani]

Gomathi - 

Were you able to resolve the issue of renewal generating the same cert on renewal?

I am facing the same issue, when I remember this working fine some 1 year back now with latest jscep almost immediate renewal is emitting the cert.

While the same code was working fine and generating new cert 1 year back.

Kindly help.

-Thanks

[Wesley Bunton]

So when we talk about renewing a certificate, there's two methods that should work:
1. Request a new certificate (reusing old keys)

2. Request a new certificate (generating new keys)

The option you select, should be based on your org policy for key lifetime, etc. In the event that you want to reuse the keys, then DO NOT generate a new keypair. Instead, simply perform the enrollment, the exact same way you did for the initial certificate, except create and sign your CSR with your existing keys. If you want new keys, you can think of "renewal" as just doing another certificate enrollment. In this case, there is nothing tying the old cert/keypair with the new cert/keypair.

Something I've implemented is "Renew cert with new keys", but I have the user select which certificate they want to renew. When they select their expiring certificate, I pull out the subject name, and auto input that into the CSR. That way the subject name should carry over, but that is just something I've done to create a sense of continuity from the old cert to the new.

I hope that helps.

[Peter Gutmann]

Wesley Bunton <wesley...@gmail.com> writes:

>So when we talk about renewing a certificate, there's two methods that should
>work:
>1. Request a new certificate (reusing old keys)
>2. Request a new certificate (generating new keys)

Note that the email you're replying to was from 2014.  Discussions on this
list and elsewhere identified renewal as a problem area in SCEP since the
original drafts more or less required the server to guess as to whether a
renewal was intended or not, with some SCEP implementations not doing renewal
because it was too uncertain how it was meant to be handled.  The rebooted
SCEP draft fixes this problem by having the client make clear that it wants a
renewal or update of a cert, so this ambiguity shouldn't exist any more for
implementations of the current spec.

Peter.