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* identical
    Subject: DC=org, DC=OpenXPKI, DC=Test Deployment client TLS enroll,
CN=testme2

However, when adding some prints to SubjectsMatch.pm, it shows that they
are _not_ the same -> resulting in a failure

SubjectsMatch()

subject1: CN=testme2,DC=Test Deployment client TLS enroll,DC=OpenXPKI,DC=org
subject2: CN=testme2,DC=org, DC=OpenXPKI, DC=Test Deployment client TLS
enroll
dont match





problem I concatenated the DC= entries incorrectly in my CSR,
I did

openssl req -keyout test.key -subj "/DC=org, DC=OpenXPKI, DC=Test
Deployment client TLS enroll/CN=testme2" -nodes -new -newkey rsa:2048 >
test.csr

I should do

openssl req -keyout test.key -subj "/DC=org/DC=OpenXPKI/DC=Test Deployment
client TLS enroll/CN=testme2" -nodes -new -newkey rsa:2048 > test.csr



I had one DC= entry with contents:   "org, DC=OpenXPKI, DC=Test Deployment
client TLS enroll/CN=testme2"
The 2nd entry gives 3 DC= entries with contents:  "org", "OpenXPKI", "Test
Deployment client TLS enroll"

When just looking at the "Subject:" line of openssl output... you don't see
the difference.


Now it "just works" (tm).


Thanks.

-Harm


On Wed, Jun 14, 2023 at 3:12 PM Harm Verhagen <h...@symeon.nl> wrote:

> 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 Deployment client TLS enroll,DC=OpenXPKI,DC=org).
> 2023/06/14 13:05:46 91903 Condition check for exist: path
> est.mobility.authorized_signer, exist: yes
> 2023/06/14 13:05:46 91903 Condition check for exist: path
> est.mobility.authorized_signer, exist: yes
> 2023/06/14 13:05:46 91903 Execute action *enroll_set_mode_onbehalf *
> 2023/06/14 13:05:46 91903 Condition check for exist: path
> est.mobility.authorized_signer, exist: yes
> 2023/06/14 13:05:46 91903 Setting context request_mode to onbehalf
> 2023/06/14 13:05:46 91903 Execute action
> global_set_error_signer_not_authorized
>
> from certificate_enroll.yaml I see
>
> is_renewal_request:
> class: Workflow::Condition::LazyAND
> param:
> condition1: enroll_signer_subject_matches_csr_subject
> condition2: "!enroll_signer_key_matches_subject_key"
>
> is_onbehalf_request:
> class: Workflow::Condition::LazyAND
> param:
> condition1: global_has_authorized_signer_rules
> condition2: "!enroll_signer_subject_matches_csr_subject"
> condition3: "!enroll_signer_key_matches_subject_key"
>
>
> So  "!enroll_signer_subject_matches_csr_subject"   seems to fail?  (Or
> its not evaluated at all?)
>
> I have a hard time finding that in the sources though.... Do you have some
> pointers?
>
> -Harm
>
>
> On Wed, Jun 14, 2023 at 1:02 PM Harm Verhagen <h...@symeon.nl> wrote:
>
>>
>>
>> On Thu, Jun 8, 2023 at 8:48 PM Oliver Welter <m...@oliwel.de> 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 of the "subject matches" condition class, the details are
>>> in the perldoc of it.
>>>
>>
>> Ah, it needs the full DN. clear.
>>
>> However...
>> when I do that, I get the same result when trying renewal:
>> I18N_OPENXPKI_UI_ENROLLMENT_ERROR_SIGNER_NOT_AUTHORIZED
>>
>> The subjects are identical now
>>
>> $ openssl req -in test.csr -noout -text |grep Subj |grep CN
>>         Subject: DC=org, DC=OpenXPKI, DC=Test Deployment client TLS
>> enroll, CN=testme2
>>
>> $ openssl x509 -in test_issued.crt -noout -text |grep Sub |grep CN
>>         Subject: DC=org, DC=OpenXPKI, DC=Test Deployment client TLS
>> enroll, CN=testme2
>>
>>
>> But
>> curl  -H "Content-Type: application/pkcs10" --data @test.pem  --key
>> test_issued.key --cert test_issued.crt --insecure
>> https://localhost:8443/.well-known/est/mobility/*simplereenroll*
>> gives
>> I18N_OPENXPKI_UI_ENROLLMENT_ERROR_SIGNER_NOT_AUTHORIZED
>>
>>
>> It seems that my openxpki does no 'subject matches' rule check at all, it
>> just checks if the signer is in an auth list.  (that sounds like
>> an authorized_signer thing, but that's not what i'm trying here, I'm trying
>> renewal)
>>
>> What am I missing here?
>>
>> Logs below
>>
>> -Harm
>>
>>
>> ==> openxpki.log <==
>> 2023/06/14 10:54:20 INFO Login successful (user: Anonymous, role: System)
>> [pid=116|sid=yvwb|pki_realm=mobility]
>> ==> catchall.log <==
>> 2023/06/14 10:54:20 openxpki.auth.INFO Login successful (user:
>> Anonymous, role: System) [pid=116|sid=yvwb|pki_realm=mobility]
>> ==> workflows.log <==
>> 2023/06/14 10:54:21 83199 Rendering subject: CN=testme2,DC=Test
>> Deployment client TLS enroll,DC=OpenXPKI,DC=org
>> ==> catchall.log <==
>> 2023/06/14 10:54:21 openxpki.application.INFO Rendering subject:
>> CN=testme2,DC=Test Deployment client TLS enroll,DC=OpenXPKI,DC=org
>> [pid=116|user=Anonymous|role=System|sid=yvwb|wftype=certificate_enroll|wfid=83199|pki_realm=mobility]
>> ==> workflows.log <==
>> 2023/06/14 10:54:21 83199 Trusted Signer chain validated - trusted root
>> is tzw4UJlDLemD55ojDPxmAHU-4F8
>> ==> catchall.log <==
>> 2023/06/14 10:54:21 openxpki.application.INFO Trusted Signer chain
>> validated - trusted root is tzw4UJlDLemD55ojDPxmAHU-4F8
>> [pid=116|user=Anonymous|role=System|sid=yvwb|wftype=certificate_enroll|wfid=83199|pki_realm=mobility]
>> ==> catchall.log <==
>> 2023/06/14 10:54:21 openxpki.application.INFO trustrule
>> HASH(0x55816c4df368)
>> [pid=116|user=Anonymous|role=System|sid=yvwb|wftype=certificate_enroll|wfid=83199|pki_realm=mobility]
>> ==> workflows.log <==
>> 2023/06/14 10:54:21 83199 Trusted Signer not found in trust list
>> (CN=testme2,DC=Test Deployment client TLS enroll,DC=OpenXPKI,DC=org).
>> ==> catchall.log <==
>> 2023/06/14 10:54:21 *openxpki.application.INFO
>> <http://openxpki.application.INFO> Trusted Signer not found in trust list*
>> (CN=testme2,DC=Test Deployment client TLS enroll,DC=OpenXPKI,DC=org).
>> [pid=116|user=Anonymous|role=System|sid=yvwb|wftype=certificate_enroll|wfid=83199|pki_realm=mobility]
>> ==> est.log <==
>> 2023/06/14 10:54:21 INF Disconnect client [pid=113|ep=[undef]]
>>
>>
_______________________________________________
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users

Reply via email to