Logging Monitoring Failures in Chi with Mutual Tls

In Chi, enabling Mutual TLS (mTLS) adds strict client certificate validation, but if logging and monitoring are not aligned with mTLS expectations, critical security events can be missed or misinterpreted. When a client presents a certificate, the server performs verification; failures such as expired certificates, untrusted CAs, or hostname mismatches are typically handled by returning a 400-level error. If these events are not explicitly captured in structured logs, the absence of records can hide an ongoing attack or misconfiguration.

Without fine-grained logging of certificate metadata (subject, issuer, validity, Common Name, and SANs), you lose visibility into which identities are being rejected or accepted. Monitoring systems that only observe HTTP status codes might flag a spike in 400 errors as a generic client problem, rather than detecting a targeted attempt to probe certificate validation behavior. An attacker can iterate through invalid certificates to learn which attributes are accepted, and if those attempts are not logged with sufficient context, the pattern remains invisible.

Correlation across components becomes unreliable when mTLS handshakes occur at the edge or load balancer and application logs do not reflect the verified client identity. For example, a request may reach the Chi service only after mTLS succeeds at the proxy, but if the proxy does not forward certificate details via headers and the application does not log them, monitoring dashboards show a healthy stream of requests while missing identity context. This gap complicates incident response and compliance evidence, because you cannot trace actions back to a specific certificate subject.

Additionally, log levels that are too coarse may omit important handshake details. A configuration that logs only errors will omit successful mTLS handshakes, making it difficult to establish a baseline of normal certificate usage. Without baseline metrics, deviations such as sudden increases in certificate validation failures or unusual certificate issuers are harder to detect. Instrumentation must capture both success and failure paths, including certificate fingerprints and verification outcomes, to ensure monitoring reflects the true security posture of mTLS-enabled endpoints.

To secure logging and monitoring in Chi with mTLS, explicitly capture certificate metadata and verification results in structured logs and ensure monitoring tracks handshake outcomes. Below are concrete examples that demonstrate how to access certificate details and emit structured logs within Chi middleware and request handling.

First, configure mTLS in your Chi application by setting up TLS configuration with client certificate verification. Then, in your middleware, extract certificate information and log it alongside the request context.

// main.go
package main

import (
    "crypto/tls"
    "crypto/x509"
    "encoding/hex"
    "log/slog"
    "net/http"
    "time"

    "github.com/go-chi/chi/v5"
    "github.com/go-chi/chi/v5/middleware"
)

func fingerprint(cert *x509.Certificate) string {
    return hex.EncodeToString(cert.RawSubjectPublicKeyInfo)
}

func mTLSLogger(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        tlsState := r.TLS
        if tlsState != nil && len(tlsState.PeerCertificates) > 0 {
            cert := tlsState.PeerCertificates[0]
            attrs := slog.Group(
                "mtls",
                "subject", cert.Subject.String(),
                "issuer", cert.Issuer.String(),
                "fingerprint", fingerprint(cert),
                "not_before", cert.NotBefore.Format(time.RFC3339),
                "not_after", cert.NotAfter.Format(time.RFC3339),
                "verification_error", tlsState.VerificationError && "verified" || "unverified",
            )
            slog.Info("mTLS connection verified", attrs)
        } else {
            slog.Warn("missing client certificate")
        }
        next.ServeHTTP(w, r)
    })
}

func hello(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("secure hello"))
}

func main() {
    r := chi.NewRouter()
    r.Use(middleware.RequestID)
    r.Use(middleware.RealIP)
    r.Use(mTLSLogger)
    r.Get("/", hello)

    tlsConfig := &tls.Config{
        ClientAuth: tls.RequireAndVerifyClientCert,
        ClientCAs:  nil, // load your CA pool here
        MinVersion: tls.VersionTLS12,
    }
    server := &http.Server{
        Addr:      ":8443",
        Handler:   r,
        TLSConfig: tlsConfig,
    }
    slog.Info("starting server with mTLS", "addr", server.Addr)
    // server.ListenAndServeTLS("server.crt", "server.key")
}

This example logs certificate fields in a structured format that integrates with monitoring pipelines. Ensure your CA pool is configured in ClientCAs so that verification errors are meaningful and can be correlated with monitoring alerts.

Second, enhance monitoring by exposing metrics for verification outcomes. Use a metrics library to increment counters for success and failure categories, and ensure these metrics are scraped by your monitoring system.

// metrics.go
package main

import (
    "crypto/x509"
    "net/http"

    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promauto"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
    certVerification = promauto.NewCounterVec(
        prometheus.CounterOpts{
            Name: "mtls_certificate_verification_total",
            Help: "Total number of mTLS verification outcomes",
        },
        []string{"outcome"},
    )
)

func metricsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        tlsState := r.TLS
        if tlsState != nil {
            if tlsState.Verified { // Note: Go does not expose Verified directly; use custom logic
                certVerification.WithLabelValues("verified").Inc()
            } else {
                certVerification.WithLabelValues("failed").Inc()
            }
        } else {
            certVerification.WithLabelValues("no_cert").Inc()
        }
        next.ServeHTTP(w, r)
    })
}

func initMetrics() {
    // expose endpoint
    go func() {
        http.ListenAndServe(":9090", promhttp.Handler())
    }()
}

In practice, you implement verification tracking by recording the result of your own validation in the middleware, because tls.Verified is not exported. Combine this with structured logs that include the same outcome labels to ensure your monitoring dashboards can alert on abnormal verification failure rates or unexpected certificate issuers.