From 23c8ab359c2108654d57176e233d2c099b398f31 Mon Sep 17 00:00:00 2001
From: srdusr <99972264+srdusr@users.noreply.github.com>
Date: Tue, 16 Jun 2026 22:57:00 +0200
Subject: Client (mutual-TLS) certificates

Adds internal/clientcert: a cert/key pair matched to hosts by the same
substring-or-regex pattern model as scope.Rule, so mitmux can present
a client certificate on an upstream TLS handshake that requires one -
the previous behavior was a hard handshake failure with no way to
authenticate. Wired into both places mitmux dials an https:// upstream
over its own TLS client connection: proxy.go's handleConnect (live
proxied traffic) and repeat.go's dialForRepeat (Repeater/Intruder
resends), both through a new Server.clientCertFor(host) helper.

Stored in a new client_certs table, mirroring the existing scope_rules
persistence pattern. The TUI (`t` from history) is add-only like
scope, for the same reason: delete and re-add covers changing
anything, and it's a rarely-touched, low-cardinality list. The add
form takes cert/key file paths and reads them once at save time - PEM
content, not the path, is what's stored and later presented, so a
cert keeps working even if the original file moves afterward.

Verified live against a real mutual-TLS-requiring origin server:
without a matching cert the handshake correctly fails; with one
configured, the origin receives it and the request succeeds; toggling
it off reproduces the failure, confirming the enable/disable path
works end to end.
---
 internal/clientcert/clientcert.go | 62 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 internal/clientcert/clientcert.go

(limited to 'internal/clientcert/clientcert.go')

diff --git a/internal/clientcert/clientcert.go b/internal/clientcert/clientcert.go
new file mode 100644
index 0000000..4bba835
--- /dev/null
+++ b/internal/clientcert/clientcert.go
@@ -0,0 +1,62 @@
+// Package clientcert manages client (mutual-TLS) certificates: which
+// certificate mitmux presents to an upstream server that requires one,
+// selected by matching the request's hostname the same way scope rules
+// do (see internal/scope) - substring match by default, or a regex - so
+// the "which rule applies to this host" mental model stays identical
+// throughout the tool.
+package clientcert
+
+import (
+	"crypto/tls"
+	"fmt"
+	"regexp"
+	"strings"
+)
+
+// Cert is one client certificate, scoped to hosts matching Pattern.
+type Cert struct {
+	ID      int64
+	Enabled bool
+	Name    string
+	Pattern string
+	IsRegex bool
+	CertPEM []byte
+	KeyPEM  []byte
+}
+
+func (c Cert) matches(host string) bool {
+	if c.IsRegex {
+		re, err := regexp.Compile(c.Pattern)
+		if err != nil {
+			return false
+		}
+		return re.MatchString(host)
+	}
+	return strings.Contains(strings.ToLower(host), strings.ToLower(c.Pattern))
+}
+
+// FindFor returns the first enabled cert whose pattern matches host, or
+// nil if none applies - mitmux then just doesn't present a client
+// certificate for that connection, same as if mutual TLS weren't
+// configured at all. First-match-wins on ID order, same convention as
+// match-and-replace rules' Position ordering, minus the extra field:
+// client certs are keyed by host, not layered edits, so insertion order
+// is a reasonable enough tiebreaker without adding one.
+func FindFor(certs []Cert, host string) *Cert {
+	for i := range certs {
+		if certs[i].Enabled && certs[i].matches(host) {
+			return &certs[i]
+		}
+	}
+	return nil
+}
+
+// TLSCertificate parses c's PEM-encoded cert/key pair into the form
+// crypto/tls needs to present it during a handshake.
+func (c Cert) TLSCertificate() (tls.Certificate, error) {
+	cert, err := tls.X509KeyPair(c.CertPEM, c.KeyPEM)
+	if err != nil {
+		return tls.Certificate{}, fmt.Errorf("parse client certificate %q: %w", c.Name, err)
+	}
+	return cert, nil
+}
-- 
cgit v1.2.3