Re: [OpenXPKI-users] EST renewal/reenrollment

[Martin Bartosch via OpenXPKI-users]

Hi,


> 5- I do get authenticated through basic auth AND through the certificates i'm 
> passing to cURL.
> But I keep getting back the same certificate.
> No workflow is triggered.
> And in EST.log
>   INF authenticated client DN: CN=same cn,DC=Test 
>  Deployment,DC=OpenXPKI,DC=org [pid=91|ep=[undef]]
> 
> 6- I thought it was my authentication stack causing the issue (using http 
> basic), so I reversed it back to the default (anonymous), and I still don't 
> get the renawal mode, just fetching the same certificate.

When receiving an enrollment request via any of its enrollment interfaces 
OpenXPKI distinguishes initial enrollment, renewal and enrollment on behalf 
mode and branches into the respective branch of the enrollment workflow. You 
can see which path is chosen by examining the enrollment workflow instance and 
its context.

If you send the same CSR (based on the same private key) to an enrollment 
interface, you will get back the existing certificate if the enrollment 
workflow for this key was previously successfully executed.

If you wish to perform a renewal, you need to generate a new private key and a 
new certificate request based on that new key. In order to qualify as a renewal 
from the viewpoint of OpenXPKI, the renewal request must be authenticated by 
the old, existing certificate and key (and the subject must match). In your 
example this means that you would have to call curl with certificate and key 
option pointing to the old certificate. 
Also, the existing certificate validity is considered by the enrollment 
workflow. Depending on configuration, the request may only be accepted if a 
certain remaining validity of the existing certificate is not exceeded.

Cheers

Martin



___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users

Re: [OpenXPKI-users] EST renewal/reenrollment

[Mo Be]

Yes yes yes Martin...
That was it !

I still don't know how to play on that renewal_period though.
By default, enrolled certificates are given a validity of one year.
I added in my EST .yaml an initial validity, something I found in rpc .yaml
 initial_validity: +01 (which translates to 1 day starting from
today)

I left the renewal period intact, i'm not sure how to interpret it
(can be renewed only if within this period of time, that I know for sure)
 renewal_period: 60

In the documentation, I have read it was following this format MMDDhhmmss
in case of absolute date.
I guess in renewal, it's different => YYMMDD (perhaps hhmmss as well),
That translates to 60 days maybe.

*https://openxpki.readthedocs.io/en/develop/reference/configuration/profile.html
*

Still need to figure out exactly what's happening regarding that renwal
period because,
OpenXPKI dates are also not in sync with my VM, which makes it a bit hard
to know what's wrong and why.

Anyway, thanks for your help Martin, got that renewed certificate working

Mohamed


Le mar. 26 mars 2024 à 10:16, Martin Bartosch via OpenXPKI-users <
openxpki-users@lists.sourceforge.net> a écrit :

> Hi,
>
>
> > 5- I do get authenticated through basic auth AND through the
> certificates i'm passing to cURL.
> > But I keep getting back the same certificate.
> > No workflow is triggered.
> > And in EST.log
> >   INF authenticated client DN: CN=same cn,DC=Test
> Deployment,DC=OpenXPKI,DC=org [pid=91|ep=[undef]]
> >
> > 6- I thought it was my authentication stack causing the issue (using
> http basic), so I reversed it back to the default (anonymous), and I still
> don't get the renawal mode, just fetching the same certificate.
>
> When receiving an enrollment request via any of its enrollment interfaces
> OpenXPKI distinguishes initial enrollment, renewal and enrollment on behalf
> mode and branches into the respective branch of the enrollment workflow.
> You can see which path is chosen by examining the enrollment workflow
> instance and its context.
>
> If you send the same CSR (based on the same private key) to an enrollment
> interface, you will get back the existing certificate if the enrollment
> workflow for this key was previously successfully executed.
>
> If you wish to perform a renewal, you need to generate a new private key
> and a new certificate request based on that new key. In order to qualify as
> a renewal from the viewpoint of OpenXPKI, the renewal request must be
> authenticated by the old, existing certificate and key (and the subject
> must match). In your example this means that you would have to call curl
> with certificate and key option pointing to the old certificate.
> Also, the existing certificate validity is considered by the enrollment
> workflow. Depending on configuration, the request may only be accepted if a
> certain remaining validity of the existing certificate is not exceeded.
>
> Cheers
>
> Martin
>
>
>
> ___
> OpenXPKI-users mailing list
> OpenXPKI-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openxpki-users
>
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users

Re: [OpenXPKI-users] EST renewal/reenrollment

[Mo Be]

Hi,

I realized i overlooked the answer : it's the subject and the renewal
period, but there is no mention of the SAN.
I thought that renewal must happen at least if the CSR and the certificate
to be renewed have
- same subject
- same SAN

Which brought me back to RFC 7030 - section 4.2.2
, and made me
wonder if we could make use of the ChangeSubjectName attribute in OpenXPKI.

That being said, do we have a way to check for the SAN as well during
renewal workflow? I'm still looking at different .yaml files but the answer
is no so far.
And does OpenX handle the ChangeUserName attribute ?

Thank you

Le mar. 26 mars 2024 à 13:30, Mo Be  a écrit :

> Yes yes yes Martin...
> That was it !
>
> I still don't know how to play on that renewal_period though.
> By default, enrolled certificates are given a validity of one year.
> I added in my EST .yaml an initial validity, something I found in rpc .yaml
>  initial_validity: +01 (which translates to 1 day starting from
> today)
>
> I left the renewal period intact, i'm not sure how to interpret it
> (can be renewed only if within this period of time, that I know for sure)
>  renewal_period: 60
>
> In the documentation, I have read it was following this format MMDDhhmmss
> in case of absolute date.
> I guess in renewal, it's different => YYMMDD (perhaps hhmmss as well),
> That translates to 60 days maybe.
>
> *https://openxpki.readthedocs.io/en/develop/reference/configuration/profile.html
> *
>
> Still need to figure out exactly what's happening regarding that renwal
> period because,
> OpenXPKI dates are also not in sync with my VM, which makes it a bit hard
> to know what's wrong and why.
>
> Anyway, thanks for your help Martin, got that renewed certificate working
>
> Mohamed
>
>
> Le mar. 26 mars 2024 à 10:16, Martin Bartosch via OpenXPKI-users <
> openxpki-users@lists.sourceforge.net> a écrit :
>
>> Hi,
>>
>>
>> > 5- I do get authenticated through basic auth AND through the
>> certificates i'm passing to cURL.
>> > But I keep getting back the same certificate.
>> > No workflow is triggered.
>> > And in EST.log
>> >   INF authenticated client DN: CN=same cn,DC=Test
>> Deployment,DC=OpenXPKI,DC=org [pid=91|ep=[undef]]
>> >
>> > 6- I thought it was my authentication stack causing the issue (using
>> http basic), so I reversed it back to the default (anonymous), and I still
>> don't get the renawal mode, just fetching the same certificate.
>>
>> When receiving an enrollment request via any of its enrollment interfaces
>> OpenXPKI distinguishes initial enrollment, renewal and enrollment on behalf
>> mode and branches into the respective branch of the enrollment workflow.
>> You can see which path is chosen by examining the enrollment workflow
>> instance and its context.
>>
>> If you send the same CSR (based on the same private key) to an enrollment
>> interface, you will get back the existing certificate if the enrollment
>> workflow for this key was previously successfully executed.
>>
>> If you wish to perform a renewal, you need to generate a new private key
>> and a new certificate request based on that new key. In order to qualify as
>> a renewal from the viewpoint of OpenXPKI, the renewal request must be
>> authenticated by the old, existing certificate and key (and the subject
>> must match). In your example this means that you would have to call curl
>> with certificate and key option pointing to the old certificate.
>> Also, the existing certificate validity is considered by the enrollment
>> workflow. Depending on configuration, the request may only be accepted if a
>> certain remaining validity of the existing certificate is not exceeded.
>>
>> Cheers
>>
>> Martin
>>
>>
>>
>> ___
>> OpenXPKI-users mailing list
>> OpenXPKI-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openxpki-users
>>
>
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users

Re: [OpenXPKI-users] EST renewal/reenrollment

[Oliver Welter]

Hi Mo,

OpenXPKI uses only the DN to decide weather this is a renewal or not but 
than copies over the SAN items from the old certificate to the new 
request, so the renewed certificate is an "exact copy" of the old one, 
besides validity and signature of course.


Handling around the "ChangeSubjectName" extension was not implemented so 
far as we never got a request on this and it does not really match the 
way how approvals are currently handled in the standard workflows. If 
you can make up a proper use case how to handle this, we can of course 
implement this in the workflows.


Oliver

On 06.04.24 14:52, Mo Be wrote:

Hi,

I realized i overlooked the answer : it's the subject and the renewal 
period, but there is no mention of the SAN.
I thought that renewal must happen at least if the CSR and the 
certificate to be renewed have

- same subject
- same SAN

Which brought me back to RFC 7030 - section 4.2.2 
, and 
made me wonder if we could make use of the ChangeSubjectName attribute 
in OpenXPKI.


That being said, do we have a way to check for the SAN as well during 
renewal workflow? I'm still looking at different .yaml files but the 
answer is no so far.

And does OpenX handle the ChangeUserName attribute ?

Thank you

Le mar. 26 mars 2024 à 13:30, Mo Be  a écrit :

Yes yes yes Martin...
That was it !

I still don't know how to play on that renewal_period though.
By default, enrolled certificates are given a validity of one year.
I added in my EST .yaml an initial validity, something I found in
rpc .yaml
 initial_validity: +01 (which translates to 1 day starting
from today)

I left the renewal period intact, i'm not sure how to interpret it
(can be renewed only if within this period of time, that I know
for sure)
 renewal_period: 60

In the documentation, I have read it was following this format
MMDDhhmmss in case of absolute date.
I guess in renewal, it's different => YYMMDD (perhaps hhmmss as
well),
That translates to 60 days maybe.

/https://openxpki.readthedocs.io/en/develop/reference/configuration/profile.html/
Still need to figure out exactly what's happening regarding that
renwal period because,
OpenXPKI dates are also not in sync with my VM, which makes it a
bit hard to know what's wrong and why.
Anyway, thanks for your help Martin, got that renewed certificate
working

Mohamed


Le mar. 26 mars 2024 à 10:16, Martin Bartosch via OpenXPKI-users
 a écrit :

Hi,


> 5- I do get authenticated through basic auth AND through the
certificates i'm passing to cURL.
> But I keep getting back the same certificate.
> No workflow is triggered.
> And in EST.log
>   INF authenticated client DN: CN=same cn,DC=Test
Deployment,DC=OpenXPKI,DC=org [pid=91|ep=[undef]]
>
> 6- I thought it was my authentication stack causing the
issue (using http basic), so I reversed it back to the default
(anonymous), and I still don't get the renawal mode, just
fetching the same certificate.

When receiving an enrollment request via any of its enrollment
interfaces OpenXPKI distinguishes initial enrollment, renewal
and enrollment on behalf mode and branches into the respective
branch of the enrollment workflow. You can see which path is
chosen by examining the enrollment workflow instance and its
context.

If you send the same CSR (based on the same private key) to an
enrollment interface, you will get back the existing
certificate if the enrollment workflow for this key was
previously successfully executed.

If you wish to perform a renewal, you need to generate a new
private key and a new certificate request based on that new
key. In order to qualify as a renewal from the viewpoint of
OpenXPKI, the renewal request must be authenticated by the
old, existing certificate and key (and the subject must
match). In your example this means that you would have to call
curl with certificate and key option pointing to the old
certificate.
Also, the existing certificate validity is considered by the
enrollment workflow. Depending on configuration, the request
may only be accepted if a certain remaining validity of the
existing certificate is not exceeded.

Cheers

Martin



___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users



___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users



--
Pr

Re: [OpenXPKI-users] EST renewal/reenrollment

[Mo Be]

Hi Oli,

I don't know if it could be useful for OpenXPKI though.
It's a nice to have, but, like how complicated would that be in terms of
implemenation...

As for the use-case, from an EST standpoint, it is simply reenrolling with
a different subject or subject alternative name.

If the user, for some reason, wishes to reenroll a certificate about to
expire, but this time, would like use  instead of , then in
this case, the CSR with Change Subject Name attribute could be useful and
would avoid the user to go through the enroll process which would require a
potential different way of authentication, whether it's a challenge
password, or an http basic password, or a certificate signed by another
trusted entity etc.

Mo

Le sam. 6 avr. 2024 à 20:28, Oliver Welter  a écrit :

> Hi Mo,
>
> OpenXPKI uses only the DN to decide weather this is a renewal or not but
> than copies over the SAN items from the old certificate to the new request,
> so the renewed certificate is an "exact copy" of the old one, besides
> validity and signature of course.
>
> Handling around the "ChangeSubjectName" extension was not implemented so
> far as we never got a request on this and it does not really match the way
> how approvals are currently handled in the standard workflows. If you can
> make up a proper use case how to handle this, we can of course implement
> this in the workflows.
>
> Oliver
>
> On 06.04.24 14:52, Mo Be wrote:
>
> Hi,
>
> I realized i overlooked the answer : it's the subject and the renewal
> period, but there is no mention of the SAN.
> I thought that renewal must happen at least if the CSR and the certificate
> to be renewed have
> - same subject
> - same SAN
>
> Which brought me back to RFC 7030 - section 4.2.2
> , and made
> me wonder if we could make use of the ChangeSubjectName attribute in
> OpenXPKI.
>
> That being said, do we have a way to check for the SAN as well during
> renewal workflow? I'm still looking at different .yaml files but the answer
> is no so far.
> And does OpenX handle the ChangeUserName attribute ?
>
> Thank you
>
> Le mar. 26 mars 2024 à 13:30, Mo Be  a écrit :
>
>> Yes yes yes Martin...
>> That was it !
>>
>> I still don't know how to play on that renewal_period though.
>> By default, enrolled certificates are given a validity of one year.
>> I added in my EST .yaml an initial validity, something I found in rpc
>> .yaml
>>  initial_validity: +01 (which translates to 1 day starting from
>> today)
>>
>> I left the renewal period intact, i'm not sure how to interpret it
>> (can be renewed only if within this period of time, that I know for sure)
>>  renewal_period: 60
>>
>> In the documentation, I have read it was following this format MMDDhhmmss
>> in case of absolute date.
>> I guess in renewal, it's different => YYMMDD (perhaps hhmmss as well),
>> That translates to 60 days maybe.
>> *https://openxpki.readthedocs.io/en/develop/reference/configuration/profile.html
>> *
>> Still need to figure out exactly what's happening regarding that renwal
>> period because,
>> OpenXPKI dates are also not in sync with my VM, which makes it a bit hard
>> to know what's wrong and why.
>> Anyway, thanks for your help Martin, got that renewed certificate working
>>
>> Mohamed
>>
>>
>> Le mar. 26 mars 2024 à 10:16, Martin Bartosch via OpenXPKI-users <
>> openxpki-users@lists.sourceforge.net> a écrit :
>>
>>> Hi,
>>>
>>>
>>> > 5- I do get authenticated through basic auth AND through the
>>> certificates i'm passing to cURL.
>>> > But I keep getting back the same certificate.
>>> > No workflow is triggered.
>>> > And in EST.log
>>> >   INF authenticated client DN: CN=same cn,DC=Test
>>> Deployment,DC=OpenXPKI,DC=org [pid=91|ep=[undef]]
>>> >
>>> > 6- I thought it was my authentication stack causing the issue (using
>>> http basic), so I reversed it back to the default (anonymous), and I still
>>> don't get the renawal mode, just fetching the same certificate.
>>>
>>> When receiving an enrollment request via any of its enrollment
>>> interfaces OpenXPKI distinguishes initial enrollment, renewal and
>>> enrollment on behalf mode and branches into the respective branch of the
>>> enrollment workflow. You can see which path is chosen by examining the
>>> enrollment workflow instance and its context.
>>>
>>> If you send the same CSR (based on the same private key) to an
>>> enrollment interface, you will get back the existing certificate if the
>>> enrollment workflow for this key was previously successfully executed.
>>>
>>> If you wish to perform a renewal, you need to generate a new private key
>>> and a new certificate request based on that new key. In order to qualify as
>>> a renewal from the viewpoint of OpenXPKI, the renewal request must be
>>> authenticated by the old, existing certificate and key (and the subject
>>> must match). I

Re: [OpenXPKI-users] EST renewal/reenrollment

[Oliver Welter]

Hi Mo,

I understand the implications in the protocol but this is somewhat 
different from the concept OpenXPKI uses.


We do not give away any certificate without making a decission on the 
certified properies - the self-renwal ability is covered by the 
assumption that an entity that was granted this certificate can use this 
"grant" forever so it can renew the certificate with the same grants. A 
renewal with a different SAN item is from this perspective not a renewal 
but a request for a new grant and therefore needs an active decission 
which is almost the same process as an initial enrollment. Strictly 
speaking there are some differences as the entity can proof its identity 
with the old certificate but we never came across a use case where this 
was relevant and so its just not implemented.


As said, we can read and process this extension technically but there is 
no path in the business logic yet to support this.


Oliver

On 08.04.24 12:25, Mo Be wrote:

Hi Oli,

I don't know if it could be useful for OpenXPKI though.
It's a nice to have, but, like how complicated would that be in terms 
of implemenation...


As for the use-case, from an EST standpoint, it is simply reenrolling 
with a different subject or subject alternative name.


If the user, for some reason, wishes to reenroll a certificate about 
to expire, but this time, would like use  instead of , 
then in this case, the CSR with Change Subject Name attribute could be 
useful and would avoid the user to go through the enroll process which 
would require a potential different way of authentication, whether 
it's a challenge password, or an http basic password, or a certificate 
signed by another trusted entity etc.


Mo

Le sam. 6 avr. 2024 à 20:28, Oliver Welter  a écrit :

Hi Mo,

OpenXPKI uses only the DN to decide weather this is a renewal or
not but than copies over the SAN items from the old certificate to
the new request, so the renewed certificate is an "exact copy" of
the old one, besides validity and signature of course.

Handling around the "ChangeSubjectName" extension was not
implemented so far as we never got a request on this and it does
not really match the way how approvals are currently handled in
the standard workflows. If you can make up a proper use case how
to handle this, we can of course implement this in the workflows.

Oliver

On 06.04.24 14:52, Mo Be wrote:

Hi,

I realized i overlooked the answer : it's the subject and the
renewal period, but there is no mention of the SAN.
I thought that renewal must happen at least if the CSR and the
certificate to be renewed have
- same subject
- same SAN

Which brought me back to RFC 7030 - section 4.2.2
,
and made me wonder if we could make use of the ChangeSubjectName
attribute in OpenXPKI.

That being said, do we have a way to check for the SAN as well
during renewal workflow? I'm still looking at different .yaml
files but the answer is no so far.
And does OpenX handle the ChangeUserName attribute ?

Thank you

Le mar. 26 mars 2024 à 13:30, Mo Be  a écrit :

Yes yes yes Martin...
That was it !

I still don't know how to play on that renewal_period though.
By default, enrolled certificates are given a validity of one
year.
I added in my EST .yaml an initial validity, something I
found in rpc .yaml
 initial_validity: +01 (which translates to 1 day
starting from today)

I left the renewal period intact, i'm not sure how to
interpret it
(can be renewed only if within this period of time, that I
know for sure)
 renewal_period: 60

In the documentation, I have read it was following this
format MMDDhhmmss in case of absolute date.
I guess in renewal, it's different => YYMMDD (perhaps hhmmss
as well),
That translates to 60 days maybe.

/https://openxpki.readthedocs.io/en/develop/reference/configuration/profile.html/
Still need to figure out exactly what's happening regarding
that renwal period because,
OpenXPKI dates are also not in sync with my VM, which makes
it a bit hard to know what's wrong and why.
Anyway, thanks for your help Martin, got that renewed
certificate working

Mohamed


Le mar. 26 mars 2024 à 10:16, Martin Bartosch via
OpenXPKI-users  a écrit :

Hi,


> 5- I do get authenticated through basic auth AND
through the certificates i'm passing to cURL.
> But I keep getting back the same certificate.
> No workflow is triggered.
> And in EST.log
>   INF authenticated client DN: CN=same cn,DC=Test
Deployment,DC=OpenXPKI,DC=org [pid=91|ep=[undef]]