Unable to pass client certificate from pact-js verifier (mTLS)

[hylmarj]

Software versions

• OS: _Windows 11 23H2 (22631.5472)
• *Pact foundation: v15.0.1
• Pact Foundation CLI: v16.0.7
• Node Version: ` v22.11.0

Issue Checklist

• I have upgraded to the latest
• I have the read the FAQs in the Readme
• I have triple checked, that there are no unhandled promises in my code and have read the section on intermittent test failures
• I have set my log level to debug and attached a log file showing the complete request/response cycle
• For bonus points and virtual high fives, I have created a reproduceable git repository (see below) to illustrate the problem

Expected behaviour

Provider verification started via pact-js Verifier should be able to establish mutual-TLS to the providerBaseUrl when an https.Agent { pfx, passphrase } is supplied (either through requestFilter or https.globalAgent), in the same way it already works when running pact-provider-verifier --tlsclientcertfile ….

Actual behaviour

The verifier spins up its local proxy (127.0.0.1) and the requestFilter receives only that internal request. When the proxy creates the outbound https.request towards the real providerBaseUrl, the configured https.Agent is not* reused, the client certificate is not sent and the TLS handshake fails with alert handshake failure / unknown ca.

• The same .p12 works in a plain Node smoke-test (https.get).
• For HTTP providers (no TLS) the verifier works fine.

Steps to reproduce

import fs from 'fs';
import https from 'https';
import { Verifier } from '@pact-foundation/pact';

const mtlsAgent = new https.Agent({
  pfx: fs.readFileSync('./certs/client.p12'),
  passphrase: 'anonymisedPwd',
  rejectUnauthorized: false,   
});

await new Verifier({
  provider: 'MyProvider2',
  providerBaseUrl: 'https://<API_HOST>:8443',
  validateSSL: false,

  // hook only sees proxy request
  requestFilter: (req, _res, next) => {
    req.agent = mtlsAgent;  // client cert
    req.servername = '<API_HOST>';  // SNI
    console.log('hook dump: ', {
      host: req.host, port: req.port, agent: !!req.agent
    });
    next();
  },

  pactBrokerUrl: process.env.PACT_BROKER_BASE_URL,
  pactBrokerToken: process.env.PACT_BROKER_TOKEN,
  publishVerificationResult: true,
  providerVersion: 'demo-1.0.0',
  consumerVersionSelectors: [{ branch: 'main', latest: true }],
  enablePending: true,
  logLevel: 'debug',
}).verifyProvider();

Relevant log files

pact:proxy non-local providerBaseUrl detected, changeOrigin=true
hook dump → { host: '127.0.0.1', port: undefined, agent: true }
write EPROTO 10560000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:c:\ws\deps\openssl\openssl\ssl\record\rec_layer_s3.c:1605:SSL alert number 40

We noticed providerTransports[].tls exists in Rust wrappers. Is there an ETA for exposing this in the JavaScript API?
https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_verifier_cli/src/main.rs

[mefellows]

Thanks for raising this request!

I'm keen to understand the scenario/use case a bit further. For instance, are you testing against a live server, or a local one?

If local (recommended) then in most cases you could drop the requirement of mTLS in this area. It's usually an incidental part of the contract and (IMO) doesn't add much value.

That being said, if we were to support it, we'd need to get it added upstream into https://github.com/pact-foundation/pact-reference/ (the core library). It would likely require a change to this FFI method.

[hylmarj]

Hi Matt,
thanks for the quick reply.

In our case the provider we verify is not running on the same machine as the test-runner. It’s an internal service that lives in a shared integration environment behind a load balancer. Corporate policy enforces mutual TLS on every inbound call to that environment, so the only way to reach the API (even from CI) is to present a client certificate in the TLS handshake.

Spinning up a local clone of the provider isn’t an option for us. The service depends on several downstream systems and security layers that can’t be mocked easily.
What we really need is to run the usual Pact provider tests against the real integration endpoint, in the same way we already do with other tools (e.g. ReadyAPI).

We’ve proved the certificate itself is fine. A plain Node script with new https.Agent({ pfx, passphrase }) can call the endpoint and get a 200/500 response.

The blocker is only inside the JS wrapper. The local proxy creates a second https.request that never gets our agent, so the server closes the handshake with an error.

If support for TLS/mTLS needs to go into pact-reference first we completely understand. We just wanted to document the use-case: provider in a secured non-local environment, test and CI must talk to it over mTLS, and sticking to pact-CLI would break our otherwise JS-only pipeline.

Thanks again for looking into it!

[mefellows]

You're right, it probably just needs to go into the proxy configuration client side (see https://github.com/pact-foundation/pact-js/blob/master/src/dsl/verifier/proxy/proxyRequest.ts). Apologies, it's 6pm here and my brain is fried ;)

If you're willing to submit a PR, I'd be happy to support introducing it into the Pact JS SDK. I think it should be something like this:

1. Update the proxy configuration to accept a new option(s) to support sending an certification for mLTS handoff
2. Ensuring there are tests covering the scenario
3. Updating any docs to ensure the options are documented