Cryptographic Failures in Actix with Mutual Tls

Mutual Transport Layer Security (mTLS) in Actix is intended to provide strong channel authentication and encryption by requiring both client and server to present valid certificates. When implemented incorrectly, cryptographic failures can occur that undermine the confidentiality and integrity the protocol is meant to guarantee. These failures are not inherent to mTLS itself, but arise from configuration and certificate handling mistakes within the Actix service.

One common pattern is binding an Actix server to a TLS listener with a server certificate while enabling client verification but failing to enforce strict certificate validation. For example, an application might call RustlsConfig::with_config and set .client_auth(ClientAuth::Optional) or use a permissive trust anchor store that accepts any issuer. This effectively reduces the guarantee to one-sided TLS, allowing unauthenticated or spoofed clients to reach endpoints that assume strong identity. In an mTLS deployment, the server must treat the client certificate as a primary authentication artifact, not as optional metadata.

Another cryptographic failure arises from improper certificate chain validation. If the server does not verify the full chain to a trusted root, or if it accepts expired, revoked, or self-signed certificates without additional checks, an attacker can present a low-assurance certificate and be treated as a legitimate client. This is particularly risky when the Actix application maps certificate fields (such as subject or SAN) directly to authorization decisions without ensuring the certificate validity period and revocation status. For instance, using the actix-web integration with rustls can expose this if the server’s ClientCertVerifier is configured to skip revocation or name checks.

A third category of cryptographic failure involves key material and certificate storage. If server private keys or client CA certificates are stored in world-readable locations or embedded in source code, the cryptographic boundary collapses regardless of how well the protocol is configured. In containerized Actix deployments, mounting secrets as files with overly permissive permissions or passing them via environment variables can lead to unintended exposure. An attacker who gains file access can then decrypt traffic or sign malicious certificates, bypassing mTLS protections.

These issues map to the broader Cryptographic Failings category in security assessments, where weaknesses in key management, protocol configuration, and certificate validation lead to insecure communication paths. Because mTLS depends on precise coordination of certificates, trust stores, and validation policies, small misconfigurations in Actix can result in significant risk despite the presence of TLS.

middleBrick’s LLM/AI Security checks are not designed to detect cryptographic misconfig in mTLS, but its standard security scans can identify missing authentication controls and improper endpoint exposure that often coexist with these failures. For teams using the Pro plan, continuous monitoring can help detect changes in authentication behavior over time, while the CLI allows developers to test endpoints quickly from the terminal using middlebrick scan <url> to surface authentication-related findings.

Remediation focuses on strict certificate validation, secure storage, and explicit configuration that enforces mTLS as intended. Below are concrete Actix code examples demonstrating a properly configured mTLS server and client setup using rustls.

First, the server must require and validate client certificates. Use a trust anchor that contains only the expected CA, and enforce full chain validation including revocation where feasible.

use actix_web::{web, App, HttpServer}; 
use actix_web::dev::Server; 
use actix_web::middleware::Logger; 
use actix_web::web::Data; 
use rustls::{Certificate, PrivateKey, ServerConfig}; 
use rustls_pemfile::{certs, pkcs8_private_keys}; 
use std::fs::File; 
use std::io::{BufReader, BufWriter}; 
use std::net::TcpListener; 
use std::sync::Arc;

fn load_rustls_config() -> Arc<ServerConfig> { 
    let cert_file = &mut BufReader::new(File::open("server.crt").expect("cannot open server cert")); 
    let key_file = &mut BufReader::new(File::open("server.key").expect("cannot open server key")); 
    let cert_chain: Vec<Certificate> = certs(cert_file).unwrap().into_iter().map(Certificate).collect(); 
    let mut keys: Vec<PrivateKey> = pkcs8_private_keys(key_file).unwrap().into_iter().map(PrivateKey).collect();

    let mut server_config = ServerConfig::builder() 
        .with_safe_defaults() 
        .with_no_client_auth() 
        .with_single_cert(cert_chain, keys.remove(0)) 
        .expect("invalid server cert or key");

    // Enforce mTLS: require and validate client certificates
    let client_ca = rustls::RootCertStore::from_iter(vec![Certificate(
        std::fs::read("ca.crt").expect("cannot read CA cert"),
    )]);
    server_config.client_auth = Some(Arc::new(rustls::server::AllowAnyAuthenticatedClient::new(client_ca)));
    server_config.max_early_data_size = 0; 
    Arc::new(server_config)
}

async fn index() -> &'static str { 
    "Hello over mTLS" 
}

#[actix_web::main] 
async fn main() -> std::io::Result<()> { 
    std::env::set_var("RUST_LOG", "actix_web=info"); 
    env_logger::init();

    let config = load_rustls_config(); 
    let listener = TcpListener::bind("127.0.0.1:8443").expect("bind failed"); 
    let server = HttpServer::new(move || { 
        App::new() 
            .wrap(Logger::default()) 
            .route("/", web::get().to(index)) 
    })
    .listen_rustls(listener, config)?; 

    server.run().await 
}

Second, the client must present its own certificate and validate the server chain. This ensures the communication is truly mutual and that the client is not inadvertently trusting any server.

use reqwest::Client; 
use rustls::{Certificate, PrivateKey, ClientConfig}; 
use rustls_pemfile::{certs, pkcs8_private_keys};

fn build_mtls_client() -> Client { 
    let cert_file = &mut std::io::BufReader::new(std::fs::File::open("client.crt").expect("cannot open client cert")); 
    let key_file = &mut std::io::BufReader::new(std::fs::File::open("client.key").expect("cannot open client key"));

    let cert_chain: Vec<Certificate> = certs(cert_file).unwrap().into_iter().map(Certificate).collect(); 
    let mut keys: Vec<PrivateKey> = pkcs8_private_keys(key_file).unwrap().into_iter().map(PrivateKey).collect();

    let mut client_config = ClientConfig::builder() 
        .with_safe_defaults() 
        .with_root_certificates({ 
            let mut root_store = rustls::RootCertStore::empty(); 
            root_store.add(&Certificate(std::fs::read("ca.crt").expect("cannot read CA"))); 
            root_store 
        })
        .with_client_auth_cert(cert_chain, keys.remove(0)) 
        .expect("invalid client cert or key");

    client_config.alpn_protocols = vec![b"h2".to_vec(), b"http/1.1".to_vec()]; 
    let tls = rustls::ClientConnection::new(Arc::new(client_config), "localhost".try_into().unwrap()).unwrap(); 
    let connector = hyper_rustls::HttpsConnectorBuilder::new() 
        .with_tls_config(tls) 
        .https_or_http() 
        .enable_http1() 
        .build();

    Client::builder() 
        .build::<_, hyper::Body>(connector) 
}

Beyond code, rotate certificates regularly, store private keys in secure enclaves or HSMs when possible, and avoid permissive trust stores. Use the middleBrick Dashboard to track security scores over time and the GitHub Action to enforce a minimum risk score in CI/CD, ensuring mTLS configurations remain validated across changes.