> **Source:** https://knowledge.leegality.com/document-execution/api/security/mtls
> **Site:** Leegality Knowledge Base — https://knowledge.leegality.com
> **About:** Leegality is a document execution platform covering eSigning, stamps, NeSL, workflows, and REST API integration.
> **Navigation:** Every article on this site has a plain-text version at `<article-url>.txt` (this format). To get an index of all articles with their `.txt` links, read: https://knowledge.leegality.com/llms.txt
> **AI Guide:** For instructions on how to navigate this knowledge base as an AI agent, read: https://knowledge.leegality.com/ai-readable.txt

---
# Mutual TLS (mTLS) on Leegality

Mutual TLS (mTLS) is a two-way authentication protocol. Unlike standard HTTPS, where only the server proves its identity, in mTLS, **both the server and the client present digital certificates** before any data exchange begins.

In Leegality's context, this means: when Leegality sends a webhook to a client's server, both sides authenticate each other using certificates — ensuring the client's server only accepts callbacks from Leegality's verified identity.

## Why mTLS for Webhooks

When Leegality completes a signing event, it sends an outbound HTTP POST call to the client's configured `webhookURL` or `errorWebhookURL`. By default, this call is made over standard HTTPS (TLS), which only authenticates the **server** (Leegality's side). However, clients who need to verify that incoming webhook calls genuinely originate from Leegality — and not from a third party — can enable **Mutual TLS (mTLS)**.

mTLS extends standard TLS by requiring **both parties** to present and validate a certificate. This means:

- Leegality proves its identity to the client's server (standard TLS).  
- Leegality also presents a **client certificate** when calling the client's webhook endpoint, which the client's server validates before accepting the request.

Clients operate under strict frameworks — RBI IT & Cybersecurity, SEBI Cloud Application Framework, and internal WAF policies. These frameworks require that all inbound API callbacks (webhooks) be authenticated. mTLS is Leegality's primary mechanism to satisfy these requirements.

## How mTLS Works

When Leegality sends an outbound webhook:

1. Leegality presents the mTLS certificate as its client identity in the TLS handshake  
2. The client's server validates Leegality's certificate  
3. The TLS handshake completes; the webhook payload is delivered

**Key facts:**

- Clients must trust the mTLS certificate in their keystore  
- Sandbox and Production are **separate configurations** — certificates must be installed and configured for each environment independently  
- The certificate is configured per **Webhook Profile ID** (a UUID), which is then mapped to an Org ID

## Implementation Methods

### Method 1: CSR Generated by Leegality

1. Leegality generates a CSR and shares it with the client  
2. Client gets it signed by any CA (private or recognised)  
3. Client shares signed certificate back with Leegality  
4. Leegality converts to P12 and configures in a Webhook Profile ID  
5. Webhook Profile ID shared with client

### Method 2: Certificate Procured by Leegality

1. Leegality procures a public signed certificate from a trusted CA  
2. Converts it to P12 format  
3. Configures it in a Webhook Profile ID  
4. Shares the public certificate and Webhook Profile ID with the client

## Prerequisites Checklist

**From the Customer:**

- [ ] Org ID(s) requiring mTLS — Sandbox and Production separately  
- [ ] Webhook receiver URL (HTTPS endpoint)    
- [ ] Custom header requirements (header names and values)  
- [ ] Commercial approval (mTLS is a paid feature )

**From the Leegality:**

- [ ] Webhook Profile ID created/identified for the Org ID  
- [ ] Certificate configured in the Webhook Profile  
- [ ] Custom headers added if required

## Certificate Renewal

Certificate has **1-year validity**. Upon renewal:

1. Leegality renews the certificate   
2. The renewed certificate must be **re-configured in every Webhook Profile ID** that uses it  
3. The new public certificate must be **re-shared with all active mTLS clients** so they can update their keystores  
4. Clients must install the new cert before the old one expires