Feat: Support for Mutual TLS (mTLS) / Client Certificates

[rafaelszp]

Did you search for existing issues already?
Yes, I am following up on the discussion started in issue #702.

Is your feature request related to a problem? Please describe.
I am currently unable to perform requests to services that require Mutual TLS (mTLS) authentication. In many enterprise environments and third-party integrations, the server requires the client to provide a certificate to verify its identity. Without support for client-side certificates, Slumber cannot be used for testing secure APIs that mandate mutual validation.

Describe the solution you'd like

I would like Slumber to support mTLS configuration. A key improvement would be supporting both separate files and bundled formats:

• Initial support: Ability to specify a Client Certificate (.crt/.pem) and a Private Key (.key).

• Enhanced support (PFX): Ability to use a single PFX/PKCS12 file, which is a standard for bundling certificates and private keys in enterprise environments.

• Passphrase handling: A way to securely provide a passphrase for PFX files or encrypted private keys (preferably via environment variables or a prompt).

Describe alternatives you've considered

• Using curl with --cert, --key, or --cert-type P12.

• Using a local proxy to handle the handshake, which is inconvenient for a TUI-based workflow.

Additional context

The implementation could follow the logic used by Postman for certificate management: Postman mTLS Documentation.

As discussed in this comment, adding this would bridge a major gap for developers working with banking, government, or high-security third-party APIs.

[LucasPickering]

Thanks for the specified report. I did some more research into this and here's what I came up with for the configuration:

certificates:
  # Add CA certificate(s) for self-signed certs
  authorities:
    - ./ca.pem
  hosts:
    example.com:
      type: pem
      crt: ./my-cert.crt
      key: ./my-cert.key
    # Wildcard domains are supported as well. This would NOT match the root `example.com`
    "*.example.com":
      type: pem
      crt: ./subdomains.crt
      key: ./subdomains.key
    # Replace the existing ignore_certificate_hosts field with this. This isn't necessary
    # for this feature, but it'd be nice to keep them together.
    # Maybe this is confusing though because the other domains specify which cert for
    # the CLIENT to use, while this refers to the SERVER's certs?
    danger.com:
      type: danger_ignore

Note: this would go in the global configuration, not the collection file.

Reqwest does support client certs, but PFX/P12 are only supported when using the native TLS backend (e.g. OpenSSL). Slumber is set to use the rustls backend, which I like because it's statically linked into the binary and doesn't rely on a specific system configuration. It looks like rustls only supports PEM.

It seems to me like the only reasonable way to support P12 is to use native TLS. I'd rather not force everyone into that, so it'll have to be either a runtime option or you'll have to install with an additional flag, like cargo install slumber --features native-tls. Needs some more research though.

For passphrases, I don't see anything in reqwest or rustls about support. This rustls issue specifically says they don't support it because there isn't a strong reason to. We'd have to use the openssl crate to do this decryption, then hand the decrypted certificate to reqwest. Possible, but it requires extra work. Prompting the user for the passphrase is easy enough though, as the HTTP engine already has access to the prompter.

I think the 3 steps of support you laid out is pretty accurate. I'd like to work on this but it'll be at least a few weeks before I can get to it.

[rafaelszp]

Reqwest does support client certs, but PFX/P12 are only supported when using the native TLS backend (e.g. OpenSSL). Slumber is set to use the rustls backend, which I like because it's statically linked into the binary and doesn't rely on a specific system configuration. It looks like rustls only supports PEM.

@LucasPickering Maybe a good and reliable way to work with pfx/p12 is to run openssl in a subprocess/background task. Externally the use will input the pfx/p12 file, while in background a conversion would be run to convert into a format that Rust works with.

Example workflow:

1. User input the pfx in

certificates:
  # Add CA certificate(s) for self-signed certs
  authorities:
    - ./ca.pfx

2. Slumber detects the format checking the first line of the file, if there is the matching string, it would identify as pem and no conversion would be done.

-----BEGIN PRIVATE KEY-----
.....

3. When pfx/p12 is detected, in background the openssl process (command) would be run. eg.:

#extracting the pem file
openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.pem
#extracting the key file
openssl pkcs12 -in cert.pfx -nocerts -out key.pem

**The only drawback is that feature won't work on windows (maybe there is a chocolatey/winget package).