Our team is using AWS Lambda functions and API Gateway to facilitate connections to open banking API's within Europe. (PSD2).
Our Lambda's are written in NodeJS.
PSD2 requires Mutual TLS, which is fine and we have everything correctly implemented and working in a sandbox environment.
An example request would look something like this:
{
hostname: '[bank hostname]',
path: '[bank api endpoint]',
method: 'GET',
headers: {
accept: 'application/json',
signature: 'XXX',
date: 'XXX',
digest: 'XXX',
'x-request-id': 'XXX',
'tpp-signature-certificate': '[PATH_TO_CERTIFICATE]',
authorization: 'Bearer [accessToken]',
},
cert: fs.readFileSync('/var/task/certs/cert.crt'), // Buffer
key: fs.readFileSync('/var/task/certs/private.key'), // Buffer
}
The problem we currently have is that we are unsure where to securely store our certificates. For the time-being, we are just storing them in an assets folder in our codebase, this is not ideal and we would like to move them out of our codebase for obvious reasons.
We have been looking at AWS ACM. However it is not clear how we would retrieve a path to certificates (after uploading them) in order to use it in the request above.
So my question is how would we use AWS to securely store our certificates in such a way that we can use them in a HTTPS request?
You cannot retrieve certificates from ACM, in fact these are attached to AWS resources only such as CloudFront, ELBs and API Gateway.
To retrieve the contents there is a couple of solutions.
The first is to store this in a credential/secrets store, AWS provide this functionality in the secrets manager service. Additionally you can store a SecureString in the systems manager parameter store.
Alternatively you could use a third party solution such as HashiCorp Vault.
With this approach if you need the file to exist on disk you will need to store the output in the tmp file storage.
If these approaches do not work for you, you could make use of AWS EFS. A recent addition has added support to allow Lambdas to have a NFS mount attached to share storage.
I think ultimately you are looking for a solution like AWS KMS or CloudHSM, which would allow you to securely store your private keys and perform cryptographic functions rather than reveal the keys for "external usage". This is the most secure way as even you won't be able to see the keys (although CloudHSM actually allows to upload/download keys).
As Node.js TLS module is based on OpenSSL and CloudHSM comes with ready-made openssl engine that you'll be able to use for Mutual TLS. Options privateKeyEngine, privateKeyIdentifier, publicKeyEngine and publicKeyIdentifier of tls.createSecureContext are to be used for that.
For AWS KMS (which is a way more cost-efficient solution) there is open source openssl engine written in Rust.
That being said, I'm not sure if you are able to use custom openssl engines in Lambda or if CloudHSM engine is included into Lambda's Node.js environment (which would be very logical). So you may also choose to "offload" mutual TLS connectivity to a "micro service" running outside Lambda. We went this way and implemented a very simple broker "proxying" mTLS calls using securely stored private keys.