Hello Oliver, thank you for your reply. Unfortunately, I didn't quite get any further as I'm not sure which action you are referring to exactly. I don't know which action actually is responsible for the renewal.
The renewal case executes four steps with the following actions. 1. global_set_error_signer_revoked 2. global_set_error_signer_expired 3. set_renewal_period prepare_renewal load_recent_metadata 4. global_set_error_not_in_current_realm As the error message is complaining about the realm I guess `global_set_error_not_in_current_realm` could be responsible? I cannot find a definition for this action--like I cannot find a definition for any action prefixed with `global_`. Am I missing something? The documentation says `global` actions are defined outside of the workflow, but where? What I also tried in the meantime is to set `policy.allow_surrogate_certificate: 1` in the realm's rpc/enroll.yaml configuration file. Unfortunately, that didn't show any effect either (but I didn't debug that case extensively because this is not the solution you suggested). Could you please elaborate the suggested solution? Paul On Sat, 2021-11-06 at 16:29 +0100, Oliver Welter wrote: > Hello Paul, > > The option is not enabled by default - you must set the > "allow_surrogate_certificate" parameter in the configuration of the > action class inside the workflow - see > https://openxpki.readthedocs.io/en/stable/reference/configuration/workflow.html > > Oliver > > Am 04.11.21 um 17:58 schrieb Paul Schaefer: > > Hello, > > > > I am trying to automate the certificate renewal as described in [1]. > > The goal is to renew a usual "TLS Server" certificate without > > client_auth key usage. > > > > First, I set up a "surrogate certificate" by copying the exact web > > server certificate subject identically into a self signed certificate > > which uses the same private key like the original web server > > certificate. (I hope this is the correct mechanism?) > > > > After that, I'm using the default enroll RPC endpoint, with TLS > > Client > > authentication using the newly generated surrogate certificate. I'm > > posting the parameters "method=RequestCertificate", > > "pkcs10=<PEMBLOCK>" > > and "profile=tls-server" (which is mapped in enroll.yaml profile_map > > to > > tls_server, which in turn is the profile originally used to issue > > this > > certificate). The following is the server's response: > > > > {"result":{"id":6399,"data":{"transaction_id":"c84f3e51a3f7fd62d863ac > > 45 > > a086b06ed6b125bf","error_code":"Renewal request is for certificate > > from > > foreign realm!"},"state":"FAILURE","pid":71,"proc_state":"finished"}} > > > > I'm a bit lost now. From what I understood is that the workflow > > `certificate_enroll.yaml` executes the EvaluateSignerTrust activity. > > I > > already debugged this class by logging extensively, but neither > > `$self- > > > param('allow_surrogate_certificate')` nor `$cert_hash` seem to have > > > a > > value when running the above procedure. > > > > Can you help me? > > > > Thank you for your help and the amazing tool! > > > > Best, > > Paul > > > > [1] > > https://openxpki.readthedocs.io/en/stable/reference/configuration/workflows/enroll.html#renewal > > > > > > _______________________________________________ > > OpenXPKI-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/openxpki-users > > > _______________________________________________ > OpenXPKI-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-users -- OpenSource Security GmbH https://os-s.de Am Bahnhof 3 48565 Steinfurt Germany Fon: +49 2552 927009-0 Fax: +49 2552 927009-9 Registergericht: Amtsgericht Steinfurt, HRB 12044 Geschäftsführer: Ralf Spenneberg, Hendrik Schwartke Umsatzsteuer-Identifikationsnummer gem. §27a UStG: DE815773501
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
