Keywords: TLS certificate | mutual authentication | server configuration
Abstract: This article delves into the technical details of retrieving client certificates on the server side in mutual TLS (mTLS) authentication scenarios. By analyzing the essence of the TLS handshake protocol, it explains why client certificates are not included in HTTP request headers and provides comprehensive guidance on configuring parameters in web servers like Nginx to pass certificate information to backend applications. Complete configuration examples and code implementations are included to aid developers in understanding and implementing mTLS authentication mechanisms.
TLS Handshake and Client Certificate Transmission Mechanism
In mutual TLS (mTLS) authentication, client certificates are transmitted during the TLS handshake phase, not at the HTTP protocol layer. When a client initiates a request using a curl command such as curl -k -vvvv --request POST --header "Content-Type: application/json" --cert client.pem:password --key key.pem "https://test.com:8443/testing", the TLS handshake verifies the server certificate and sends the client certificate as part of this process. This certificate information is exchanged via TLS messages and does not appear directly in HTTP request headers.
Server-Side Configuration and Certificate Information Extraction
To obtain the client certificate on the server side, appropriate configuration in web servers like Nginx is required. By setting directives such as ssl_verify_client on and ssl_client_certificate, the server can request and validate the client certificate. Upon successful validation, the entire certificate content can be passed to the backend application as a custom HTTP header using proxy_set_header SSL_CLIENT_CERT $ssl_client_cert. For example:
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /path/to/chainedcert.pem;
ssl_certificate_key /path/to/key;
ssl_client_certificate /path/to/ca.pem;
ssl_verify_client on;
proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;
location / {
proxy_pass http://localhost:3000;
}
}This configuration ensures that only validated client certificate information is transmitted, allowing the backend application to parse the header for certificate details.
Alternative Approach with Custom Request Headers
Although not recommended, it is possible to manually send client certificate information via custom HTTP headers. For instance, using curl to add a header like --header "X-Client-Cert: $(cat client.pem)". However, this method poses security risks, such as certificate leakage or tampering, and violates the design principles of the TLS protocol. In practice, server-side configuration should be prioritized for secure transmission of certificate information.
Supplementary Examples and Considerations
Referencing a Golang code example, it demonstrates how to load client certificates in programming languages: cert, err := tls.LoadX509KeyPair(certFile, keyFile), and configure the TLS client. It is crucial to set ClientAuth to tls.RequireAndVerifyClientCert to enforce verification. During deployment, use trusted CA certificates and avoid InsecureSkipVerify: true in production environments to prevent man-in-the-middle attacks.
In summary, by correctly configuring web servers and adhering to TLS best practices, client certificates can be handled efficiently and securely on the server side, enhancing system security.