Encryption, SSL/TLS, and Managing Your Certificates in Postman

Just like when it comes to making API requests and working with responses, Postman aims to give you greater control when it comes to configuring API encryption—which is now a standard part of API operations in 2020. Encryption is pushing API providers to leverage Transport Layer Security (TLS) to secure the data, content, and other resources that are being passed back and forth during each API request and response. And since TLS is dependent on Secure Sockets Layer (SSL) certificates to encrypt traffic, developers need solutions for yet another layer of potential friction.

In order to help with this, Postman provides visibility and control over TLS and the certificates that enable it: You can add, edit, and remove certificates, and troubleshoot some of the most common SSL problems encountered when putting APIs to work.

Managing certificates in Postman

Certificates are issued per domain, and you will need to have one of the following:

  • CA Certificate: A certificate issued by a trusted certificate authority
  • Self-Signed Certificate: A certificate not signed by a certificate authority

As the name suggests, CA certificates enable encryption with more security properties than self-signed certificates. You can manage CA certificates in Postman by simply going to the master Settings pane in the desktop or web version of the platform and clicking on the Certificates tab. If you have access to the CA certificate for a domain, you can upload the .pem file into Postman, allowing you to have more control over the encryption chain for the API calls you are making within each domain.

encryption certificate management
Adding a CA certificate .pem file in Postman

In addition to CA certificates, Postman lets you define and upload self-signed client certificates using the same Certificate tab used for CA certificates. You can configure the domain, certificate files, and passphrase so that you have full control over SSL/TLS security of the APIs you are using.

encryption certificate management
Adding a self-signed client certificate in Postman

Note: You can’t edit a certificate after it’s been added. In order to renew or change a certificate, you’ll need to remove and re-add the certificate. Once you have your certificate installed, you can begin making encrypted calls to an API within that domain.

For further visibility, Postman’s Network information icon provides helpful details about what is working or not working when it comes to the TLS dimension of making API calls:

encryption certificate management
Postman’s Network information icon gives greater visibility

If you need more help troubleshooting, be sure to read our documentation about managing certificates and visit the Postman community SSL page to see other user questions. If you don’t find the answer to your question, our support and developer relations teams are ready to help.

What do you think about this topic? Tell us in a comment below.

Comment

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.

14 thoughts on “Encryption, SSL/TLS, and Managing Your Certificates in Postman

    just curious. is there any reason why we can’t edit certificate after it was created? it would be a little annoying to test the same domain with different certificate.

    I’m working with mTLS across a team, is there a way to add certificates to a team workspace so all members can share the same certs?

    crt file -> client certificate
    key file -> client key for the certificate
    I cant see a place to add server certificate. Am i missing something here?

    Are these guaranteed to never leave the local machine (i.e. exempt from postman account sync, etc)? They seem to be (they were not synced for me) but I would still like to hear an official confirmation of this.

      Yes, Postman only stores the file path of the certificates and the path is not synced as well.

    It will be good, if we can set same certificate for multiple domains at same time.

    I am using Postman for the first time. The objective is to get mutual auth mTLS 1.2 working with a vendor API. I am able to get it work. However, I am only convinced the Client authentication is working. If my client certificates do not match what I have in place and sent to the service provide (vendor) it fails. When it is correct with the matching cert, key and passphrase, it works. It does not matter what I have defined in the CA Certificates file. It always works if the client credentials are correct. If CA Certificates is off it works. If it uses any file (not necessarily the one sent from the provider) it still works. I need to make sure that the server is being authenticated by the client. Any thoughts?

    You link to documentation in the article, but that documentation is out of date and doesn’t match what you have in your blog post. The documentation seems to be well out-of-date (and it’s what is found when Googling).

    Is there a reason we can’t see the ssl options (–cert, –key, …) in the generated Curl command when we add client certificate in the settings ?

    Is there a way we can pass passphrase in Newman CLI?

    Is there anyway to allow certificates to be used for Monitoring? It seems that my monitoring APIs are unable to make use of my certificates and as a result I am getting 403 Forbidden errors as a result (since the API endpoint I am monitoring requires MTLS). As the certificates are only stored locally (using the desktop version of Postman), and the Monitoring capability may run on the cloud based version, is there any way to allow the cloud based monitoring calls to use certificates?

    I run webinspect api scan using a postman collection file, the api endpoint I have is a https one and I’ll need to use the TLS certs to make api requests work, how to include the tls certs in postman collection file