Postman self-signed certificate

The documented message

Postman's v11 certificate documentation gives this wording:

SSL Error: Self signed certificate

Message not reproduced in Postman here. The wording is version-specific. A local HTTPS server did reproduce the corresponding certificate rejection in curl, followed by a successful request with explicit trust.

1. The API uses a private CA that Postman does not trust

Obtain the approved public CA certificate from the environment owner. In Postman Settings, open Certificates, enable CA certificates and select the CA PEM file. Send the request again with verification enabled. For the web app's certificate management, the documented workflow requires the Desktop Agent.

Do not import an arbitrary certificate received through an untrusted channel. Confirm it belongs to the intended test environment.

2. The server sends an incomplete or incorrect chain

Ask the server owner to check the presented leaf and intermediate certificates. Trusting a CA on your laptop does not repair an incomplete chain for everyone else. Check the hostname and validity dates too: those failures require the correct certificate, not just an extra CA entry.

For an isolated local reproduction and CA fix, use the fixture in SSL handshake errors. With that fixture running, this command was run successfully:

curl --cacert /tmp/batch2-tls/cert.pem https://localhost:4312/

It returned TLS lab OK. This demonstrates explicit trust for that local certificate; it does not demonstrate Postman's UI settings or a production certificate chain.

3. The API also requires a client certificate

If the Console indicates an mTLS identity requirement, add the client certificate and matching private key, or the provided PFX, against the documented host and port. Keep private keys out of collection exports and shared reports. A client identity is additional to server verification, not a replacement for it.

Prevention and interview answer

Keep private CA provisioning in the environment setup instructions and retest with verification enabled after certificate rotation. Temporarily disabling verification can isolate a trust problem on a controlled test endpoint, but a passing request in that mode does not validate TLS identity.

“I distinguish server trust from client authentication, add the intended CA or client identity, and rerun with verification enabled.” For connection failures without certificate evidence, start with Postman could not get any response.