Hi Ralf,

please respond or at least cc the list...

The workflow expects the PKCS10 including the "-----BEGIN
CERTIFICATE-----" headers and linebreaks.

This should do (where CSR is the path to the csr file generated with
openssl req..)
curl -X POST --form pkcs10="`cat $CSR`"

best regards

Oliver

Am 18.10.2018 um 17:39 schrieb Ralf Spenneberg:
> Hi Oliver,
> 
> that works. Thanks a lot. Now for the complicated part.
> I am trying to use the RequestCertificate method using curl. But
> unfortunately I do not know how to format the Post data. Is there any
> documentation available? How do I pass the pkcs10 file?
> 
> I tried --data "pkcs10=MIICnzCCAYcC...."
> This does not work. I am getting error code 42.
> 
> Kind regards,
> 
> Ralf
> 
> Am 18.10.18 um 16:35 schrieb Oliver Welter:
>> Hello Ralf,
>>
>> welcome to OpenXPKI - nice to hear you like it.
>>
>> I guess you get a 500 server error back? At least I do - in that case
>> you find the error message in the apache error log.
>>
>> The short story: Certificate.dn returns a hash but you need a string,
>> use "Certificate.dn(context.cert_identifier,'CN')" to get the common
>> name back.
>>
>> In the end it should not crash but - congrats - you found a bug ;)
>>
>> The root cause explained:
>> * Certificate.dn returns a hash
>> * The "_map..:[% .. %]" notation internally calls a template parser that
>> returns a string
>> * Perl converts the hash into a string "HASH(0x1234)"
>> * The server has not problem in sending that to the client - so all is fine
>>
>> Why this causes a problem took me while to find out...when returning the
>> data back to the user, we analyse if a value is a serialized array/hash
>> and our old serialization protocol used "HASH" as a marker. So what
>> happens here is that the serializer thinks this is a hash encoded in the
>> legacy format and crashed on deserializing it as the used filter was sloppy.
>>
>> Oliver
>>
>>
>> Am 18.10.2018 um 07:01 schrieb [email protected]:
>>> Hi,
>>>
>>> I am just starting evaluating openxpki for a project.
>>>
>>> I am using openxpki on Debian Jessie using the packages and am
>>> strugglinc with the PEM download. I read the conversation between
>>> Andreas Krieger and Oliver Welter. Apparently Andreas got it to work by
>>> modifying the template plugin Template/Plugin/Certificate.pm
>>>
>>> To get a feeling for the process, I tried to first include the dn in the
>>> output of the rpc SearchCertificate. I just started modifying the
>>> rpc/default.conf file and including dn in the output of the
>>> SearchCertificate, since dn is already mentioned in
>>> the template plugin:
>>>
>>> [SearchCertificate]
>>> workflow = certificate_search
>>> param = common_name
>>> output = cert_identifier, notbefore, notafter, status, dn
>>>
>>> I also changed config.d/realm/ca-one/workflow/def/certificate_search.yaml
>>>
>>>     get_certificate_data:
>>>         class: OpenXPKI::Server::Workflow::Activity::Tools::SetContext
>>>         param:
>>>             _map_notbefore: "[% USE Certificate %][%
>>> Certificate.notbefore(context.cert_identifier) %]"
>>>             _map_notafter: "[% USE Certificate %][%
>>> Certificate.notafter(context.cert_identifier) %]"
>>>             _map_status: "[% USE Certificate %][%
>>> Certificate.status(context.cert_identifier) %]"
>>>             _map_dn: "[% USE Certificate %][%
>>> Certificate.dn(context.cert_identifier) %]"
>>>
>>>
>>> While I got the following output without these changes:
>>> $ curl --data "method=SearchCertificate"  --data "common_name=test"
>>> http://localhost:8080/rpc
>>> {"result":{"data":{"notbefore":"2018-10-17T16:35:46","notafter":"2019-04-17T16:35:46","cert_identifier":"rbaixzzFogGSt9WIR68A8gzbAXM","status":"ISSUED"},"state":"SUCCESS","id":0,"pid":1170}}3
>>>
>>> unfortunately I now get nothing and the logfiles do show the processing:
>>> ==> /var/log/openxpki/rpc.log <==
>>> 2018/10/18 04:58:43 DEBUG:757 Config for service rpc loaded
>>> 2018/10/18 04:58:43 INFO:757 RPC handler initialized
>>> 2018/10/18 04:58:43 DEBUG:757 Autodetect config file for service rpc: .conf
>>> 2018/10/18 04:58:43 DEBUG:757 No config file found, falling back to default
>>> 2018/10/18 04:58:43 DEBUG:757 RPC unauthenticated (plain http)
>>> 2018/10/18 04:58:43 DEBUG:757 Initialize client
>>> 2018/10/18 04:58:43 DEBUG:757 Started volatile session with id:
>>> tNRIg98WTDCi11ITTK8SAw==
>>> 2018/10/18 04:58:43 DEBUG:757 Selecting auth stack _System
>>> 2018/10/18 04:58:44 DEBUG:757 Workflow created (ID: 0), State: SUCCESS
>>> 2018/10/18 04:58:44 INFO:757 RPC request was processed properly
>>> (Workflow: 0, State: SUCCESS
>>> 2018/10/18 04:58:44 DEBUG:757 Keys cert_identifier, notbefore, notafter,
>>> status, dn
>>>
>>> ==> /var/log/openxpki/workflows.log <==
>>> 2018/10/18 04:58:43 0 Execute action certsearch_initialize on workflow #0
>>> 2018/10/18 04:58:44 0 Execute action certsearch_pop_identifier on
>>> workflow #0
>>> 2018/10/18 04:58:44 0 Execute action certsearch_get_certificate_data on
>>> workflow #0
>>>
>>>
>>>
>>> Is anything else required to modify the workflow?
>>>
>>> Kind regards,
>>>
>>> Ralf
>>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenXPKI-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/openxpki-users
>>
> 


-- 
Protect your environment -  close windows and adopt a penguin!

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users

Reply via email to