Help with SOAP CA implementation / Example

[anaryk]

Hi, I am new to python and PKI and would like some advice please. I would like to deploy this ACME proxy against a CA I have already deployed and unfortunately it is without ACME. But unfortunately the only call it has is SOAP, see attached documentation below. Would it be possible to add an example of how to integrate this soap ? Thank you very much in advance for your help, it will save me.

SOAP Interface:

Name: RequestCertificate () - It verifies the signed request in the PKCS7 format and, in case of successful verification, issues a certificate to the CA. - Input: RequestCertificateInput - Output: RequestCertificateResult

Input RequestCertificateInput

Attribute:

1. ProfileName - String - The profile defined for the certificate type
2. CertificateRequestRaw - byte[] in Base64 - PKCS7 signed PKCS10 application in DER format
3. Email - String - email
4. ReturnCertificateCaChain - bool - Return only the certificate, or the certificate including the chain of parent certificates.

Output RequestCertificateResult

Attribute:

1. IssuedCertificate - byte[] in Base64 - DER certificate or P7b certificate chain

Thank you very much for any help

[grindsa]

Hi, can you tell me the name of the CA? Is it a commercial product or rather something homegrown? Is there any chance to get access to a test-system?

Technically you have to create a new ca-handler and extend the enroll method by the respective SOAP calls. But this requires a bid of python know-how. So it might be faster if I could access the CA and modify the handler myself.

[anaryk]

Unfortunately, the authority has no public testing API. It is a modified windows CA authority by some external company and the only thing that has been provided is the specification of SOAP API, see the picture below. Therefore I wanted to ask if it would be possible to make an example according to the specification, which I could then try to implement and deploy. After that, only light adjustments might be enough for me to handle the proper function. Unfortunately, I currently don't fully understand how exactly ca_handlers work, combined with my poor python knowledge I am not able to create a handler all by myself. Thank you very much in advance for your help.

[grindsa]

Do you see any chance to capture the message flow in clear-text and send me the SOAP-calls going back and forth?

[anaryk]

@grindsa I am sending soap communication in xml. I modified the certificate it returned in base64 to not pasting cert here :-)

[grindsa]

Thank you that helps. Let me try to mock this over the weekend. Will try my best... Is there any authentication layer to be used?

[anaryk]

Thanks a lot. Authorization is done by client certificate.

[grindsa]

I started to prototype a handler but I have a question:

I read from the Spec that we need to send the CSR as "pkcs7 signed pkcs10 request". Who is expected to sign the request?

I understand the purpose of signatures in case of cert renewals which is btw. not possible as acme-clients do send CSRs in pkcs10 format without attaching the existing cert (prove of possession is done via different mechanism). But for new enrollments this signing operation a bid unclear. Can you please clarify?

Thx

[anaryk]

If I understood it correctly, the authorization of the SOAP call is to sign the CSR with the client certificate. I looked at their sample CSR and it looks like it is signed with the client certificate. And the soap call itself doesn't look like it requires certificate authentication.

[grindsa]

ok. This makes sense... So implementation will be in a way that the pkcs10 CSR will be wrapped into an pkcs7 construct, the client certificate from acme2certifier will be attached and the corresponding private key will be use to sign the message.

Two other questions:
Is the communication with the soap server based on https? If you, do you need an option to load a CA certificate to validate the soap-server certificate?

Are you running acme2certifier in a docker-container? if so which version? I am asking as I am looking for best way to provide you development versions for testing...

[anaryk]

Great, thanks so much for your help.

Yes the communication is over https, so we will need to be able to load the truststore CA as you write.

I tested this with the latest version of acme2certifier as a docker-container. So in docker it would be best

[grindsa]

Another question. I need some examples of failed enrollments to implement proper error-handling. Any chance to get some traces or extracts from the documentation how error messages send back to client do look like?

[anaryk]

I tested calling soap through postman. The request ends with the code 500

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<s:Body>
<s:Fault>
s:Client
Processing RequestCertificate - Error! by request={ProfileName=SSL 2Y AUTO,CertificateRequestRaw.Length=2486,Email=test@test.cz,ReturnCertificateCaChain=True}, profile=SSL 2Y AUTO, pkcs7initials=, ErrorMessage=Cannot parse PKCS7 message!
</s:Fault>
</s:Body>
</s:Envelope>

[anaryk]

responseError.zip

[grindsa]

Ok. First version got uploaded and is ready for your testing. I uploaded a image for testing to docker.

you can install it with docker pull grindsa/acme2certifier:soap_handler

You need to configure the handler as shown below:

[CAhandler]
handler_file: examples/ca_handler/pkcs7_soap_ca_handler.py
soap_srv: <http://name of your soap server:<port>
signing_cert: /var/www/acme2certifier/volume/certs/sig_cert.pem
signing_key: /var/www/acme2certifier/volume/certs/sig_key.pem
ca_bundle: /var/www/acme2certifier/volume/certs/ca_bundle.pem
profilename: <profile name>
email: <email address>

Some more but basic documentation

Feel free try it. I am interested in the outcome :-) If you have questions let me know...

[anaryk]

Thank you very much. I already wanted to start deploying and testing, but unfortunately I ran into one more "little thing" and I'm not sure if it will have a solution. The certificate to be used to sign CSRs must be stored on/in the HSM. I didn't get this information until now. So the question is if python can emulate the HSM to sign the request.

[grindsa]

I need to check in detail but in principle it should be possible to use the OpenDNSSec SoftHSM and authenticate the access via Pin. However I am wondering about the advantage of this over a solution storing the private key in an encrypted form in either pkcs#8 or pkcs#12 format and use a passphrase for authentication which is much easier to implement. Other options would be to use a a docker secret or use a vault. Any thoughts on this?

[anaryk]

Unfortunately, the certificate for the signature is issued by another person and I tried to convince him to use p12 or p8 with a password, but he was unfortunately adamant and insisted on storing the key using HSM. If OpenDNSSec SoftHSM was used, would it be enough to insert the pin using some K8S secret for example? I'm not entirely sure how software HSM works. I've tried project
SoftHSMv2 and also other references in google, but unfortunately I'm still not wise of the implementation.

[grindsa]

That's a weird comment as a software HSM does not provide any benefit over an encrypted PKCS#8 file.

I need to look into it but below some links with further information.

https://www.howtoforge.com/tutorial/how-to-install-and-use-softhsm-on-ubuntu-1604-lts
https://clydedcruz.medium.com/a-dive-into-softhsm-e4be3e70c7bc
https://www.cooltym.com/post/pkcs-11-test-with-softhsm
https://developers.cloudflare.com/ssl/keyless-ssl/hardware-security-modules/softhsmv2/

Can you feed the pin via environment variable to the docker container just to avoid messing around with the kubernetes API? Sorry I am not a k8s expert and this would ease things a lot...

[anaryk]

I'm still considering the option that the person who requires high security on the VM where it would run would install and manage his own HSM software and provide a command with which it should be possible to sign the CSR. What I have according to the initial documentation

/opt/signer/signer_TEST.sh <path_to_unsigned_csr> <path_to_store_signed_csr> <SIGNER_ALIAS> <CONFIG_VARIANT>

But unfortunately this will probably mean leaving the option of deploying in the docker, since their signer will be installed directly on the VM.

More on k8s. The k8s secret is basically a base64 encoded string. But from a vanilla kubernetes perspective, it's the most secure option for storing passwords. There are some alternatives like vault that work with more encryption but it's not part of kubernetes. I'll prepare a K8S deployment using Helm for acme2certifier as well if anyone would like to use it.

[grindsa]

I think it depends what the signer-script is doing. But most probably you are right. However, I seriously doubt that the above approach is more secure than what we discussed before (storing the private key encrypted and use a passphrase fed by either secret or an environment variable to decrypt it).
Thanks for your explanation on k8s We have some basic yaml files for deployment but I am sure they can be improved as we are using the files to test cert-manager interoperability during regression... There is also some documentation available.

[anaryk]

Basically you're right, but unfortunately from their security perspective the signing certificate will not be available on FS and will be in their HSM software and basically they will provide a shell that already performs the signing, which they believe is the most secure.

According to the latest information, the script takes the path to the unsigned CSR as a variable and the next argument is where to insert the signed CSR. Is it possible to somehow get the CSR from acme2certifier, externally sign it and then proceed with the signed one? There would have to be some temporary folder where it would be stored for the duration of the signature. Would it be possible to do this in python somehow ?
I've been looking at the yamls you have for k8s deployment and it would be better to convert it to Helm, which I can certainly do.

[grindsa]

I think this should be doable. Do we have to trigger any action after placing the CSR? Further; can we agree to use any random string as filename and get the signed CSR in a kind of _signed.p7b?

[anaryk]

I had to go on vacation, sorry for the late reply :-) but basically once there is a CSR that is unsigned it should call the bash signer script that takes as arguments /opt/signer/signer_TEST.sh <path_to_unsigned_csr> <path_to_store_signed_csr> <SIGNER_ALIAS> <CONFIG_VARIANT> these two last variables will always be the same, so just insert them from config will be best. So if the first will be the path to the CSR that ACME will generate to temp and the second will also be some temp, but with the acme server knowing where to reach for the signed CSR so that it can be sent using that soap.

[grindsa]

No problem at all as i am on holidays as well. Let me give it a try next few days...

Current plan is to add few additional variables:

signing_script: /opt/signer/signer_TEST.sh
csr_path: /tmp/csr - filename will be a random value
signer_alias: no_default
config_variant: no_default
sleep_timer: 5

sleep_timer is the duration of the signing operation. Do you think that this is enough?

[anaryk]

So enjoy the holidays.

Yeah, I think that is enough. I was just thinking of one more thing. In the example script they call that bash for signature still via sudo, because it is installed under another user. So it's basically like this: sudo -u nfast /opt/signer/signer_TEST.sh <path_to_unsigned_csr> <path_to_store_signed_csr> <SIGNER_ALIAS> <CONFIG_VARIANT>. So if you could add sudo option with custome user selection(assuming the user it's running under is set to passwordless in sudoers for specific signer account) that would be best.

[grindsa]

Quick question. Does the /opt/signer/signer_TEST.sh script expect the CSR to be in DER or PEM format?

[anaryk]

DER format

[grindsa]

ok I modified the handler according to what we discussed before. The changes made it alread into the devel branch; there is also a docker image available which can be installed via docker pull grindsa/acme2certifier:devel. In case you have already an a2c server running it should be enough to just replace the ca_handler. Below my configuration for reference. I was unfortuately not able to test the signing_user option but I do not see a reason why this should not work as long as sudo is configured correctly.

[CAhandler]
handler_file: examples/ca_handler/pkcs7_soap_ca_handler.py
soap_srv: http://192.168.14.131:8888
ca_bundle: acme_srv/cmp2/ca_bundle.pem
profilename: Profile
email: grindsa@foo.bar
signing_script: /var/www/acme2certifier/volume/mock_signer.py
signing_user: signer
signing_interpreter: py  # optional
signing_alias: alias
signing_csr_path: acme_srv/soap
signing_config_variant: cfg_variant

Give it a try and let me know who it goes...