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
<https://datatracker.ietf.org/doc/html/rfc7030#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 <mopra...@gmail.com> 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: +000001 (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: 000060
In the documentation, I have read it was following this format
YYYYMMDDhhmmss 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
--
Protect your environment - close windows and adopt a penguin!
_______________________________________________
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
