Support switching client certificates on the same domain

[pdeak]

Considering Postman's function as a development / testing tool, the ability to test different client certificates (i.e. to test different users or accounts) on the same domain seems like it would be a common use case?

Certainly in all our projects, we have been forced to continue using the Chrome App version of Postman, as it allows us to select a new certificate from the system's installed client certificates (on Windows) every time we restart Postman.

In the native app, the "Certificates" page in Settings is far too restrictive - you can only have a single certificate per domain, and switching to a different one requires the manual removal/addition of the record, which is very time consuming.

Our concern is that with the upcoming deprecation of the Chrome app, Postman will no longer be an option for us if there is no easier way to switch client certificates.

Could any of the options below be considered as for a new feature?

1. Allow setting the client certificate via the Javascript sandbox API. OR
2. Implement the ability to assign multiple certificates to the same domain in Settings->Certificates, with some way to switch between them. OR
3. Enable the use of the system certificate popup (as per the Chrome app) to be able to select a different certificate every time Postman is restarted

[thecuriousdev]

@pdeak thanks for reporting this, we'll look into this.

[ErikUI]

I have the same need as OP

[andrewpmartinez]

Developing a new API that has strict requirements for certificate authentication only. Auth w/ cert, create new users w/ one-time-tokens used to sign certs, which are then used to authenticate.

What a pain. Feels like I'm forcing Postman to work.

[sskmail14]

Having the same requirement. Is there any plan or milestone been set yet? Kindly acknowledge @thecuriousdev

[rvq]

I am all for this 2. Implement the ability to assign multiple certificates to the same domain in Settings->Certificates, with some way to switch between them.

How I manage multiple certificates for same endpoints as a workaround:

1. Have a dedicated folder for an endpoint with crt.crt and key.key with a genericpassword
2. To change the certificate I just copy/replace new certificates with the same filenames and same password to the folder and submit a request.

Littel bit of folder management and copy/pasting and it works like a charm. Annoying but better than having to remove and enter the certificate info again.

[pacific202]

It's been a long time, but I'm needing this now. I am working with two separate clients that want ADP API integration, and I have to swap the certificates globally every time I switch working with one client or another.

It would be great if the Client Certificate setup became part of the Environment setup.

[pdeak]

@pacific202 I would recommend switching to an alternative tool like we had to (SoapUI, Insomnia etc). Its been over 2 years ago that I raised this, Postman's usability and feature set has evolved and progressed significantly in that time, just not when it comes to the usage of client certificates.

Other tools (including the ones I mentioned above) provide easier ways to switch certificates.

[pacific202]

I have switched to Insomnia. So far so good. Their Workspace concept lets me control the certificates independently for each workspace.

[alexmyles-exp]

This is also key for our organisation. Our company subscribes to Postman Pro and we use it heavily for dev and demos, but several of our external services issue multiple certificates to us (eg for different functionality, or to represent different clients for testing). Having to delete and reconfigure the certs every time we want to change them is ridiculous. This is not a complex feature and it's already supported by competing products...

[joachimbuechse]

I vote for this as well. For us already a call to just disable the client certificate for a particular call would be a step forward.

[VW1GDFC]

What about moving the certificate settings to the collection? So client certificates could be organised in a similar way like variables.

[rhollander73]

> I have switched to Insomnia. So far so good. Their Workspace concept lets me control the certificates independently for each workspace.

I think I will do the same. Client certificate per workspace, it pops up as soon as you open one: https://support.insomnia.rest/article/51-client-certificates

[houdini68]

Hi,

I got the keys (certificate and private) from Ibanity and I have tried several methods to change the password of the private key and it was unsuccessful. The method of @rvq works if all the private keys share the same password.

I have applied the following method:

Where is the config of Postman?

rudy@rudy-ThinkPad-T590:~/snap/postman/133/.config$ ls -lrt
total 48
-rw-rw-r--  1 rudy rudy    5 nov 15  2019 user-dirs.locale
drwxr-xr-x  2 rudy rudy 4096 déc 21  2019 fontconfig
drwxr-xr-x  2 rudy rudy 4096 déc 21  2019 dconf
drwxr-xr-x  2 rudy rudy 4096 déc 21  2019 gtk-3.0
drwxr-xr-x  2 rudy rudy 4096 déc 21  2019 gtk-2.0
-rw-r--r--  1 rudy rudy   36 fév 28 09:27 user-dirs.dirs.md5sum
-rw-r--r--  1 rudy rudy  673 fév 28 09:27 user-dirs.dirs
-rw-r--r--  1 rudy rudy   36 fév 28 09:27 user-dirs.locale.md5sum
drwx------ 16 rudy rudy 4096 avr 29 16:46 Postman.integ
drwxr-xr-x  2 rudy rudy 4096 avr 29 16:48 ibus
drwx------ 16 rudy rudy 4096 avr 29 16:49 Postman.prod
drwx------ 16 rudy rudy 4096 avr 29 16:49 Postman

Configure Postman to use for example the INTEG environment of Ibanity exit Postman rudy@rudy-ThinkPad-T590:~/snap/postman/133/.config$ cp -pr Postman Postman.integ start Postman Configure Postman to use for example the PROD environment of Ibanity exit Postman rudy@rudy-ThinkPad-T590:~/snap/postman/133/.config$ cp -pr Postman Postman.prod Now I have Postman.integ -> INTEG env and Postman.prod -> PROD env

To activate an environment: exit Postman

rudy@rudy-ThinkPad-T590:~/snap/postman/133/.config$ rm -r Postman
rudy@rudy-ThinkPad-T590:~/snap/postman/133/.config$ cp -pr Postman.prod Postman

start Postman

[pacific202]

Key words here:

if all the private keys share the same password

Not going to happen in any real world scenario.

[rvq]

Password can be changed with openssl for example

[fmessner]

We have the same requirement to test our APIs with different client certificates for different users. Is there any progress on this or are there any plans to work on a solution?

[michaelbrunner]

Yes this is still a pain for us, who develop different APIs, which must be access through a gateway.

[datta016]

Option #2 would be great.

Having multiple client certificates configured in the Postman settings with the same Host value but different cert files, with the restriction being that only one can be enabled at a time vs having to remove/add a new cert in each time from scratch.

[NathanBenz]

Perhaps instead of thinking about this at a "global" setting, can we not just have it as part of the hierarchical settings for each workspace? That way the certs for a workspace or for a folder or for an individual request are just set at that level like any other comparable setting.

[btull89]

Please improve the certificate experience!! It is very lacking..

[hemashrij]

Same requirement for us to test a request with different user certificates going through the same host?

[mieber]

Ok I switched away from SoapUI driven testing to Postman just to find out that it has basically no support for client auth testing. You cant switch the certs and if you want to test a fault state with a wrong client cert you get a "socket hang up".

Thinking now to test the client faulty auth cases with curl, and do the user role tests with certs and what @rvq described 5 years ago and manually shuffling files.

For tests from cli this means we will need to split the tests into different collections. Acutally quite a bummer.

[softinvent-cto]

+1 for this feature, especially @NathanBenz suggestion about letting the cert config follow the workspace.