Written in collaboration with: Santosh Kumar

Prerequisites: Basic understanding of SSL and TLS

Introduction:

Hello everyone, for the last few weeks, we have been working on migrating the communication between our industry cloud applications and cloud foundry environment managed services (data archiving, usage metering, malware scanning etc.) on SAP BTP from client id-client secret authentication to certificate-based authentication. This is done to make our product more secure. We are one of the first product teams working on this migration and would like to share our findings to help others.

Used technologies:

SAP BTP Cloud Foundry environment, Destination Service, XSUAA, Java

Following are the blog posts which are a part of this blog series:

1. X.509 certificate-based authentication(mTLS) – Generating X.509 certificates of BTP managed services: This blog will explain the flow of how certificate-based service keys are generated for BTP-managed services, certificate generation from the service keys and using it to fetch the bearer token to authenticate the service
2. X.509 certificate-based authentication(mTLS) – Communicating with services using SAP destination service(Java): This blog will cover the scenario in which the BTP application needs to communicate to a service in a different tenant, such as SAP Cloud ALM service, which is part of a different global account.
3. X.509 certificate-based authentication(mTLS) – Communicating with services using VCAP environment variables(Java): This blog will cover the scenario in which the BTP application will communicate with services binding with the application, and the certificate and key can be fetched through the VCAP variables.

The above blog posts will help you implement/migrate certificate-based security on your SAP BTP Applications.

Before getting into it, we should understand why we should implement mTLS instead of the normal security method. Following are some of the reasons which will explain their importance:

• First and foremost, the client id and client secret, once generated, remain constant and can compromise the server if stolen.
• The x.509 certificate has limited validity, which can be customised, and certificate rotation also helps change the credentials at regular intervals.
• It is near impossible to brute force in certificate-based authentication
• Unknown requests to the server are rejected

Basics of X.509 and mTLS-based authentication

Introduction:

This is the first blog in this blog post series. This blog will focus on the theoretical aspect of certificate-based authentication and gives an eagle’s eye view of the key concepts. Feel free to contact us if there is still some help needed in understanding these concepts.

Content:

1. What is mTLS?
2. mTLS flow diagram
3. What is the X.509 certificate?
4. Working of X.509 certificate-based authentication service
5. Structure of a X.509 certificate
6. What is a Certificate Authority?

1) What is mTLS?

Mutual TLS, or mTLS for short, is a method for mutual authentication. mTLS ensures that the client and server at the end of a network connection are who they claim to be. It refers to transport layer security(TLS) that uses a two-way encrypted channel between the client and server.

mTLS is used to verify an organisation’s users, devices, and servers in accordance with Zero Trust Framework. Zero Trust ensures that no device or user is trusted by default making the connections more secure.

2) mTLS flow diagram:

mTLS flow diagram

3) What is an X.509 certificate?

X.509 is a digital certificate built on top of a widely trusted standard known as ITU or International Telecommunication Union X.509 standard, in which the format of PKI certificates is defined. X.509 digital certificate is a certificate-based authentication security framework that can be used for providing secure transaction processing and private information. These are primarily used to handle security and identity in computer networking and internet-based communications.

4) Working of X.509 certificate-based authentication service:

The heart of the X.509 authentication service is the public key certificate connected to each user. These user certificates are assumed to be produced by some trusted certification authority and positioned in the directory by the user or the CA. The directory server itself is not responsible for creating public keys or for the certification function; it merely provides an easily accessible location for users to obtain certificates. The X.509 certificate format uses an associated public and private key pair for encrypting and decrypting a message.

Once an X.509 certificate is provided to a user by the certified authority, that certificate is attached like an identity card. Unlike other unsecured passwords, the chances of someone stealing or losing it are less. With the help of this analogy, it is easier to imagine how this authentication works: the certificate is presented like an identity at the resource that requires authentication.

5) Structure of an X.509 Certificate:

Every X.509 certificate contains information like issuing authority, version, subject, signature algorithm etc. Some information in an X.509 certificate includes the following:

• Version: Which X.509 version applies to the certificate, indicating what data the certificate must include.
• Serial number: The CA creating the certificate must assign it a serial number that distinguishes the CA certificate from other certificates.
• Algorithm information: The signature algorithm the issuer uses to sign the certificate.
• Issuer distinguished name: The name of the entity issuing the certificate — usually, the CA.
• Validity period of the certificate: The start and end date and the time the certificate is valid and can be trusted.
• Subject distinguished name: The name to which the certificate is issued.
• Subject public key information: The public key associated with the identity.
• Extensions (optional): Extensions have their own unique IDs, expressed as a set of values called an object identifier. An extension can be rejected if it is not recognized or if the extension has information that can’t be processed.

6) What is a Certificate Authority?

A Certificate Authority is a trusted third party that can “sign” certificates adding their stamp of approval. This allows the verifier to know that they mutually trust somebody. A signature is done using the trusted third party’s private key to encrypt a known value, which is then added to the certificate. A verifier can then use the signer’s public certificate to decrypt that known value and verify that it matches the expectation. Only a person in possession of the third party’s private key could have encrypted the value such that it decrypts correctly, proving that (as long as the private key has not been compromised) the trusted third party (the Certificate Authority) trusts this certificate’s claims. If you trust the Certificate Authority, then you can trust this certificate.

7) Summary:

In this blog, we have covered the concepts related to mTLS. In the next blog, we will see how a certificate can be generated for a BTP service and how it can be used to authenticate it. We will also see the different formats of X.509 certificates and use them to fetch a JWT token using curl and postman.

Please let us know if you find this content helpful and share any inputs and feedback.

References:

https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/

https://www.geeksforgeeks.org/x-509-authentication-service/

https://www.techtarget.com/searchsecurity/definition/X509-certificate