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 <dns2> instead of <dns1>,
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 <m...@oliwel.de> 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
<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
_______________________________________________
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
