Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.
1. Configure the TLS Server Profile
As mTLS is handled at the handshake level you will mostly need to configure it for all APIs on the same hostname and enable it through the TLS Server profile mapped to a specific hostname. In API Connect Reserved Instance you can do this through the RI Config Manager.
2. Configure your API to require mTLS
3. Create certificates, subscription and test the API
openssl req -newkey rsa:2048 -new -nodes -keyout client-private-key.pem -out cert_request.pemopenssl x509 -req -days 365 -in cert_request.pem -signkey client-private-key.pem -out client-public-cert.pem
curl https://{mtls-hostname}/{organisation}/{catalog}/{base-url} --cert client-public-cert.pem --key client-private-key.pem -H "X-IBM-Client-ID: {client-id}
#IBMAPIConnect#mTLS#reserved#Cloud
Copy
Ehsan - Isn't this more of a subscription problem?
A client with the Leaf11 client certificate is subscribed to the product with application1 APIs
A second client with the Leaf21 client certificate is subscribed to a different product with application2 APIs
Each client application loads their certificate when being defined, as Ricky describes above to validate their identity but the subscription regulates access.
We have two applications:
Application1.API1
Application2.API2
And a certificate hierarchy as follows:Root├── Intermediate1│ ├── Leaf11│ └── Leaf12└── Intermediate2 ├── Leaf21 └── Leaf22
We want to configure the system such that:
Only a client with the Leaf11 certificate can access Application1.API1
Only a client with the Leaf21 certificate can access Application2.API2
QuestionWhich certificates need to be uploaded to the gateway's truststore and the applications, in order to enforce this behavior?Thank you,Ehsan