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 >> <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 > listOpenXPKI-users@lists.sourceforge.nethttps://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
