Missing Tls in Chi with Mutual Tls

In a Chi-based service that opts into Mutual TLS (mTLS), failing to enforce TLS on all listener configurations can expose the application to unauthenticated and unencrypted traffic even when client certificates are expected. Chi itself is a lightweight router and does not manage transport configuration; the server setup in Go dictates whether TLS is required. If the HTTP server is configured without TLS or with a non-mutual TLS setup, endpoints that should require client certificates remain reachable over plain HTTP.

This misconfiguration creates a split surface: some routes may be protected by mTLS expectations in middleware, but the transport layer remains open. An attacker can bypass intended access controls by connecting over HTTP, avoiding the client certificate requirement entirely. Additionally, inconsistent enforcement—such as using different TLS configurations for different hosts or ports—can lead to accidental exposure of admin or health endpoints.

From a scanning perspective, middleBrick checks the unauthenticated attack surface and flags missing TLS as a high-severity finding because the API becomes susceptible to eavesdropping and tampering. Without transport-layer encryption and server authentication, confidentiality and integrity guarantees are lost. Findings include lack of HTTPS redirection, missing certificate verification on the server side, and routes that accept cleartext traffic. These map to OWASP API Top 10 A02:2023 (Broken Authentication) and A05:2023 (Security Misconfiguration), and can be surfaced in scans even when mTLS logic exists in application code but transport settings are incomplete.

Remediation centers on ensuring the Chi router is only attached to a server that enforces TLS and requests client certificates. Configure the Go HTTP server with TLSConfig that sets ClientAuth to tls.RequireAndVerifyClientCert and provides a populated ClientCAs pool. This guarantees that the transport rejects connections that do not present a valid client certificate, aligning the deployment with mTLS requirements.

Below is a concrete, working example for a Chi service with Mutual TLS enabled. It creates a certificate pool, loads CA certificates, and configures the server to require client certs before requests reach Chi routes.

// main.go
package main

import (
    "crypto/tls"
    "crypto/x509"
    "fmt"
    "io/ioutil"
    "net/http"

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

func main() {
    // Load CA certificate pool to verify client certificates
    caCert, err := ioutil.ReadFile("ca.crt")
    if err != nil {
        panic(fmt.Errorf("failed to read CA cert: %w", err))
    }
    caPool := x509.NewCertPool()
    if ok := caPool.AppendCertsFromPEM(caCert); !ok {
        panic("failed to append CA cert")
    }

    // Configure TLS with mutual authentication
    tlsConfig := &tls.Config{
        ClientCAs:  caPool,
        ClientAuth: tls.RequireAndVerifyClientCert,
        MinVersion: tls.VersionTLS12,
        CipherSuites: []uint16{
            tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
            tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
        },
    }

    // Build Chi router
    r := chi.NewRouter()
    r.Use(middleware.RequestID)
    r.Use(middleware.RealIP)
    r.Get("/api/secure", func(w http.ResponseWriter, r *http.Request) {
        // At this point, client cert has been verified by the transport
        w.Write([]byte("secure data"))
    })

    server := &http.Server{
        Addr:      ":8443",
        Handler:   r,
        TLSConfig: tlsConfig,
    }

    fmt.Println("mTLS server listening on :8443")
    if err := server.ListenAndServeTLS("server.crt", "server.key"); err != nil {
        panic(fmt.Errorf("server failed: %w", err))
    }
}

For automated validation, integrate middleBrick scans into your workflow. Use the CLI to verify endpoint exposure: middlebrick scan https://api.example.com. In CI/CD, the GitHub Action can enforce a minimum score before allowing deployment, and the Pro plan’s continuous monitoring can alert on configuration drift that weakens TLS enforcement. The MCP Server enables on-demand scans from your IDE while you adjust Chi or server settings, ensuring transport-layer mTLS remains consistent across environments.