From Root CA to User Authorization in nginx and Apache: Client Certificate Login Explained
This is part three of a practical series on building a complete Root CA to user authorization system using nginx and Apache. The first two parts covered deployment of a two-level PKI with a Root CA and three intermediate CAs (Person, Server, Code), certificate revocation via CRL, and an OCSP responder.
The current part focuses on server-side configuration for client certificate authentication. It explains how to force nginx and Apache to request, validate, and forward X.509 client certificates to applications, and what changes when the application terminates TLS directly without a proxy.
Key differences between password and certificate login are highlighted: with certificates the private key never leaves the client, while the server verifies the signature and builds the chain to a trusted root. The tutorial stresses that the list of accepted CAs must contain only the Person intermediate CA to avoid offering unrelated certificates to users.
Practical steps include issuing a client certificate with extendedKeyUsage = clientAuth and keyUsage containing digitalSignature, packaging it as PKCS#12 for browser import, and enabling mTLS with full directive references. All nine reference tables covering 331 parameters from nginx ngx_http_ssl_module, Apache mod_ssl, and OpenSSL are included.
Special attention is given to secure header passing, login CSRF protection using separate hosts and one-time tokens, and revocation checking on the server side using both CRL and OCSP. The material was verified on nginx 1.29.8, Apache httpd 2.4, OpenSSL 3.3.7, and Go 1.24.
Related articles
PKI Storm: Managing 100,000 Simultaneous Certificate Requests in Kubernetes Recovery Scenarios
A large organization's PKI infrastructure faced a critical bottleneck when a data center outage triggered simultaneous startup of tens of thousands of Kubernetes pods, each requiring mTLS certificates. The existing setup using ESAUS and Citadel routed all requests through external certificate authorities that could only sustain 50-70 RPS against an incoming burst of 100,000 requests. Average daily load of 10-11 RPS had masked the thundering herd risk during mass recovery. Scaling the CA 15x was rejected due to cost and the fundamental dependency on real-time signing. The team introduced pre-issuance of certificates stored in a dedicated Unified Secret Storage (ЕХС) layer that supports 14,000 RPS reads while the CA continues normal operation. This architectural separation of issuance and consumption reduced recovery time from nearly 24 minutes to seconds while shifting focus to secure secret lifecycle management including KRA key protection.
MinTsifry Considers Annual 10 Billion Rubles Support Package for Russian AI Development
Russia's Ministry of Digital Development is discussing a state support package worth up to 10 billion rubles per year aimed at local AI developers. The proposed funding would cover technology development, pilot launches, and compensation for computing resources. According to Kommersant, 8 billion rubles are planned for development and implementation while 2 billion would offset computational costs. Mechanisms under consideration include subsidized loans through authorized banks and grants covering up to 80 percent of pilot project costs in priority sectors. The initiative remains in discussion with no final parameters or launch timelines confirmed yet. Industry experts note that clear selection criteria and transparent reporting will be essential to prevent intermediaries and ensure fair access for independent teams.
Indid Reports Russian Identity Security Market Reaches 17 Billion Rubles Amid High Incident Rates
According to Indid, the Russian Identity Security market reached 17 billion rubles by the end of 2025. The assessment highlights that organizations continue to allocate significant budgets to access protection while account-related problems persist. Survey data shows that 87.5 percent of companies experienced incidents involving user accounts and access rights during the period. Identity Security solutions focus on managing digital identities, controlling permissions, and preventing unauthorized access across corporate systems. The findings indicate ongoing challenges in maintaining secure access despite growing investments in specialized tools and platforms.
How a Node.js Bridge Connects MAX and VK Messengers to Chatwoot with Secure Bidirectional Sync
A detailed technical case study describes building a lightweight Node.js service that links the MAX messenger and VK communities to Chatwoot without scraping or using personal accounts. The bridge uses official bot APIs and community callbacks, separate API inboxes, and persistent state stored in a Docker volume to maintain conversation mappings across restarts. Security measures include webhook secret validation, deduplication of events using ring buffers, SSRF protections when handling images, and strict filtering to prevent loops or private notes from leaking externally. The implementation covers contact and conversation creation via Chatwoot Application API, image transfer for VK, and graceful recovery after partial failures. Limitations such as lack of exactly-once delivery and absence of a durable queue are acknowledged, with recommendations for production use including SQLite, retries, and structured logging. The author provides configuration examples, health checks, and a capability matrix showing current support for text and media in each direction.