Skip to main content

​
What is mTLS?

Mutual TLS (mTLS) adds an optional second layer of authentication to your Method integration. In addition to your API key, your application presents a client certificate on every request, and Method verifies that certificate before processing the call. mTLS is optional and opt-in. It is available for teams that require it and must be provisioned per team and per environment before it takes effect. Teams that are not provisioned for mTLS continue to authenticate with their API key alone and are unaffected. If you are interested in mTLS, contact your Method representative to have your team provisioned.

​
What changes with mTLS

You continue to call the standard Method hostnames. The hostnames are the same whether or not your team uses mTLS.
Once your team is provisioned for mTLS, both of the following are required on every request:
  1. A valid client certificate
  2. Your normal Method credential (an API key or OAuth access token)
After provisioning, requests without a valid client certificate are rejected, and your API key alone is no longer sufficient. Until your team is provisioned, mTLS is not enforced and your existing requests continue to work unchanged.

​
Getting a client certificate

You generate a private key and a certificate signing request (CSR). You send Method the CSR, and Method returns a signed client certificate.
  1. Generate your private key and CSR (see below).
  2. Send Method the CSR.
  3. Method returns client.pem, and on first issuance the CA chain.pem if you need it for your trust store.
Exchange files with Method over email or another secure channel. Your Method representative will coordinate the exchange and confirm the approved Subject DN before you generate the CSR.

​
Generate a private key and CSR

Run the following, replacing the placeholders in -subj with your approved values:
This produces two files, client.key and client.csr. client.csr is your certificate signing request and should be sent to Method.
Never send anyone your private key (client.key).

​
Making authenticated requests

Present your client certificate and private key alongside your API key on every request:
If you received a CA chain from Method for your trust store, pass it as the trusted CA (--cacert chain.pem with cURL, or the equivalent in your HTTP client).

​
Error handling

When mTLS is enforced for your team, requests that fail certificate validation return a 401 or 403. See mTLS Errors for the full list and response bodies.

​
Certificate rotation

Renew your certificate before it expires:
  1. Generate a new private key and CSR.
  2. Send Method the new CSR.
  3. Method registers the new certificate.
  4. Deploy the new certificate. Both the old and new certificates remain valid during an agreed overlap window.
  5. Method removes authorization for the old certificate once you confirm the switch.
If your Subject DN does not change between renewals, no configuration change is needed on Method’s side.