Newman: SSL Errors

Created on 20 Nov 2015  路  8Comments  路  Source: postmanlabs/newman

Hello,

I am running npm 3.5.0 and node 5.1.0

Since I am using Node4.0+, I installed newman@beta

Within Postman, I successfully run a "collection" with a defined "environment" (this environment only needs a single "key" and a "value" corresponding to the current valid cookie). I export the "collection" and I export the "environment" from Postman, with the intention of using these files with newman

The "collection" together with its environment works successfully in Postman but does not work with newman@beta

I keep seeing the following Error: SSL Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE

I have tried, as suggested by many Google search results

npm config set strict-ssl false

but I still get the same UNABLE_TO_VERIFY_LEAF_SIGNATURE error.

Is there perhaps something else I can do?

Most helpful comment

Can you try adding the --insecure option to Newman while running the command?

All 8 comments

Can you try adding the --insecure option to Newman while running the command?

Thank you very much. That worked.

That indeed did work - just now. @abhijitkane +1

I just ran into the same problem. --insecure worked.

But why is this required?

I tried to access a server with a valid certificate listed under https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt which is used by node as default trusted ca (tls.createSecureContext(options)) http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt.

@andineck Just having a trusted CA is not enough. SSL will also check for things such as misconfigured domain names. SSL verification will also fail if the server does not support the encryption protocols supported by the client (in this case, Node.js).

@czardoz Thank you for your answer. Do you think a wildcard certificate could be the problem?

I use Newman with wildcard certificates all the time, so that should not be a problem. Any number of things could be wrong really. You might want to try hitting the endpoint from the command line (with curl or wget) which usually give more descriptive error messages.

Why is --insecure required, although it worked.
Can it be achieved with other than --insecure

Was this page helpful?
0 / 5 - 0 ratings