Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment"
Hi Martin, Thanks you for the link. No problem for the ASN.1 Regards Eddy Internal -Message d'origine- De : Martin Bartosch Envoyé : mardi 25 mai 2021 18:45 À : openxpki-users@lists.sourceforge.net Cc : Eddy BODIN Objet : Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment" [External email: Use caution with links and attachments] Hi, > Thanks you Oliver, I succeed with SSCEP to sign my client with the PKI#2 > previously signed by PKI#1 (This post helped me > too:https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fopenxpki%2Fmailman%2Fmessage%2F36904820%2Fdata=04%7C01%7Ceddy.bodin%40non.se.com%7Cd996de228f814e2908d91f9c700b%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637575579613826309%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=yUqk0hx7HK9FvjaJCm8msxjWY3bzwaSwFReWcizH18U%3Dreserved=0) > > But I have still two questions: > • The quick one; in case where I have 2 signers (e.g.: ca-signer-1 and > ca-signer-2) is it possible to set/configure that only ca-signer 1 signs a > certificate request? (SCEP enrollment) – because currently the last signer I > add, the last signer who signs the request. See https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fopenxpki%2Fmailman%2Fopenxpki-users%2F%3Fviewmonth%3D202105%26viewday%3D18%26style%3Dflatdata=04%7C01%7Ceddy.bodin%40non.se.com%7Cd996de228f814e2908d91f9c700b%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637575579613826309%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=wUODNGxklLfKL67I1jfFVJ5MWgfeX%2BWjh5r4%2B58XVsg%3Dreserved=0 for a very similar question and answer. > • The second question arrived because I trying to do the on-behalf – > already made with SSCEP – now with Cryptlib. > The PKI#1 (openxpki with workaround in the workflow) signs my client (START > INITIAL is triggered) – this part is OK. Then the PKI#2 trying to sign my > client (I trying to reach START ON-BEHALF) but I failing before that, I get > lot of errors from LibSCEP: > > I don’t know which ASN1 field(s) have a problem, is it possible to know that? Sorry, I currently don't have the time for ASN.1 diving... Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment"
Hi, > Thanks you Oliver, I succeed with SSCEP to sign my client with the PKI#2 > previously signed by PKI#1 (This post helped me > too:https://sourceforge.net/p/openxpki/mailman/message/36904820/) > > But I have still two questions: > • The quick one; in case where I have 2 signers (e.g.: ca-signer-1 and > ca-signer-2) is it possible to set/configure that only ca-signer 1 signs a > certificate request? (SCEP enrollment) – because currently the last signer I > add, the last signer who signs the request. See https://sourceforge.net/p/openxpki/mailman/openxpki-users/?viewmonth=202105=18=flat for a very similar question and answer. > • The second question arrived because I trying to do the on-behalf – > already made with SSCEP – now with Cryptlib. > The PKI#1 (openxpki with workaround in the workflow) signs my client (START > INITIAL is triggered) – this part is OK. Then the PKI#2 trying to sign my > client (I trying to reach START ON-BEHALF) but I failing before that, I get > lot of errors from LibSCEP: > > I don’t know which ASN1 field(s) have a problem, is it possible to know that? Sorry, I currently don't have the time for ASN.1 diving... Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment"
tk65gaesqNeK5qbflF/vUfz7sLX6CCBdQwggXQ MIIEOKADAgECAgo9/xxHU69qpRU1MA0GCSqGSIb3DQEBCwUAMFoxCzAJBgNVBAYTAkRFMREwDwYD VQQKDAhPcGVuWFBLSTEMMAoGA1UECwwDUEtJMSowKAYDVQQDDCFPcGVuWFBLSSBEZW1vIElzc3Vp bmcgQ0EgMjAyMTAzMTMwHhcNMjEwNTI1MTQzODM5WhcNMjExMTI1MTQzODM5WjBsMRMwEQYKCZIm iZPyLGQBGRYDb3JnMRgwFgYKCZImiZPyLGQBGRYIT3BlblhQS0kxHzAdBgoJkiaJk/IsZAEZFg9U ZXN0IERlcGxveW1lbnQxGjAYBgNVBAMMETIwMjEwNTI1LUMtMTYzODMzMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7miqvWivvg5ezZuocbCd0LzMFUbcQJD+xhq85bZcCPGZjfcu1im6 a6/MWpg0hiwNf2JBSJ5JIyhX7Tvg7ABQairVVYTGKnRKsnoi/oP5vPqP6zg0iwGP00hJYvqFY602 KGKkCQFY5Dz1htBrNGYrh0EVXgNWtzXQsmbOJ0E/NHKOjhEu336myrFS0Puzrt4FJDNSfJsSfYDu UGWK6FLvG54iO5MWfmBUm8KThHtSnJKxkbzYcpb/4WjBM7j28tjwtrNx+f16b/gPFqmaLOx97oCL 2WUJ2nPFX9KW/RwYvHeuVFUYBQxs0UsC1bIj1SwqlDMJVSwfokWDwcUU/I6aqQIDAQABo4ICBDCC AgAwgYcGCCsGAQUFBwEBBHsweTBRBggrBgEFBQcwAoZFaHR0cDovL3BraS5leGFtcGxlLmNvbS9k b3dubG9hZC9PcGVuWFBLSV9EZW1vX0lzc3VpbmdfQ0FfMjAyMTAzMTMuY2VyMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5leGFtcGxlLmNvbS8wHwYDVR0jBBgwFoAUpFUBl4Jcxu1OpH791Pw7qpnc lq8wDAYDVR0TAQH/BAIwADBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vcGtpLmV4YW1wbGUuY29t L2Rvd25sb2FkL09wZW5YUEtJX0RlbW9fSXNzdWluZ19DQV8yMDIxMDMxMy5jcmwwEwYDVR0lBAww CgYIKwYBBQUHAwEwDgYDVR0PAQH/BAQDAgOoMIGoBgNVHSAEgaAwgZ0wgZoGAyoDBDCBkjArBggr BgEFBQcCARYfaHR0cDovL3BraS5leGFtcGxlLmNvbS9jcHMuaHRtbDArBggrBgEFBQcCARYfaHR0 cDovL3BraS5leGFtcGxlLmNvbS9jcHMuaHRtbDA2BggrBgEFBQcCAjAqGihUaGlzIGlzIGEgY29t bWVudCBmb3IgcG9saWN5IG9pZCAxLjIuMy40MB0GA1UdDgQWBBRObxvZLIxEk5X2IYJ0zpo2qiRv KDANBgkqhkiG9w0BAQsFAAOCAYEALiVIVcPCZlT0+7lw8BdtVZ638iNYVTKiDzV17hFpTvny81es BZoRp6C+I1YDO94xmto16k1CtXatA87aerFpxKbCuTdxdghZNs4isXW6GjuZxaSylMR19j8UNBu1 CxxZxbO58yq7i2KILlGqVg/ecj/HhuFkf/stw/6bXXSR1ii9VEkCMK3i2vT1JKjNjWRz3m+L08Ux AXYePI2B9q4B5YgGAKPL2lX5aMyku8IkxJv0vlsPZEujIoV/PpJ0Wj4PrcPICWP4NzRb3rR8rZnM eBolW4+Z2Z50+3hqMvj+jRFaFwCnnfpsYdQpZlJkANw4mh6M+NfES9NHiUUnSLnI83bCCxcEeaSM 9/NhSxOCJCyYjfKWbUPxMhYEw4x4ykpDunJhzpmturWU4+lsq6XF0mKSL+evenTY+HSQIrJoPie1 ozYal1G7f3D7u2k8mFDzfubbDS78ybSS6tvJPQvAxIZrUBAj4fwInx0+eRoLxdf6HqrnNJ92/c0F 1LW21pfIMYICojCCAp4CAQEwaDBaMQswCQYDVQQGEwJERTERMA8GA1UECgwIT3BlblhQS0kxDDAK BgNVBAsMA1BLSTEqMCgGA1UEAwwhT3BlblhQS0kgRGVtbyBJc3N1aW5nIENBIDIwMjEwMzEzAgo9 /xxHU69qpRU1MA0GCWCGSAFlAwQCAQUAoIIBCzASBgpghkgBhvhFAQkCMQQTAjE4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwGAYKKoZIhvcNAQkZAzEKBAj1QHiTENAh/zAcBgkqhkiG9w0BCQUx DxcNMjEwNTI1MTQzODAwWjAeBgkqhkiG9w0BCTQxETAPMA0GCWCGSAFlAwQCAQUAMCAGCmCGSAGG +EUBCQUxEgQQ7KSFQOl7s6E0/GJOTi9dkDAvBgkqhkiG9w0BCQQxIgQgEzAI6spxx+mpPewHK5IT aiS7H9p/Vse0LgJE7/IhD0AwMAYKYIZIAYb4RQEJBzEiEyA1M2ExYTE5OWE2NmM3MTgxYzk2Mjg3 OTVjNTBiMjU2ODANBgkqhkiG9w0BAQEFAASCAQB+Zaw2vVbXXj1+6aS6YgNwbZfwsNeZJIOWR+8t DpsERZ/Q5SUmXSf48t5LKVwTYqriCvawGjQ7I2KvxXCEtCtWgdFjP3gdAdB6U/ofR2GLbcs8iMB6 iWkd3LOPk8+UhbeuXVQdniS3UcZv3NX0ArLdrJsIbmt435vmO+yJpp66lpK6z4iB39+dnpX+u2q/ NQxyXEhbfG6ERQOpTaiIW5S5aPkTCri4zEyvW3nJAfx4pSK5tBK+NXM6C0oZqr/D1coI7c2AHNbA VTaQozkSvhpFg+QVTI2ouA0TlVmym5g1yUBb/AqCY+6f+vZ2GhFYS8acGGrcwkE5ojKOoBNIkoD+ Regards Internal De : Oliver Welter Envoyé : mardi 11 mai 2021 07:37 À : openxpki-users@lists.sourceforge.net Objet : Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment" [External email: Use caution with links and attachments] Hello Eddy, Am 10.05.21 um 22:49 schrieb Eddy BODIN via OpenXPKI-users: Thanks you for your help. Do you think that a fix will be develop for this issue? yes we will fix this issue as the "problem" is on the OpenXPKI side so we want to get this working properly, there is already a bug ticket for this https://github.com/openxpki/openxpki/issues/810<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenxpki%2Fopenxpki%2Fissues%2F810=04%7C01%7Ceddy.bodin%40non.se.com%7C5b84611e93a14a47fae908d9143efc46%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637563083028368015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=CWZVA4hSw2WC5SuVyxpJj8k1BBIzXonAyU5LSmgxiBQ%3D=0>. We have planned this for the next release which is currently scheduled for end of July but I can not promise that the fix will make it until then or that the release is on schedule - the main driver for development are our paying customers so their demands get the priority. I have another questions, I read in the documentation : https://openxpki.readthedocs.io/en/latest/reference/configuration/workflows/enroll.html#enrollment-on-behalf<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenxpki.readthedocs.io%2Fen%2Flatest%2Freference%2Fconfiguration%2Fworkflows%2Fenroll.html%23enrollment-on-behalf=04%7C01%7Ceddy.bodin%40non.se.com%7C5b84611e93a14a47fae908d9143efc46%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637563083028378010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=A7CfmIJCjTeS1aa6AXvaXCZTmR8VHwal5XsbRZk85vo%3D=0>, according this chapter, it seems possible to request a cert
Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment"
Hello Eddy, Am 10.05.21 um 22:49 schrieb Eddy BODIN via OpenXPKI-users: > > > Thanks you for your help. Do you think that a fix will be develop for > this issue? > yes we will fix this issue as the "problem" is on the OpenXPKI side so we want to get this working properly, there is already a bug ticket for this https://github.com/openxpki/openxpki/issues/810. We have planned this for the next release which is currently scheduled for end of July but I can not promise that the fix will make it until then or that the release is on schedule - the main driver for development are our paying customers so their demands get the priority. > > > > I have another questions, I read in the documentation : > https://openxpki.readthedocs.io/en/latest/reference/configuration/workflows/enroll.html#enrollment-on-behalf, > > according this chapter, it seems possible to request a certificate, > signed by another PKI e.g. PKI#2, to get a certificate signed by > PKI#1. Maybe my comprehension of this feature is wrong. Every tests I > made never match the state "On Behalf" so my question is: > > > > First, it’s possible to do that? If yes, what I need to add in my CSR > (maybe something around extensions)? And where I have to specify the > other trusted PKI in OpenXpki configuration file? > The feature does not necessarily involve a second PKI - it just relies on a signature made by another certificate. Usually you issue this as a TLS Client from the OpenXPKI itself. If you want to use a certificate from an external PKI, you must first import the CA chain from it and configure the trust settings correctly. You also need to enable the "allow external signer" flag on the "evaluate_signer_trust" activity and reference the external CA chain - the perldocs of this class should provide hopefully useful information on this. Its definitely possible but I think we dont have a public available summary elsewhere for this scenario. best regards Oliver > > > Regards > > Eddy > > > > *De :*Oliver Welter > *Envoyé :* vendredi 7 mai 2021 08:48 > *À :* openxpki-users@lists.sourceforge.net > *Objet :* Re: [OpenXPKI-users] SCEP enrolment: problem to reach > "Initial enrolment" > > > > [External email: Use caution with links and attachments] > > > > > > Hi Eddy, > > > > my colleague Martin had a deeper look into your data and we found the > problem :) > > > > The construction of the "key identifier" is only loosely defined in > RFC5280 but we never saw any tools with a different behaviour - as of > today. As a CSR does not include a key identifier the ASN1 structure, > we use the definition from the RFC and use the sha1 hash of the public > key. Fpr the certificate, we read the key identifier from the ASN1 > structure (if set) and surprisingly the value in your signature > certificate does not match the expected one. > > > > Bottom line: You are using the correct key/certificate but the > assumption we made is wrong and we therefore fail to detect this > properly. We are currently discussion how to solve this properly in > OpenXPKI but at the moment there is no "quick hack" I can offer on > this side other then reworking the conditions in the workflow as > described in my last post. > > > > Oliver > > > > Am 07.05.21 um 08:00 schrieb Oliver Welter: > > Hello Eddy, > > > > as I already said last week > https://sourceforge.net/p/openxpki/mailman/message/37269596/ > > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fopenxpki%2Fmailman%2Fmessage%2F37269596%2F=04%7C01%7Ceddy.bodin%40non.se.com%7C14f63a9ff6684ec9024408d911244413%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637559669725397575%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=sRRG8qd0NxsKWUO8HbJ1xtTS08cHV6JgYqyp045WZrU%3D=0> > - to be recognized as an "initial enrollment" the request must be > self-signed - at least in our world this means that the public key > used in the CSR must also be used to sign the SCEP envelope. > > > > As you can see here, this is not the case > > > > csr_subject_key_identifier > A4:50:D7:F8:BA:A5:1D:EB:3B:C6:9D:AB:EB:9C:00:12:8A:DA:81:D0 > signer_subject_key_identifier > 60:A2:93:80:F1:F5:58:93:59:4B:80:CA:13:EE:50:DA:4F:7C:80:6F > > > > The complete enrollment workflow is described here > > https://openxpki.readthedocs.io/en/latest/reference/configuration/workflows/enroll
Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment"
Hi Oliver, Thanks you for your help. Do you think that a fix will be develop for this issue? I have another questions, I read in the documentation : https://openxpki.readthedocs.io/en/latest/reference/configuration/workflows/enroll.html#enrollment-on-behalf, according this chapter, it seems possible to request a certificate, signed by another PKI e.g. PKI#2, to get a certificate signed by PKI#1. Maybe my comprehension of this feature is wrong. Every tests I made never match the state "On Behalf" so my question is: First, it's possible to do that? If yes, what I need to add in my CSR (maybe something around extensions)? And where I have to specify the other trusted PKI in OpenXpki configuration file? Regards Eddy De : Oliver Welter Envoyé : vendredi 7 mai 2021 08:48 À : openxpki-users@lists.sourceforge.net Objet : Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment" [External email: Use caution with links and attachments] Hi Eddy, my colleague Martin had a deeper look into your data and we found the problem :) The construction of the "key identifier" is only loosely defined in RFC5280 but we never saw any tools with a different behaviour - as of today. As a CSR does not include a key identifier the ASN1 structure, we use the definition from the RFC and use the sha1 hash of the public key. Fpr the certificate, we read the key identifier from the ASN1 structure (if set) and surprisingly the value in your signature certificate does not match the expected one. Bottom line: You are using the correct key/certificate but the assumption we made is wrong and we therefore fail to detect this properly. We are currently discussion how to solve this properly in OpenXPKI but at the moment there is no "quick hack" I can offer on this side other then reworking the conditions in the workflow as described in my last post. Oliver Am 07.05.21 um 08:00 schrieb Oliver Welter: Hello Eddy, as I already said last week https://sourceforge.net/p/openxpki/mailman/message/37269596/<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fopenxpki%2Fmailman%2Fmessage%2F37269596%2F=04%7C01%7Ceddy.bodin%40non.se.com%7C14f63a9ff6684ec9024408d911244413%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637559669725397575%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=sRRG8qd0NxsKWUO8HbJ1xtTS08cHV6JgYqyp045WZrU%3D=0> - to be recognized as an "initial enrollment" the request must be self-signed - at least in our world this means that the public key used in the CSR must also be used to sign the SCEP envelope. As you can see here, this is not the case csr_subject_key_identifier A4:50:D7:F8:BA:A5:1D:EB:3B:C6:9D:AB:EB:9C:00:12:8A:DA:81:D0 signer_subject_key_identifier 60:A2:93:80:F1:F5:58:93:59:4B:80:CA:13:EE:50:DA:4F:7C:80:6F The complete enrollment workflow is described here https://openxpki.readthedocs.io/en/latest/reference/configuration/workflows/enroll.html<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenxpki.readthedocs.io%2Fen%2Flatest%2Freference%2Fconfiguration%2Fworkflows%2Fenroll.html=04%7C01%7Ceddy.bodin%40non.se.com%7C14f63a9ff6684ec9024408d911244413%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637559669725397575%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=zlR8FNuFIswtQ8qUYbdALk1xjMezVVU3GINPb91qZDg%3D=0> If you want to change this detection logic you can rework the conditions in the workflow, you find this here https://github.com/openxpki/openxpki-config/blob/community/config.d/realm.tpl/workflow/def/certificate_enroll.yaml#L30<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenxpki%2Fopenxpki-config%2Fblob%2Fcommunity%2Fconfig.d%2Frealm.tpl%2Fworkflow%2Fdef%2Fcertificate_enroll.yaml%23L30=04%7C01%7Ceddy.bodin%40non.se.com%7C14f63a9ff6684ec9024408d911244413%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C637559669725407570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=WdOfE56xBecyVMx1DGi2hmb3h9a0TIWgvaBFXH%2BPNsk%3D=0> The better way would be IMHO to try to fix this in your SCEP client. best regards Oliver Am 06.05.21 um 22:27 schrieb Eddy BODIN via OpenXPKI-users: Hello, we're trying to enroll with SCEP a newly created certificate, using a Cryptlb based client, on an openXpki server on the default realm called "democa". We expect to have an initial enrolment but instead of it regarding the workflow we reach state "START_RENEWAL" after "SIGNED_REQUEST". In the workflow the CSR is not considered as self-signed, leading to this issue. The newly created certificate has a new transaction_id and a new DN and common name. What possible reason could lead to this issue ? Thanks. Workflow Con
Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment"
Hi Eddy, my colleague Martin had a deeper look into your data and we found the problem :) The construction of the "key identifier" is only loosely defined in RFC5280 but we never saw any tools with a different behaviour - as of today. As a CSR does not include a key identifier the ASN1 structure, we use the definition from the RFC and use the sha1 hash of the public key. Fpr the certificate, we read the key identifier from the ASN1 structure (if set) and surprisingly the value in your signature certificate does not match the expected one. Bottom line: You are using the correct key/certificate but the assumption we made is wrong and we therefore fail to detect this properly. We are currently discussion how to solve this properly in OpenXPKI but at the moment there is no "quick hack" I can offer on this side other then reworking the conditions in the workflow as described in my last post. Oliver Am 07.05.21 um 08:00 schrieb Oliver Welter: > Hello Eddy, > > as I already said last week > https://sourceforge.net/p/openxpki/mailman/message/37269596/ - to be > recognized as an "initial enrollment" the request must be self-signed > - at least in our world this means that the public key used in the CSR > must also be used to sign the SCEP envelope. > > As you can see here, this is not the case > > csr_subject_key_identifier > A4:50:D7:F8:BA:A5:1D:EB:3B:C6:9D:AB:EB:9C:00:12:8A:DA:81:D0 > signer_subject_key_identifier > 60:A2:93:80:F1:F5:58:93:59:4B:80:CA:13:EE:50:DA:4F:7C:80:6F > > The complete enrollment workflow is described here > https://openxpki.readthedocs.io/en/latest/reference/configuration/workflows/enroll.html > > If you want to change this detection logic you can rework the > conditions in the workflow, you find this here > https://github.com/openxpki/openxpki-config/blob/community/config.d/realm.tpl/workflow/def/certificate_enroll.yaml#L30 > > The better way would be IMHO to try to fix this in your SCEP client. > > best regards > > Oliver > > Am 06.05.21 um 22:27 schrieb Eddy BODIN via OpenXPKI-users: >> >> Hello, >> >> we're trying to enroll with SCEP a newly created certificate, using a >> Cryptlb based client, on an openXpki server on the default realm >> called "democa". We expect to have an initial enrolment but instead >> of it regarding the workflow we reach state "START_RENEWAL" after >> "SIGNED_REQUEST". In the workflow the CSR is not considered as >> self-signed, leading to this issue. >> >> The newly created certificate has a new transaction_id and a new DN >> and common name. >> >> What possible reason could lead to this issue ? >> >> >> >> Thanks. >> >> >> >> >> >> *_Workflow Context :_* >> >> >> >> cert_profile tls_server >> >> cert_subject CN=20210506-C-220638,DC=Test >> Deployment,DC=OpenXPKI,DC=org >> >> cert_subject_parts >> >> C >> >> FR >> >> CN >> >> 20210506-C-220638 >> >> O >> >> MYORGANISATION >> >> OU >> >> MYUNIT >> >> cert_subject_style enroll >> >> creator generic >> >> csr_digest_alg sha256 >> >> csr_key_alg rsa >> >> csr_key_params >> >> key_length >> >> 4096 >> >> csr_subject CN=20210506-C-220638,OU=MYUNIT,O=MYORGANISATION,C=FR >> >> csr_subject_key_identifier >> A4:50:D7:F8:BA:A5:1D:EB:3B:C6:9D:AB:EB:9C:00:12:8A:DA:81:D0 >> >> error_code Renewal request is for certificate from foreign realm! >> >> interface scep >> >> p_allow_anon_enroll 0 >> >> p_allow_eligibility_recheck 1 >> >> p_allow_man_approv 1 >> >> p_allow_man_authen 0 >> >> p_allow_replace 1 >> >> p_approval_points 0 >> >> p_auto_revoke_existing_certs 1 >> >> p_max_active_certs 1 >> >> pkcs10 >> >> -BEGIN CERTIFICATE REQUEST- >> >> MIIEuTCCAqECAQAwUzELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDk1ZT1JHQU5JU0FU >> >> SU9OMQ8wDQYDVQQLEwZNWVVOSVQxGjAYBgNVBAMTETIwMjEwNTA2LUMtMjIwNjM4 >> >> MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvFMd313lzD1i+A5u2l7i >> >> 9oLQnZXhG6usD2tYJq1NcuUE++YTxQ+PDbb2EPfcClEc7/Xyurn+TMPeU7opPdxP >> >> 3IQx23H1Y4UbIzv0k8WJckCj1zwnSgQllJzXefAImezJTSlV9IAo8UB9uXTxbbzu >> >> CipYD+GcbDMKN1Wjjn6ngtjIdmYgnsc1x/UBUsmb7rrtWcI7dMEgrw7hkJThw+EW >> >> XwL7l1TnVPUVTFxkIvrOzCatWA/HUNCeiE5XeERYwyZ6WwkpVv+ufO3tMVxhsu5r >> >> TzxxAr1Xk1P7/9izAYzJ4CwRI2UuTqo5nOXNHdqcQpcJWqHwpYfCqwtlPZdOyx6a >> >> fuEnvQW7V8P/PQ2ttbJ9CGk4sWB7Y2GHAEPCb1gxKl9rEHAh3b/uNvXHaBo09F6G >> >> JCDQqZpVVAxcZkHSuf9BMJzU3A8mkxdONWDd6q4VYvMN+5eSJHEgT5r15nEStmUD >> >> e/UFGW/2WouYxONASVFbljm6JjsOX49p6zhh4Fq0vZM1YETbIqhYCN3CPibgYXQn >> >> nBKHCnCInLi0pM3fqIE+HAFSI8/0Rbp38kbfNCkjyVGyjBED4MUVJeIlemgop0Jk >> >> pFFtv2JZjIbagjm8OqJ4UnRtCELinGnQeWCyya4gX5KnWZUEEojNQmUJKVO34eHF >> >> L7MQvfrZK50f875rbwTuEEcCAwEAAaAhMB8GCSqGSIb3DQEJBzESExB4eHh4WFhY >> >> WHh4eHhYWFhYMA0GCSqGSIb3DQEBCwUAA4ICAQCLorLSJgWwsXD50uWlUtyHdcSY >> >> nDygUe6l9gb53tuvsrMpqTcPOUcTFUJys4OtQ8gcN0HPfhO/O6LUoNx9kYpJc4Xd >> >>
Re: [OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment"
Hello Eddy, as I already said last week https://sourceforge.net/p/openxpki/mailman/message/37269596/ - to be recognized as an "initial enrollment" the request must be self-signed - at least in our world this means that the public key used in the CSR must also be used to sign the SCEP envelope. As you can see here, this is not the case csr_subject_key_identifier A4:50:D7:F8:BA:A5:1D:EB:3B:C6:9D:AB:EB:9C:00:12:8A:DA:81:D0 signer_subject_key_identifier 60:A2:93:80:F1:F5:58:93:59:4B:80:CA:13:EE:50:DA:4F:7C:80:6F The complete enrollment workflow is described here https://openxpki.readthedocs.io/en/latest/reference/configuration/workflows/enroll.html If you want to change this detection logic you can rework the conditions in the workflow, you find this here https://github.com/openxpki/openxpki-config/blob/community/config.d/realm.tpl/workflow/def/certificate_enroll.yaml#L30 The better way would be IMHO to try to fix this in your SCEP client. best regards Oliver Am 06.05.21 um 22:27 schrieb Eddy BODIN via OpenXPKI-users: > > Hello, > > we're trying to enroll with SCEP a newly created certificate, using a > Cryptlb based client, on an openXpki server on the default realm > called "democa". We expect to have an initial enrolment but instead of > it regarding the workflow we reach state "START_RENEWAL" after > "SIGNED_REQUEST". In the workflow the CSR is not considered as > self-signed, leading to this issue. > > The newly created certificate has a new transaction_id and a new DN > and common name. > > What possible reason could lead to this issue ? > > > > Thanks. > > > > > > *_Workflow Context :_* > > > > cert_profile tls_server > > cert_subject CN=20210506-C-220638,DC=Test > Deployment,DC=OpenXPKI,DC=org > > cert_subject_parts > > C > > FR > > CN > > 20210506-C-220638 > > O > > MYORGANISATION > > OU > > MYUNIT > > cert_subject_style enroll > > creator generic > > csr_digest_alg sha256 > > csr_key_alg rsa > > csr_key_params > > key_length > > 4096 > > csr_subject CN=20210506-C-220638,OU=MYUNIT,O=MYORGANISATION,C=FR > > csr_subject_key_identifier > A4:50:D7:F8:BA:A5:1D:EB:3B:C6:9D:AB:EB:9C:00:12:8A:DA:81:D0 > > error_code Renewal request is for certificate from foreign realm! > > interface scep > > p_allow_anon_enroll 0 > > p_allow_eligibility_recheck 1 > > p_allow_man_approv 1 > > p_allow_man_authen 0 > > p_allow_replace 1 > > p_approval_points 0 > > p_auto_revoke_existing_certs 1 > > p_max_active_certs 1 > > pkcs10 > > -BEGIN CERTIFICATE REQUEST- > > MIIEuTCCAqECAQAwUzELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDk1ZT1JHQU5JU0FU > > SU9OMQ8wDQYDVQQLEwZNWVVOSVQxGjAYBgNVBAMTETIwMjEwNTA2LUMtMjIwNjM4 > > MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvFMd313lzD1i+A5u2l7i > > 9oLQnZXhG6usD2tYJq1NcuUE++YTxQ+PDbb2EPfcClEc7/Xyurn+TMPeU7opPdxP > > 3IQx23H1Y4UbIzv0k8WJckCj1zwnSgQllJzXefAImezJTSlV9IAo8UB9uXTxbbzu > > CipYD+GcbDMKN1Wjjn6ngtjIdmYgnsc1x/UBUsmb7rrtWcI7dMEgrw7hkJThw+EW > > XwL7l1TnVPUVTFxkIvrOzCatWA/HUNCeiE5XeERYwyZ6WwkpVv+ufO3tMVxhsu5r > > TzxxAr1Xk1P7/9izAYzJ4CwRI2UuTqo5nOXNHdqcQpcJWqHwpYfCqwtlPZdOyx6a > > fuEnvQW7V8P/PQ2ttbJ9CGk4sWB7Y2GHAEPCb1gxKl9rEHAh3b/uNvXHaBo09F6G > > JCDQqZpVVAxcZkHSuf9BMJzU3A8mkxdONWDd6q4VYvMN+5eSJHEgT5r15nEStmUD > > e/UFGW/2WouYxONASVFbljm6JjsOX49p6zhh4Fq0vZM1YETbIqhYCN3CPibgYXQn > > nBKHCnCInLi0pM3fqIE+HAFSI8/0Rbp38kbfNCkjyVGyjBED4MUVJeIlemgop0Jk > > pFFtv2JZjIbagjm8OqJ4UnRtCELinGnQeWCyya4gX5KnWZUEEojNQmUJKVO34eHF > > L7MQvfrZK50f875rbwTuEEcCAwEAAaAhMB8GCSqGSIb3DQEJBzESExB4eHh4WFhY > > WHh4eHhYWFhYMA0GCSqGSIb3DQEBCwUAA4ICAQCLorLSJgWwsXD50uWlUtyHdcSY > > nDygUe6l9gb53tuvsrMpqTcPOUcTFUJys4OtQ8gcN0HPfhO/O6LUoNx9kYpJc4Xd > > iaRscx+u2FetQbpwsO8D1JZeMfvBz3R7Znpu8mZm/aggX8ZRE184/Cok9kJIcGbI > > 4dhJ2Qw6/H3rjnn+0PenqHXH97WuVYpmJDHJuHvX4YWY4X4LF46sMObT3+JoBYNR > > c7EKVRyoYGltcoOEVjQLSi86992V5R5Ddd3x1pfLcMOnK8lGLUxIZhfqY6IWPiRo > > tyINtQn1egS6Jwohns5qU5YLEsZcfdzywwDc/cvP/7n2qpzrYxv9zXd0P91OVS3P > > Pr+rE794N8kQmS4y671aoq/UCwAFMbP5YS4zmhfjA0iKJvTYSOGp8RjofKjUC7IZ > > 2mYC1YgDo4uudzyCquJlHSAVV85K+qV4urjtIT7vFgNcduQbtK44+pU0zc7QQY+r > > EWacWNMeOORbH9FUrfQ3svoFNY962glfSbAi8ssYkOfFjgW8yKDj1DRc5BpIPwr1 > > ZhegqYZLDvYDNEPmcmh0fQXHL6x4MT75S6k/zZqPhJrBq+ESL6aRq29nHUat+Z5N > > +XhEcNCh/66rDV3bKNoudMbTFyQir4GXEErKaVzXH/WxRlkSuz6j3l+Kz3uZ7wOo > > ztPnfK1IJ95lb9Frfw== > > -END CERTIFICATE REQUEST- > > > > req_attributes challengePassword > > > > request_mode renewal > > server generic > > signer_authorized 0 > > signer_cert > > -BEGIN CERTIFICATE- > > MIIFZzCCA0+gAwIBAgIIakzaLfQ1P5wwDQYJKoZIhvcNAQELBQAwUzELMAkGA1UE > > BhMCRlIxFzAVBgNVBAoTDk1ZT1JHQU5JU0FUSU9OMQ8wDQYDVQQLEwZNWVVOSVQx > > GjAYBgNVBAMTETIwMjEwNTA2LUMtMjIwNjM4MB4XDTIxMDUwNjIwMDYwMFoXDTIx > >
[OpenXPKI-users] SCEP enrolment: problem to reach "Initial enrolment"
Hello, we're trying to enroll with SCEP a newly created certificate, using a Cryptlb based client, on an openXpki server on the default realm called "democa". We expect to have an initial enrolment but instead of it regarding the workflow we reach state "START_RENEWAL" after "SIGNED_REQUEST". In the workflow the CSR is not considered as self-signed, leading to this issue. The newly created certificate has a new transaction_id and a new DN and common name. What possible reason could lead to this issue ? Thanks. Workflow Context : cert_profile tls_server cert_subject CN=20210506-C-220638,DC=Test Deployment,DC=OpenXPKI,DC=org cert_subject_parts C FR CN 20210506-C-220638 O MYORGANISATION OU MYUNIT cert_subject_style enroll creator generic csr_digest_alg sha256 csr_key_alg rsa csr_key_params key_length 4096 csr_subjectCN=20210506-C-220638,OU=MYUNIT,O=MYORGANISATION,C=FR csr_subject_key_identifier A4:50:D7:F8:BA:A5:1D:EB:3B:C6:9D:AB:EB:9C:00:12:8A:DA:81:D0 error_codeRenewal request is for certificate from foreign realm! interface scep p_allow_anon_enroll0 p_allow_eligibility_recheck1 p_allow_man_approv 1 p_allow_man_authen 0 p_allow_replace 1 p_approval_points 0 p_auto_revoke_existing_certs 1 p_max_active_certs 1 pkcs10 -BEGIN CERTIFICATE REQUEST- MIIEuTCCAqECAQAwUzELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDk1ZT1JHQU5JU0FU SU9OMQ8wDQYDVQQLEwZNWVVOSVQxGjAYBgNVBAMTETIwMjEwNTA2LUMtMjIwNjM4 MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvFMd313lzD1i+A5u2l7i 9oLQnZXhG6usD2tYJq1NcuUE++YTxQ+PDbb2EPfcClEc7/Xyurn+TMPeU7opPdxP 3IQx23H1Y4UbIzv0k8WJckCj1zwnSgQllJzXefAImezJTSlV9IAo8UB9uXTxbbzu CipYD+GcbDMKN1Wjjn6ngtjIdmYgnsc1x/UBUsmb7rrtWcI7dMEgrw7hkJThw+EW XwL7l1TnVPUVTFxkIvrOzCatWA/HUNCeiE5XeERYwyZ6WwkpVv+ufO3tMVxhsu5r TzxxAr1Xk1P7/9izAYzJ4CwRI2UuTqo5nOXNHdqcQpcJWqHwpYfCqwtlPZdOyx6a fuEnvQW7V8P/PQ2ttbJ9CGk4sWB7Y2GHAEPCb1gxKl9rEHAh3b/uNvXHaBo09F6G JCDQqZpVVAxcZkHSuf9BMJzU3A8mkxdONWDd6q4VYvMN+5eSJHEgT5r15nEStmUD e/UFGW/2WouYxONASVFbljm6JjsOX49p6zhh4Fq0vZM1YETbIqhYCN3CPibgYXQn nBKHCnCInLi0pM3fqIE+HAFSI8/0Rbp38kbfNCkjyVGyjBED4MUVJeIlemgop0Jk pFFtv2JZjIbagjm8OqJ4UnRtCELinGnQeWCyya4gX5KnWZUEEojNQmUJKVO34eHF L7MQvfrZK50f875rbwTuEEcCAwEAAaAhMB8GCSqGSIb3DQEJBzESExB4eHh4WFhY WHh4eHhYWFhYMA0GCSqGSIb3DQEBCwUAA4ICAQCLorLSJgWwsXD50uWlUtyHdcSY nDygUe6l9gb53tuvsrMpqTcPOUcTFUJys4OtQ8gcN0HPfhO/O6LUoNx9kYpJc4Xd iaRscx+u2FetQbpwsO8D1JZeMfvBz3R7Znpu8mZm/aggX8ZRE184/Cok9kJIcGbI 4dhJ2Qw6/H3rjnn+0PenqHXH97WuVYpmJDHJuHvX4YWY4X4LF46sMObT3+JoBYNR c7EKVRyoYGltcoOEVjQLSi86992V5R5Ddd3x1pfLcMOnK8lGLUxIZhfqY6IWPiRo tyINtQn1egS6Jwohns5qU5YLEsZcfdzywwDc/cvP/7n2qpzrYxv9zXd0P91OVS3P Pr+rE794N8kQmS4y671aoq/UCwAFMbP5YS4zmhfjA0iKJvTYSOGp8RjofKjUC7IZ 2mYC1YgDo4uudzyCquJlHSAVV85K+qV4urjtIT7vFgNcduQbtK44+pU0zc7QQY+r EWacWNMeOORbH9FUrfQ3svoFNY962glfSbAi8ssYkOfFjgW8yKDj1DRc5BpIPwr1 ZhegqYZLDvYDNEPmcmh0fQXHL6x4MT75S6k/zZqPhJrBq+ESL6aRq29nHUat+Z5N +XhEcNCh/66rDV3bKNoudMbTFyQir4GXEErKaVzXH/WxRlkSuz6j3l+Kz3uZ7wOo ztPnfK1IJ95lb9Frfw== -END CERTIFICATE REQUEST- req_attributes challengePassword request_mode renewal server generic signer_authorized 0 signer_cert -BEGIN CERTIFICATE- MIIFZzCCA0+gAwIBAgIIakzaLfQ1P5wwDQYJKoZIhvcNAQELBQAwUzELMAkGA1UE BhMCRlIxFzAVBgNVBAoTDk1ZT1JHQU5JU0FUSU9OMQ8wDQYDVQQLEwZNWVVOSVQx GjAYBgNVBAMTETIwMjEwNTA2LUMtMjIwNjM4MB4XDTIxMDUwNjIwMDYwMFoXDTIx MDUwNzIwMDYwMFowUzELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDk1ZT1JHQU5JU0FU SU9OMQ8wDQYDVQQLEwZNWVVOSVQxGjAYBgNVBAMTETIwMjEwNTA2LUMtMjIwNjM4 MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvFMd313lzD1i+A5u2l7i 9oLQnZXhG6usD2tYJq1NcuUE++YTxQ+PDbb2EPfcClEc7/Xyurn+TMPeU7opPdxP 3IQx23H1Y4UbIzv0k8WJckCj1zwnSgQllJzXefAImezJTSlV9IAo8UB9uXTxbbzu CipYD+GcbDMKN1Wjjn6ngtjIdmYgnsc1x/UBUsmb7rrtWcI7dMEgrw7hkJThw+EW XwL7l1TnVPUVTFxkIvrOzCatWA/HUNCeiE5XeERYwyZ6WwkpVv+ufO3tMVxhsu5r TzxxAr1Xk1P7/9izAYzJ4CwRI2UuTqo5nOXNHdqcQpcJWqHwpYfCqwtlPZdOyx6a fuEnvQW7V8P/PQ2ttbJ9CGk4sWB7Y2GHAEPCb1gxKl9rEHAh3b/uNvXHaBo09F6G JCDQqZpVVAxcZkHSuf9BMJzU3A8mkxdONWDd6q4VYvMN+5eSJHEgT5r15nEStmUD e/UFGW/2WouYxONASVFbljm6JjsOX49p6zhh4Fq0vZM1YETbIqhYCN3CPibgYXQn nBKHCnCInLi0pM3fqIE+HAFSI8/0Rbp38kbfNCkjyVGyjBED4MUVJeIlemgop0Jk pFFtv2JZjIbagjm8OqJ4UnRtCELinGnQeWCyya4gX5KnWZUEEojNQmUJKVO34eHF L7MQvfrZK50f875rbwTuEEcCAwEAAaM/MD0wHQYDVR0OBBYEFGCik4Dx9ViTWUuA yhPuUNpPfIBvMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBCwUAA4ICAQCUP4YDL3y3RpSU4HBU3OmsqcEYWr6jzvA95ZIHsGX08fp+GJi4 GJdkOBQmli6kY2OZ5H7t/7cLqGtwIlmflfEM4bcdOdhxUqRpiIkzmJeEUBYINJLk WTjBV1RVtwGY2zdqSiLmLBcAZZXCdD8BiGpObKRnBO++UOsz9JLvGUF7SG24tScE OPBpFDgqH0O9JfJgcK2+/6EZFzPyBnqnEWOhuSkw2ErH05hJdsBDh2QGe0X321FU vAhm/nEiFsiO0r8zHrNYDsgYbpMblCYfhTJON67SYxMf3okv4WP+DU62hmJ9Iq9p wcka2C4D3RoU7rff+9CpssvWY5mSlfWQwASd+iKNuKndtGHWqScQDyK2Gbkr7uIA GTdGImA61TQpn5Bv9Zvq+SO6C1qQJSAgsP0jfS6iYRJNeMlBIFmmgDNMSRUbC7ny
