Pact-js: Cannot run provider verification against HTTPS endpoint

[YOU54F]

Hi,

I am trying to migrate my pact provider verification step away from pact-node to pact-js and am getting errors when trying to connect to a HTTPS endpoint. It appears to originate from http-proxy module

Here is my pact-node implementation

const pact = require('@pact-foundation/pact-node')

const opts = {
  provider: 'XXXXX',
  providerBaseUrl: 'https://XXXX', 
  // providerStatesSetupUrl: 'http://localhost:3002/test/setup', 
  pactBrokerUrl: process.env.PACT_BROKER_URL,
  publishVerificationResult: false, 
  providerVersion: applicationVersion, 
  pactBrokerUsername: process.env.PACT_BROKER_BASIC_AUTH_USERNAME,
  pactBrokerPassword: process.env.PACT_BROKER_BASIC_AUTH_PASSWORD
}

pact.verifyPacts(opts).then(() => {
  console.log('success')
  process.exit(0)
}).catch((error) => {
  console.log('failed', error)
  process.exit(1)
})

For pact-js verification I have used

const { Verifier } = require('@pact-foundation/pact');

const opts = {
  provider: 'XXXXX',
  providerBaseUrl: 'https://XXXX', 
  // providerStatesSetupUrl: 'http://localhost:3002/test/setup', 
  pactBrokerUrl: process.env.PACT_BROKER_URL,
  publishVerificationResult: false, 
  providerVersion: applicationVersion, 
  pactBrokerUsername: process.env.PACT_BROKER_BASIC_AUTH_USERNAME,
  pactBrokerPassword: process.env.PACT_BROKER_BASIC_AUTH_PASSWORD
}

return new Verifier(opts).verifyProvider().then(() => {
  console.log('success')
  process.exit(0)
}).catch((error) => {
  console.log('failed', error)
  process.exit(1)
})

But i get the following error

/<projectPath>/node_modules/http-proxy/lib/http-proxy/index.js:120
    throw err;
    ^

Error: Hostname/IP doesn't match certificate's altnames: "Host: localhost. is not in the cert's altnames: DNS:*.<URL>"
    at Object.checkServerIdentity (tls.js:223:17)
    at TLSSocket.<anonymous> (_tls_wrap.js:1122:29)
    at emitNone (events.js:106:13)
    at TLSSocket.emit (events.js:208:7)
    at TLSSocket._finishInit (_tls_wrap.js:643:8)
    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:473:38)

There is probably no CA on the providers HTTPS endpoint (it is currently a mock produced by WireMock).

The URL in the error message drops the prefix before the first . in the url, so if the example URL was https://test.domain.co.uk, the error would be `Error: Hostname/IP doesn't match certificate's altnames: "Host: localhost. is not in the cert's altnames: DNS:*.domain.co.uk"

I have tried running the script with the prefix NODE_TLS_REJECT_UNAUTHORISED=0 to no avail

I don't currently have an example, but will provide one later on this evening 👍

[YOU54F]

I've created a branch showing the issue with circleci's run's showing both both pact-node and pact-js provider verifications

https://github.com/YOU54F/pact-consumer-example-typescript/pull/42

Here is a circleci run

https://circleci.com/workflow-run/63512026-e121-4758-9cfe-b1ece53f40a0

This is the pact-node job that can perform provider verification, with a providerBaseUrl that is HTTPS

https://circleci.com/gh/YOU54F/pact-consumer-example-typescript/348

This is the pact-js job that fails to perform provider verification, with a providerBaseUrl that is HTTPS

https://circleci.com/gh/YOU54F/pact-consumer-example-typescript/347

[mefellows]

Thanks @YOU54F. I managed to repro and have just pushed out a tiny fix.

There is now a flag validateSSL you can pass to the verifier to disable SSL verification when communicating to the provider service. By default, it validates (existing behaviour) but switching to false will disable it.

Also, I noticed in your test that the provider endpoint has the /v2/ suffix on it, as does the tests. For me, this resulted in 404s. Once I fixed the URL (and disabled SSL verification) all was green.

[mohammedalnuaimi]

Thanks @YOU54F. I managed to repro and have just pushed out a tiny fix.

There is now a flag validateSSL you can pass to the verifier to disable SSL verification when communicating to the provider service. By default, it validates (existing behaviour) but switching to false will disable it.

Also, I noticed in your test that the provider endpoint has the /v2/ suffix on it, as does the tests. For me, this resulted in 404s. Once I fixed the URL (and disabled SSL verification) all was green.

@mefellows I got exactly the same issue when added validateSSL the started getting 404, my baseUrl doesn't contain the suffix /v1/ however my PACT obviously does
how did you guys fixed it? @mefellows @YOU54F

[mefellows]

@mohammedalnuaimi if I understand correctly, your test uses a suffix but the actual provider doesn't? (or vice versa). I would simply remove the suffix from your test (i.e. configure your test to have the path you need to match the providers' needs (why is it there if it doesn't match? Going through a proxy or something?)

If that doesn't work, you might have to use the requestFilter feature and dynamically modify the path in the verification process. There are other options, but we need more detail to help you. Jump into slack.pact.io to chat more

[YOU54F]

Mo also needed the changeOrigin flag set, he has text me as we used to work together at our previous employers and I mentioned I needed the combo of flags. Think he’s all sorted now

[TimothyJones]

Thanks for the update, @YOU54F! If a particular combination of flags is necessary, does this mean there's a place we need to improve in the documentation?

[mohammedalnuaimi]

Thanks for the update, @YOU54F! If a particular combination of flags is necessary, does this mean there's a place we need to improve in the documentation?

thanks @mefellows @YOU54F for your assistance and reply, yes @TimothyJones I think needs PACT documentation needs more improvement, what each version solves and provides, also the documentation around how PACT really works is a bit misleading

[mefellows]

Thanks for your feedback @mohammedalnuaimi. We would really appreciate if perhaps with your newfound knowledge if you could provide specific areas (i.e. in the README) that need to change or are missing. Better yet, a PR would be really brilliant. Would that be something you're interested in helping with?

[mohammedalnuaimi]

Thanks for your feedback @mohammedalnuaimi. We would really appreciate if perhaps with your newfound knowledge if you could provide specific areas (i.e. in the README) that need to change or are missing. Better yet, a PR would be really brilliant. Would that be something you're interested in helping with?

@mefellows thanks for that, I would like to participate, but I'm very busy these months, will try to find a time at some point :)

[mefellows]

No worries @mohammedalnuaimi - thanks

[TimothyJones]

No worries- if you can find the time, even a few words about what specifically you found needed improvement or was misleading would help us turn your complaint into an action item.