mtls-actix
Actix Web middleware for mTLS authentication with IP whitelisting.
Overview
mtls-actix provides Actix Web middleware for integrating mTLS (mutual TLS) authentication and IP whitelisting into your Actix applications. It validates client certificates and IP addresses before requests reach your handlers.
Features
- IP Whitelist Validation: Rejects requests from unauthorized IP addresses before TLS handshake
- Certificate Header Extraction: Extracts client certificates from HTTP headers (X-Client-Cert)
- Seamless Integration: Drop-in middleware for Actix Web applications
- Async Validation: All validation happens asynchronously without blocking
Quick Start
Add to your Cargo.toml:
[]
= "0.1.0"
= "0.1.0"
Example Server
use ;
use MtlsMiddleware;
use ConnectionValidator;
use ServerConfig;
use Path;
async
async
Example Client
use ConnectionValidator;
use ClientConfig;
use Path;
async
Configuration
Server Configuration
The middleware requires a ConnectionValidator configured for server use:
use ServerConfig;
use IpNetwork;
let server_config = new
.with_client_ipv4_whitelist
.with_require_client_auth;
let validator = create_for_server?;
let middleware = new;
Client Configuration
For clients that need to validate outgoing connections:
use ClientConfig;
let client_config = new
.with_ca_cert_path
.with_verify_server;
let validator = create_for_client?;
How It Works
IP Validation
- The middleware extracts the client's IP address from the request
- If an IP whitelist is configured, it validates the IP against allowed networks
- Unauthorized IPs receive an immediate 403 Forbidden response
Certificate Validation
- The middleware looks for client certificates in the
X-Client-Certheader - Certificates are validated against the trusted CA chain
- Requests without valid certificates are rejected (when client auth is required)
Request Flow
Request → Extract IP → Validate IP → Extract Certificate → Validate Certificate → Handler
↓ ↓ ↓ ↓ ↓
↓ [Invalid] [Reject] [Missing] [Invalid]
↓ ↓ ↓
↓ [Optional] [Reject]
Advanced Usage
Custom Certificate Headers
By default, the middleware looks for certificates in the X-Client-Cert header. You can extract certificates from different headers by extending the middleware:
// Custom middleware that extracts from different headers
Combining with Other Middleware
The mTLS middleware can be combined with other Actix middleware:
new
.wrap
.wrap
.wrap
.route
Error Handling
The middleware returns appropriate HTTP status codes:
- 403 Forbidden: IP address not in whitelist
- 400 Bad Request: Invalid or missing client certificate (when required)
- 500 Internal Server Error: Configuration or validation errors
Security Considerations
IP Spoofing
- The middleware trusts the IP address provided by Actix's connection info
- When behind proxies, ensure
X-Forwarded-Forheaders are properly validated - Consider using a trusted proxy layer for accurate IP extraction
Certificate Security
- Always use strong private keys (RSA 2048-bit minimum, prefer ECDSA)
- Regularly rotate certificates and update whitelists
- Monitor for certificate expiration
Deployment
- Deploy the middleware in production behind a reverse proxy (nginx, Apache)
- Use hardware security modules (HSM) for private key storage in production
- Enable detailed logging for security audits
Testing
Test your mTLS-protected endpoints:
Limitations
Current Limitations
- Certificate validation from headers only (not from TLS handshake at HTTP layer)
- Header-based certificates require proxy termination of TLS
- No built-in certificate revocation checking (CRL/OCSP)
Future Improvements
- Direct TLS termination in Actix (when Actix supports mTLS natively)
- Certificate revocation support
- More flexible certificate extraction strategies
License
Dual-licensed under either:
- MIT License
- Apache License, Version 2.0
at your option.
Contributing
Contributions are welcome! Please see the main project repository for contribution guidelines.