How to sign certificate requests from a client system?

Question

Question

Stephen De Gabrielle · Apr 27, 2017

Hi,

I can't work out how to use the Cache CA Server to process certificate request from external clients!

We are setting up an interface where we use SSL/TLS 'Mutual Authentication' to allow a client system to securely transmit document to our server. (they are off-site and hosting a service for us)

I am not a security expert, but my understanding of setting up mutual authentication where my instance of ensemble is the server, and it is receiving messages from a client is as follows

I create a CA private key and self-signed certificate ( or purchase a cert from one of the big providers)
Generate the server certificate and private key
The client generates their own private key and certificate request.
The client sends me their certificate request (only)
I use my CA private key and their certificate request to create the client certificate
I send the Client certificate and my CA certificate to the client.

When the client initiates a connection with my instance of ensemble, the SSL handshake is used to let both parties confirm they are connecting to who they are connecting to*, and establish a secure channel.

While the SSl/TLS configurations facility supports setting up client and server configurations, the Public Key Infrastructure only seems to support signing a certificate request created in the 'InterSystems Public Key Infrastructure (PKI)':

'5. At this point, you have used Caché to create and submit the CSR.'
(Submitting a Certificate Signing Request to a Certificate Authority Server at http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_pki#GCAS_pki_csr_submit)

Unfortunately to do 'Mutual Authentication' we need to sign a certificate request sent by the client system.

I can use OpenSSL to process the certificate request at the command line, but I'd prefer to use the 'InterSystems Public Key Infrastructure (PKI)' facilities if possible.

Is there a folder I should put the certificate request from exteral clients so the Cache CA Server can 'Process pending Certificate Signing Requests' ?

[If the the 'InterSystems Public Key Infrastructure (PKI)' can't be used to sign certificate requests, I'll write a short post on how to do it with OpenSSL on the command line.]

Kind regards,

Stephen

Discussion (5)0

Log in or sign up to continue

Katherine Reid · May 2, 2017

I agree - that SOP sounds like you have an outside vendor acting as a CA. If you're using a CA vendor that still only supports SHA-1, it may be worth considering looking for a new vendor. Whether an internal or external CA makes sense for you long term can be a complicated question. It's worth having a detailed internal discussion about what your security requirements are and what the risks and benefits of each case are before making that decision.

If you want to look at a PEM-format certificate in order to see who it's signed by, you can run:

openssl x509 -in certificate-to-display.pem -noout -text

where certificate-to-display.pem is the name of the file you want to read. This will display the certificate in a human-readable format. The CA who signed the certificate will be listed in the Issuer field.

2 0

Katherine Reid · May 1, 2017

I'm worried that you may be conflating several ideas here. You said you need to sign your partner's certificate to do mutual authentication. That's not required technically. (Maybe it is required by policy for your particular organizations, but I didn't see you say that so I suspect it's not.)

A CA is a trusted party for verifying identities, usually a third party. You don't need to sign your partner's certificates yourself to do mutual authentication. That's the power of using a CA - you don't have to do identity verification and issue certificates for every possible connection partner, you trust the CA to do it for you.

To use an analogy, if a certificate is a driver's license, then the CA is the state agency that issues licenses. If you operate a service where you need to check identities of people, you don't need to start issuing your own licenses, you can just trust ones issued by states that you think 1) do a good job checking identities before giving out licenses and 2) you recognize and know how to tell if they're real.

To do mutual authentication, you need to have a certificate, and the other side needs to have a certificate. Both certificates need to be signed by CAs the other side trusts - meaning your certificate needs to be signed by a CA that your partner trusts, and their certificate needs to be signed by a CA you trust.

You can (and probably should) get your certificates for use in TLS connections with Ensemble/HealthShare through whatever processes you normally use for generating certificates.

2 0

score 0 · Answer 1 · 2017-04-27T12:23:55-04:00

Hi,

wrc just confirmed that externally created certificates can't be signed using the IPKI

If you need to sign a certificate request to create a client certificate, you can use openssl:

openssl x509 -req -days 365 -in [client]request.crs –signkey YOUR-CAprivatekey.pem -out [client].cer

This uses your private key to sign their certificate request to create their client certificate.

You should send your CA certificate (not the private key) and the signed client certificate back to the client.

score 0 · Answer 2 · 2017-05-02T06:50:56-04:00

Thanks for the clarification, I think I was a bit confused. I was working from an existing SOP which may be wrong, but as it is based on the assumption that we don't have a CA. (Our organisation is the client sending messages to the vendors server)

The SOP (summarised) is:

Client generates private key(a) and certificate request(b)
(openssl req -new -keyout privatekey.pem -out request.crs -days 9125 -newkey rsa:2048 -sha1 [2])
the certificate request(b) is sent (securely) to vendor
the vendor signs the certificate request and and returns both the client certificate(c) and their ceritficate(d)
we create a SSL/TLS configuration that our service will use to connect to the vendors server: we populate the following fields:
1. trusted Certificate Authority X.509 certificate(d) - supplied from the vendor
2. client certificate(c) - returned by the vendor after we sent our certificate request
3. client private key(a) we created initially.

In this case I think the vendor is acting as the CA by signing our certificate request. (I've tried inspecting the certificate they provided but I'm not sure how to tell if it is self-signed, or signed by one of the big CA's)

I think this is fine for testing, and maybe while we have a small number of interfaces, but in the longer term I believe we need to manage this properly: use the cache Certificate Authority server, and 'Caché Credential Sets'.

---

[1]simplified summary of Mutual Authentication from https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

1.A client requests access to a protected resource.
2.The server presents its certificate to the client.
3.The client verifies the server’s certificate.
4.If successful, the client sends its certificate to the server.
5.The server verifies the client’s credentials.
6.If successful, the server grants access to the protected resource requested by the client.

---

[2] we know we shouldn't use sha1 but are limited to what the vendor supports.

score 0 · Answer 3 · 2017-05-03T10:26:49-04:00

Thanks

good point about SHA1

- this is brilliant:

I:\Projects\certiificates>openssl x509 -text -in certsForStunnel.pem -noout Certificate: Data: Version: 3 (0x2) Serial Number: af:0c:7a:b9:44:11:6c:e8 Signature Algorithm: sha1WithRSAEncryption Issuer: C = GB, ST = West Somewhere, L = Town, O = XXX, OU = HL7, CN = VENDOR HL7 Messaging API Validity Not Before: Apr 13 10:48:24 2017 GMT Not After : Apr 7 10:48:24 2042 GMT Subject: C = UK, ST = London, L = London, O = LNWH NHS Trust, CN = TIE Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:e0:24:df:16:3d:d4:ed:1f:b0:4a:2b:6a:07:a7:
[truncated]