API Connect

API Connect

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.


#API Connect
#Applicationintegration
#APIConnect
 View Only

How to use mTLS for API Consumers in API Connect Reserved Instance

By Ricky Moorhouse posted Tue March 05, 2024 01:13 PM

  

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.

  • Under TLS
    • Create a Keystore and Truststore
    • Configure a TLS Server Profile
      This should reference the key store and trust store created and set the mTLS option to either require or request. 
  • Under Gateways, select the Gateway service desired and then configure the Domains handled by Gateway via SNI for the hostname to use this profile
  • Configure your DNS to route the new hostname to the API Connect gateway by creating a CNAME pointing to the value shown for Base URL of the API invocation endpoint

2. Configure your API to require mTLS 

  • Ensure your API is configured to require at least a client id so that the calling application can be mapped to a subscription
  • On the gateway tab of the API Editor enable Application Authentication
  • Set the Application Authentication Source to be `tls-cert` so the certificate is used from the handshake. 
    Alternatively if you are using a load balancer doing TLS termination in front of the gateway you can configure the certificate to be passed in a header and set that as the source. 
  • Publish your API
    NB. you won't be able to test your API through the built in test tab as it does not have an option to provide a certificate.

3. Create certificates, subscription and test the API

  • Create a client certificate to use to call the API - in this example I'm going to use a self-signed certificate I created for testing using the following OpenSSL commands:

    openssl req -newkey rsa:2048 -new -nodes -keyout client-private-key.pem -out cert_request.pem
    openssl x509 -req -days 365 -in cert_request.pem -signkey client-private-key.pem  -out client-public-cert.pem
  • Then from the API Manager catalog page, create a Consumer Org.
  • Create an Application and upload the public certificate you created (client-public-cert.pem from the example above).
  • Create a subscription for the Application to your API from the overflow menu on the applications list
  • You should now be able to call the API using your subscription and client certificate - using curl this will look something like this:
    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

2 comments
21 views

Permalink

Comments

8 days ago

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.

15 days ago

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

Question
Which certificates need to be uploaded to the gateway's truststore and the applications, in order to enforce this behavior?

Thank you,
Ehsan