Hi Oliver,
this works great. I now can request certificates. I even got it to work
without authentication and authorization thanks to other emails from
this list.
My ultimate goal is the preparation of a PKI which may be used in a M2M
setup for embedded systems to automatically request and retrieve
certificates.
I modified the SearchCertificate endpoint to retrieve the PEM file as
well. This works nicely. I modified
/etc/openxpki/rpc/default.conf
/etc/openxpki/config.d/realm/ca-one/workflow/def/certificate_search.yaml
Here I added the mapping
/usr/lib/x86_64-linux-gnu/perl5/5.20/OpenXPKI/Template/Plugin/Certificate.pm
The last file was modified based on the current code adding the pem part.
Unfortunately I now have the problem to connect the request with the
search. The request sends back the cert_identifier. The search only
supports the commonName. Is it possible to modify the request to map the
PEM file as well? I looked at the workflow and compared it to the search
workflow and tried the following changes:
--- certificate_enroll.yaml.orig 2018-10-19 07:33:29.985461405 +0000
+++ certificate_enroll.yaml 2018-10-19 07:29:55.422065179 +0000
@@ -252,11 +252,14 @@
SUCCESS:
label: I18N_OPENXPKI_UI_WORKFLOW_STATE_CERT_ENROLL_SUCCESS_LABEL
description:
I18N_OPENXPKI_UI_WORKFLOW_STATE_CERT_ENROLL_SUCCESS_DESC
+ action:
+ - get_certificate_data > NOCHANGE
output:
- cert_identifier
- server
- interface
- cert_subject
+ - pem
- cert_profile
- request_mode
- is_replace
@@ -301,6 +304,15 @@
- _url_params
- transaction_id
+ 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,'CN') %]"
+ _map_pem: "[% USE Certificate %][%
Certificate.pem(context.cert_identifier) %]"
+
accept_request:
class: OpenXPKI::Server::Workflow::Activity::Noop
label: I18N_OPENXPKI_UI_WORKFLOW_ACTION_ENROLL_ACCEPT_REQUEST_LABEL
Obviously this does not work. I know at least part of PEM output is
planned for 2.2. Is there a release date available?
Kind regards,
Ralf
Am 18.10.18 um 17:59 schrieb Oliver Welter:
> 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
>>>
>>
>
>
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
