Re: [OpenXPKI-users] EST renewal/reenrollment

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

Re: [OpenXPKI-users] EST renewal/reenrollment

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 s

Re: [OpenXPKI-users] EST renewal/reenrollment

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 "ChangeSubje

Re: [OpenXPKI-users] EST renewal/reenrollment

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

Re: [OpenXPKI-users] EST renewal/reenrollment

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 da

Re: [OpenXPKI-users] EST renewal/reenrollment

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=9

Re: [OpenXPKI-users] EST renewal

I found it ! Learning a lot browsing the openxpki sources. (learning x509, ASN.1, ...) So it happened that signer_subject_matches_csr_subject failed in my case because I constructed the subject incorrectly in the CSR When inspecting the CSR/CERT with openssl the subjects *seemed* identica

Re: [OpenXPKI-users] EST renewal

Enabling some debug loggins shows that indeed, my system is doing enroll_set_mode_onbehalf, instead of enroll_set_mode_renewal 023/06/14 13:05:46 91903 Trusted Signer Authorization matched subrule mobility 2023/06/14 13:05:46 91903 Trusted Signer not found in trust list (CN=testme2,DC=Test Deploym

Re: [OpenXPKI-users] EST renewal

On Thu, Jun 8, 2023 at 8:48 PM Oliver Welter wrote: > Hi Harm, > > in the OpenXPKI default workflows the condition for a renewal is a FULL DN > match so your incoming CSR must not only have the same CN but the complete > DN. This can be configured in several ways by changing the comparison logic

Re: [OpenXPKI-users] EST renewal

Hi Harm, in the OpenXPKI default workflows the condition for a renewal is a FULL DN match so your incoming CSR must not only have the same CN but the complete DN. This can be configured in several ways by changing the comparison logic of the "subject matches" condition class, the details are

Re: [OpenXPKI-users] EST renewal

Hi, I guess I need somehow to configure a ruleX: that verifies that the authorized_signer subject, matches the subject of the CSR. I could not find any examples in the documentation, mailinglists how to do that. Are there any examples available? Or does someone has a suggestion here? Or am I mi