Ruthenium: Custom Chromium Build for Android Adds Russian Trusted Root CA Support
Ruthenium is a custom build of Chromium for Android that adds support for the Russian Trusted Root CA certificate from the Ministry of Digital Development without modifying the system certificate store.
Many Russian banks and government services use TLS chains ending at this root. Standard Google Chrome on Android rejects these chains with NET::ERR_CERT_AUTHORITY_INVALID because the root is absent from Chromium’s built-in store. The author wanted to keep using Chrome’s interface and therefore created a separate APK that includes the root with strict DNS constraints limited to .ru and .рф zones.
Why Chrome rejects the chain
The browser receives the site certificate and intermediates, validates names, validity periods and signatures, then attempts to build a path to a trusted root. Because Russian Trusted Root CA is not present in Chromium, verification fails. Existing solutions either require switching to another browser or installing the root into Android’s system store, which affects all applications.
Technical implementation of the patch
The certificate is converted from PEM to DER and embedded as a byte array in chrome/browser/net/profile_network_context_service.cc. The patch creates a CertWithConstraints object that adds the root with permitted_dns_names set to {“.ru”, “.xn--p1ai”}. This constraint applies to all DNS names listed in the certificate’s Subject Alternative Name, preventing misuse outside the allowed TLDs. The build scripts verify the DER SHA-256 against a lock file before compilation.
Four C++ files are modified in total: the network context service for the constrained root, primary_account_manager.cc to disable browser-level sign-in by default, and two omnibox/searchbox files to replace unavailable XR icon methods on Android builds without VR support.
Build configuration and distribution
The release uses is_official_build=true with ThinLTO enabled but external PGO profiles disabled. VR and AR features are turned off via GN flags. Each APK is published with a release tag that incorporates the Chromium revision, certificate digest, and build arguments, enabling traceability. Checksums, ABI information, and apksigner verification results accompany every binary.
Ruthenium installs under the package name app.ruthenium.browser and keeps its data separate from Chrome. No auto-update mechanism is provided; users must install new versions manually. The browser behaves identically to upstream Chromium on non-Russian domains.
Related articles
Russian CA TCI Integrates ACME Protocol to Automate TLS Certificate Issuance
The Technical Center Internet (TCI), part of RTK-COD, has deployed a production ACME server compatible with standard clients such as acme.sh, Certbot and lego. The implementation aligns the ACME state machine with the existing isolated signing infrastructure, Domain Control Validation mechanisms and mandatory Certificate Transparency logging to Yandex and VK CT logs. Certificate lifetimes are shortening industry-wide, with Web PKI limits dropping to 47 days by 2029, making manual issuance unsustainable. The service supports HTTP-01 and DNS-01 challenges, ECDSA P-256 keys and certificate revocation, while preserving the requirement for Subject/CN in CSRs and mandatory revocation reasons. A separate staging environment uses an internal CT log simulator for safe testing. Future plans include full multi-SAN support, ARI (RFC 9773) and removal of the Subject/CN restriction.
Russia Pushes Corporate Multibanking Forward with Updated Open API Standards
The Bank of Russia and AFT have advanced Open Banking standards that enable corporate clients to aggregate account data across multiple banks within a single interface. The new specifications cover consent management, security profiles based on STO BR FAPI and OpenID Connect, and account information retrieval for both individuals and legal entities. While the 2025 pilot results demonstrated practical use cases such as personal financial assistants and corporate multibanking, the updated standards effective from October 2026 still lack a unified initiation-of-transfer component. Developers must therefore combine the new account-data APIs with separate bank-specific payment initiation mechanisms. The article explores how accounting systems or independent fintech services could become the primary workspace for financial directors managing payments, payroll, and liquidity across several banks. It also examines real-world challenges including idempotency handling, status reconciliation after network failures, and the separation of application permissions from signer authority. Examples from the UK Open Banking Limited sweeping VRP statistics illustrate how pre-authorized variable recurring payments can streamline operations while highlighting the additional policy work required for corporate supplier payments in Russia.
Hacker Attacks as Force Majeure: Russian and International Courts Diverge on Liability for Cyber Incidents
In November 2026, Russian hosting provider Beget suffered a major cyber attack that disrupted websites, virtual servers, email, DNS, and control panels for thousands of clients. Beget notified customers of circumstances resembling force majeure under Article 401 of the Russian Civil Code but stopped short of claiming automatic court recognition. Russian courts have reached inconsistent rulings on whether DDoS attacks and ransomware qualify as extraordinary and unavoidable events, examining factors such as attack scale, provider preparedness, and contractual obligations. International cases from France, Norway, the United States, and the Netherlands further illustrate that outcomes depend on evidence of prior security measures, backup integrity, and specific contractual language rather than the mere occurrence of an attack. Key precedents include disputes involving Timeweb, Expeditors, and Nordlo Haugesund where liability was limited or denied despite confirmed incidents. The analysis shows that even when force majeure is rejected, clients often struggle to recover full losses due to liability caps and proof requirements. Businesses are advised to maintain independent backups, review service agreements, and document incidents thoroughly to protect against financial exposure.
US Mandates Removal of Acronis from Federal Systems by January 2027 Over Russian Ties
US federal civilian agencies have been ordered to remove all Acronis products from their information systems by January 27, 2027, with new purchases also prohibited. The directive from the Department of Homeland Security, signed on July 31 and published in the Federal Register on October 30, covers Acronis AG along with Acronis Inc. and Acronis SCS. A nearly decade-long review examined whether Russian developers still access the code and whether supply chain risks have been sufficiently reduced, though no specific evidence of backdoors was reported by sources. After 2022, Acronis suspended operations in Russia and relocated specialists, while in 2025 Swedish firm EQT acquired a controlling stake with approval from the US CFIUS committee. Despite over 75 percent of shares now held by Western investors, these measures proved insufficient for continued access to federal systems. The ban does not extend to the private US market.