Mutual Authentication in CloudHub
As a security measure, mutual authentication, also known as two-way authentication, requires entities to authenticate one another before speaking to one another. This means that in a networked context, digital certificates verifying the identities of the client and server are required.
What is Mutual Authentication working in CloudHub?
The term “mutual authentication” refers to a TLS connection over HTTP (also known as HTTPS) in which the source and target apps verify against predetermined standards the certificate that was issued to establish the connection. The TLS channel is not formed and no connection is permitted if these requirements are not satisfied.
Why Mutual Authentication?
This offers transport-level security between two systems.
How Mutual Authentication?
Mutual Authentication working in CloudHub works in two ways. there are.
- API exposed by CloudHub.
- API called by CloudHub
SSL termination is managed by the load balancer. A different name for each “certificate” endpoint that the load balancer loads must be depending on the certificate’s CN. Utilizing OpenSSL, create a public/private key pair.
openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pemopenssl rsa -in key.pem -out key-decrypt.pemCertificate presented by CloudHub
In the case of Salesforce, it will only accept connections containing a certificate signed by a trusted global CA. So a Certificate Signing Request (CSR) generated from the private key.
openssl req -new -sha256 -key key-decrypt.pem -out <outfilename>.csrAnd sent to Logical Minds for signing by their authority of choice. The resultant set of certificates was concatenated local cert first then intermediate user certificate, into a single file (api__cert_chain.crt) which used to replace the Public Key value in the Load Balancer “certificate”.
cat <our server>.crt <trustedintermediary>
<.crt.root>.crt > cert_chain.crt
Certificate presented to CloudHub
A second public/private key pair was created to act as CloudHub Certificate Authority (CA).
openssl genrsa -out rootCA.key 4096 openssl req -x509 -new -nodes -key
rootCA.key -days 365 -out rootCA.crtCA cannot be downloaded from CloudHub and is stored on internal confluence. CSRs are sent in from source applications (for example Salesforce, SAP) and these are signed by the CA key to generate a certificate.
openssl x509 -req -in <csr_from_source>.csr -CA rootCA.crt -CAkey
rootCA.key -CAcreateserial -out <source>.crt -days 365This output .crt certificate is sent back to the source application.
Certificate presented to CloudHub
A second public/private key pair was created to act as CloudHub Certificate Authority (CA).
openssl genrsa -out rootCA.key 4096.openssl req -x509 -new -nodes -keyrootCA.key -days 365 -out rootCA.crt
CA cannot be downloaded from CloudHub and is stored on internal confluence. CSRs are sent in from source applications (for example Salesforce, SAP) and these are signed by the CA key to generate a certificate.
openssl x509 -req -in <csr_from_source>.csr -CA rootCA.crt-CAkey rootCA.key-CAcreateserial -out <source>.crt -days 365
This output .crt certificate is sent back to the source application.In the CloudHub load balancer, the public key of the CA pair (rootCA.crt) is loaded into the “Client Certificate” box on the Load Balancer certificate. Ensure the “Mandatory” radio box is checked.
What is MuleSoft Graph QL integration? ETL
To set up one-way to a target system by providing them with a specific certificate, the certificate provided by the target must be included as a P12 file in the resource directory of the application. It is linked into the HTTP connection using TLS context:
<http:request-config name="https_target"
host="${http.host}"port="${http. port}"
doc: name="HTTP Request Configuration" protocol="HTTPS"><tls:context> <tls:key-store type="pkcs12" path="certificatefile.p12"keyPassword="${keystore.key.password}"password="${keystore.password}"/></tls:context></http:request-config>
The underlying Java code cannot manage to select a certificate within a P12 file based on aliases, so it is best just to include a single certificate within the P12 file.
Logical Minds has not built an application that sets up mutual SSL to a target, but the theory is that a trust store (.jks file) is added to the resources/ directory and the certificates to be accepted are added into it, then it is configured using a trust-store element added to the TLS context.
<http:listener-config name="https-lc-0.0.0.0-8082" host="${https.host}" port="${https.port}" protocol="HTTPS" doc:name="HTTP Listener Configuration"><tls:context name="tls-context-config"><tls:trust-store path="truststores/trust.ts" password="password"/><tls:key-storepath="${https.keystore.path}"alias="${https.keystore.alias}"keyPassword="${https.keystore.keypassword}"type="${https.keystore.type}"/></tls:context></http:listener-config>
for more reference – mulesoft.
