mTLS or Mutual Transport Layer Security (also known as Mutual TLS), is a new solution from LivePerson. The purpose of this solution is to centralize certificate management and to store certificates in a secured location over HashiCorp’s Vault. This solution is self-served.

What is mTLS?

Transport Layer Security is a protocol for verifying the identity of a service over the Internet. While TLS meant that only one side needs to authenticate the connection, with mTLS, the more widespread and common protocol in the industry today, both parties need to authenticate their identity. This protocol is safer, since both sides verify their identity, and fast becoming an industry standard, especially in the banking industry.

By adopting mTLS, LivePerson is looking to adhere to industry standards and offer more secure connections between brands and their consumers. By verifying both the identity of the LivePerson server and the identity of the brand, we can make sure that there's no man in the middle attacks, fraud, phishing or other security risks.

The optimal flow looks like this: the client authenticates the server (just like in TLS) then the server authenticates back to the client. Traffic will flow only after mutual (back and forth) authentication has been achieved.

What is HashiCorp Vault?

HashiCorp provides a suite of open-source tools intended to support development and deployment of large-scale service-oriented software installations. Vault, first released on April 2015, provides secrets management, identity-based access, and encrypting application data for auditing of secrets for applications, systems, users.

Use cases — Why should I use mTLS?

Our mTLS methods allow you to add an additional layer of security to all communications between yourself, LivePerson, and your customers. You should use these methods to create mTLS certified conversations which provide this added layer of security. mTLS serves outbound traffic only. Traffic flow is LP Service –> mTLS –> Client Url.

Happy flow example

The mTLS "happy flow" includes configuring the service and then invoking it in runtime:

Configuration

Follow mTLS Self Service

Run time

  • Run the Mapping method for the configured service name/url/siteId, this will indicate that all the data is saved successfully and can be used.
  • Forward the request using the preconfigured parameters (if all previous step passed then this step should not fail). This request will now be authenticated with mTLS.

Onboarding Guide

Check out our onboarding guide for complete mTLS flow.

Limitations

Technical limitations

  • The P12 key (private + public) must be Java compliant. The created key must use supported algorithms and key strength. To test your P12 key, please use the P12 Key Tester resource included in this API.

  • Resources support the oAuth1 (app key + app secret) and Bearer authentication (OAuth2) methods.

    • The Check Mapping Configuration method supports OAuth1 and OAuth2.

    • Any methods which create certificates "by-file" support Bearer authentication (OAuth2) only.

    • The P12 Key Tester supports Bearer authentication (OAuth2) only.

    • The Forwarding methods support OAuth1 authorization (app key + app secret).

  • The mTLS service is throttling protected, allowing 150 requests per second (per incoming IP).

  • Uploaded certificates/mappings will be updated to runtime after 5 minutes. This is due to caching mechanisms embedded in the runtime resources. The Configuration (certificate CRUD) resource is not cached.

  • It is possible to use the same certificate for different services but for each mapping of accountId + serviceName + url it will be only one certificate and the certificate name is unique.