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

[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

[OpenXPKI-users] EST renewal/reenrollment

[Mo Be]

Hello,

I'd like to experiment with EST reenroll web service and I don't seem to
succeed yet.

1- I have enrolled a 1st CSR and got my certificate.

2- In this forum, I also found out that it's comparing the full subject
(and not just the CN part)
So I just ran the same command to have the same CSR with same data in it.

   To generate the CSR like the following
sudo openssl req -subj "/DC=org/DC=OpenXPKI/DC=Test Deployment/CN
=same cn" -addext "subjectAltName = DNS:localhost" -nodes -new -ke
y openxpki.pem -outform der -out - | base64 > localhost-req.pem

3- I did compare the two subjects and they look similar
cat localhost-req.pem | base64 --decode | openssl req -inform der -noout
-text | grep Subject:
  Subject: DC = org, DC = OpenXPKI, DC = Test Deployment, CN= same cn

openssl x509 -in cert.pem -noout -text |grep Subject:
  Subject: DC = org, DC = OpenXPKI, DC = Test Deployment, CN= same cn

4- sudo curl -k --key openxpki.pem --cert cert.pem -u test:test -v -
H "Connection: close" -H "Content-Type: application/pkcs10" --data
@localhost-req.pem https://localhost:8443/.well-known/est/simplereenroll

The use of http basic auth (-u test:test) was just something i was testing
before. It's irrelevant in this post.

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.

(sudo curl and csr involve sudo because that private key requires some
privileges)

Has anyone spotted the missing piece ?
Thank you for your time and efforts,
Mohamed
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users