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
Honeytoken Traps for Detecting Compromised Backends in Encryption Key Services
The article details a honeytoken-based detection system designed to identify when a trusted backend has been compromised and is abusing its signing key to request encryption keys for arbitrary documents. A secret set of fake user and document identifiers is stored only inside the key service using keyed HMAC-SHA256 hashes, ensuring the backend itself cannot discover or bypass the canaries. Any signed request touching these identifiers triggers an alarm, audit logging, and optional emergency lock that wipes master keys from memory. The check is deliberately placed after signature validation but before envelope decryption to avoid false positives from unauthenticated attackers while keeping performance cost low. Two types of canaries address different attack patterns: document canaries catch bulk scraping while user canaries detect forged grants for non-existent principals. The mechanism has been deployed in production, with live tests confirming silent failure responses externally and clear canary_trip plus emergency_lock events internally. Limitations include inability to catch targeted extraction of a single real user’s documents and the fact that detection occurs after a canary key has already been issued.
Yisaqi Automation Magician Delivers Self-Healing RPA to Fix Low ROI in Enterprise AI Agents
Meituan's internal experiment revealed that widespread AI agent adoption drove daily token costs into the millions while introducing errors into business processes. MIT research confirmed that 95 percent of generative AI pilots fail to deliver measurable returns despite tens of billions in spending. Yisaqi's Automation Magician addresses these gaps by extending the agent lifecycle beyond conversation to include exploration, automated testing, self-healing, and export of stable scripts. The platform uses natural language input to generate resilient automation flows that adapt to UI changes without repeated model calls. Deployments at Jiage Food and a major central SOE financial shared service center demonstrate large-scale coverage of tax, finance, and manufacturing processes with minimal manual intervention. Zhongtian Technology reported 80 percent efficiency gains and annual savings exceeding one million yuan after rolling out the solution across 112 scenarios.
Aeroflot to Accept Digital Rubles for Ticket Purchases Starting September 2026
From September 1 2026 Aeroflot will begin accepting digital rubles as a payment method for airline tickets both on its website and in company sales offices. Customers choosing the new option online will see a QR code generated by the site that must be scanned in a participating bank application. The payment is then confirmed from the digital wallet hosted on the Bank of Russia platform and an electronic ticket plus receipt are issued automatically. The same QR-based flow will be used at physical ticket counters where the code appears on the terminal. Ordinary bank cards and other payment methods remain fully available and no physical digital cash is required. On the same date MTS will start accepting digital rubles through MTS Pay while Rostelecom and Megafon are also preparing their systems. Russian authorities have clarified that the digital ruble is the third official form of the national currency alongside cash and non-cash funds rather than a cryptocurrency.
Russia Permits 5G Deployment on Existing 4G Infrastructure and Frequencies
The Russian Ministry of Digital Development has prepared a draft decision for the State Radio Frequency Commission that introduces technological neutrality for mobile networks. Major operators including Beeline, Megafon, MTS and Tele2 will be allowed to launch 5G services on spectrum and base stations already allocated for LTE. The measure covers foreign equipment installed before September 2026 and aims to accelerate commercial 5G rollout without waiting for entirely new infrastructure. Additional spectrum in the 4.63-4.99 GHz band will be allocated for high-capacity use cases, although these frequencies offer limited coverage. Commercial 5G services must appear in cities with over one million residents by the end of 2027, with gradual expansion through 2031. Domestic base stations are scheduled to replace foreign equipment between 2027 and 2031.