SAP Cloud Integration (aka CPI) allows to send messages from an iFlow to an Event Broker via AMQP.
The AMQP adapter can be configured with Basic Authentication or with Client Certificate.
This blog post shows how to configure client certificate authentication in iFlow for sending messages to Solace PubSub+ Event Broker.
This blog series covers
🔹SAP Cloud Integration in Cloud Foundry
🔹Solace PubSub+ Event Broker Cloud
🔹OpenSSL
🔹Java Keytool
Overview
Part 1: Introduction (this blog post)
1.1. Prerequisites
1.2. Intro
1.3. Next Steps
1.4. Further Reading
Part 2: Create Client Certificate Chain
Part 3: Configure Solace
Part 4: Configure CPI, create iFlow, run
Part 1: Introduction
1.1. Prerequisites
🔹To follow this tutorial, access to a Solace Event Broker is required.
This tutorial is based on a developer account at Solace PubSub+ Cloud
🔹Access To CPI Tenant
🔹To configure Solace and CPI, we need a private key and a certificate.
Can be a self-signed certificate or a certificate chain.
This tutorial covers the creation via OpenSSL and Java Keystore.
However, any other tool should be fine as well, as long as it produces an output that is supported by CPI and Solace.
BUT: if you really don’t want to create a certificate at all, you can use the existing certificate in CPI
1.2. Introduction
This tutorial brings the worlds of Solace and SAP CPI closer together.
What do we want to achieve?
Our goal is basic and minimalistic:
We’re happy if we manage to send a message from an iFlow to an Event Broker.
More concrete: From AMQP adapter to a queue in Solace Broker.
That’s all.
(See here for "Advanced Event Mesh" adapter)
That's all?
Yes.
So why do we need a tutorial?
Because we want to authenticate at Solace via Client Certificate.
And?
That can be tricky.
So we cover the scenario in detail from creating the certificate to configuring it in both worlds.
Can we have an introduction?
It is all about accessing protected resources.
We have to give the secret password and if it is correct, we get access.
Instead of a password (e.g. “abc123”), we can give a symmetric key (some code).
But: In case of client-server, it is more safe to use asymmetric keys.
Why?
Because it is not safe to send anything secret over the net.
In case of asymmetric keys, we can safely send a public key over the net to the server.
Why?
Because it is "public", it is not secret.
So how does it work?
We encrypt anything with our secret private key.
The server verifies the result with the public key.
Cool.
One more step:
To make sure that the public key belongs to myself (proves my identity), it is wrapped by a certificate.
What is a certificate?
A certificate contains the public key and some metadata like my name.
And importantly: the certificate is issued by a trustworthy “Certification Authority” (CA) which proves my identity.
The info about the “issuer” is added to the certificate.
AND: the issuer signs my certificate.
What is signing?
A signature is a security mechanism to prove integrity and authenticity, by applying a hash code and encrypting it with the issuer’s private key.
A signature can be verified with the public key which is publicly available.
Like that, everybody can verify that my certificate was issued and signed by the trustworthy CA.
How do I get a certificate?
To get my certificate, I have to send a “certificate signing request” (CSR) to the CA.
This process takes time and money – but it is a good security mechanism.
Afterwards, I can authenticate safely at a server, with my private key and a certificate.
How does the server know?
The server will check the signature on my certificate and make sure that it was signed by trustworthy CA.
In addition, the server has to make sure that I possess the private key that matches the public key that is contained in the certificate.
How does that work?
When the client does request to server, the private key is used by the user agent at client-side.
That user agent can be a browser or a rest-client.
The agent generates a little piece of text (nonce) and signs it with the private key.
That is sent along with the request.
The server verifies the received signature with the public key of the cert (which is already there).
If successful, it means that the sender is really the one who is identified by the certificate.
Cool.
One more thing:
A trustworthy certification authority cannot issue and sign millions of client certificates.
Therefore, the CA enables sub-CAs, which are trustworthy as well.
Such a Sub-CA (called "Intermediate CA") will issue my client certificate.
As a result, my own certificate is not issued by the CA, but by the intermediate CA.
Such a pity
Yes, because it means:
if I send my client certificate which is issued by the intermediate CA, the server doesn't accept it.
Because the intermediate CA is not contained in his list of trusted CAs.
So the server doesn't trust my certificate.
So how to solve the problem?
However, the intermediate CA is issued by the root CA and is signed by it.
This is verified by the server.
And therefore, the server accepts my client cert (also called “leaf”).
My client cert is signed my intermediate cert, and the intermediate is signed by the CA.
As such, my cert is trustworthy.
That mechanism is called a “certificate-chain”.
I'm confused
A diagram is always helpful:
Note that there can be multiple intermediate certificates, depending on the setup of a “Public Key Infrastructure” (PKI) of a company.
The next diagram shows the contents of certificates in a chain.
We can see some of the metadata contained in a certificate:
🔹The subject is what identifies myself.
🔹The issuer is the subject of the CA.
🔹A certificate contains also a signature, which allows to verify it with the public key.
🔹Most important, the certificate contains the public key which matches the private key of the sender.
Each certificate contains the info about itself and its issuer.
If the subject and issuer are equal, then it is a root certificate.
Additional information contained in a certificate are the serial number of each certificate.
And also the so-called “v3-extensions”, additional info and security mechanisms added in version 3 of X.509.
What to do with a chain?
When a server receives a request with Certificate-Based Authentication (CBA), then it would proceed as follows (simplified):
➖ check client certificate: who is the issuer?
➖ check if the issuer ("demomiddle") can be found.
➖ check the middle certificate: is it a CA ? (check v3-extension).
➖ use the public key of middle to verify the signature of client.
➖ check the middle certificate: who is the issuer
➖ check if the issuer ("demoroot") can be found.
➖ check the root certificate: is it a CA? Is it a Root?
➖ finally: is the root contained in the list of trusted root CAs?
Done.
How does a chain look like?
Usually, it is a text file containing the 3 certificates (or more), each has header and footer.
The certificates are base64-encoded.
That’s called PEM format.
What is...?
It is a container for one or more certificates, also keys can be contained.
Usually, the order of the certificates is relevant, the client on top and the root on bottom.
(My mnemonic: RootRestsRear)
Again: how does it look like?
Below is a (shortened) example of a certificate chain in PEM format:
Cool.
So, a certificate chain is a mechanism to prove the trustworthiness of my client certificate.
As a consequence, this means, I cannot just send my client cert, as the server would reject.
I have to send the chain.
So the server can check my cert and the issuer cert . . . and finally the issuer of the issuer.
Yes, still cool.
After this introduction, we’re ready to understand this blog post.
😴
What have we learned?
For certificate-based authentication, the server needs a valid chain.
Usually, a server has a key store where (only) the root certificates are stored.
Usually, a client sends the chain, to enable the server to fully validate.
Some variants are possible, however:
Client doesn’t have to send the whole chain, if the server already has the root certificate.
Client doesn’t have to send the intermediate certificate, if it is contained on server store (not recommended).
Also, a chain can be longer or shorter.
For testing, a self-signed certificate can be used and the chain length would be 1 in that case.
What about the private key?
The private key must be available at client-side, for establishing the mutual trusted connection.
This is called mTLS (mutual TLS).
Therefore, the private key must be uploaded to CPI.
Is that safe?
Yes, it is.
ote that the private key is never sent to the receiver.
Coming to CPI…
Acting as a client, we need a key pair and a certificate chain.
We upload it to CPI in a container format ("p12" or "jks", see below).
In our tutorial, we create the keys and chain ourselves, self-signed.
In a productive scenario, we would send a CSR to a real CA and purchase the chain.
Note:
For testing, we could also use a certificate that is delivered by SAP CPI, see Appendix below.
The container contains the chain (including public key) and the private key.
The private key alias is specified in the AMQP adapter.
Coming to Solace…
We need to upload the root certificate to Solace.
Done?
Done.
Disclaimer:
This blog post is not an official reference guide.
Nor an official security setup recommendation.
I’m just trying to help you to get a scenario running, end to end.
1.3. Next Steps
To run the scenario, we need a client certificate that is accepted by Solace.
🔹Part 2: Create Certificate Chain, using OpenSSL and Java Keytool, different variants
🔹Part 3: Configure Solace
🔹Part 4: Configure CPI and Create iFlow, run the scenario
1.4. Further Reading
Solace
Solace home
Solace Event Broker Cloud Trial
The Solace dashboard entry
Docu for Solace PubSub+ Cloud
CPI
AMQP Adapter
Mandy's blog post about AMQP adapter
Security Glossary
OpenSSL
genpkey
req
X509
verify
pkcs12
How to secretly passing a password to commands
- SAP Managed Tags:
