Russian Ministry Certificates Enable Potential State MITM on Foreign Domains

Russian organizations under sanctions have begun switching to certificates issued under the Ministry of Digital Development and Communications root after commercial authorities revoked or declined to renew their existing certificates. Users who visit affected sites now encounter browser warnings that the authenticity of the resource cannot be verified.

The article explains that the only practical workarounds are to install the Ministry root certificates system-wide, switch to Yandex Browser which already bundles them, or maintain two separate browsers. Each option carries significant risks: loss of access to services, full system trust in a state-controlled CA, or reduced usability.

Threat Model

The author constructs a detailed threat model focused on a third party operating inside Russian jurisdiction. This actor can legally compel any Russian company to hand over data and can also deploy TLS interception appliances between users and foreign services. Once the Ministry root is trusted, the same infrastructure can silently terminate and re-sign connections to non-Russian domains, capturing session tokens and credentials.

Because the Ministry root currently carries no name constraints, it can issue certificates for any domain. The article therefore recommends re-signing the root with nameConstraints that permit only the national TLDs .ru, .su, and .рф.

Technical Implementation with OpenSSL

All steps are performed using OpenSSL on macOS and Linux. Users first download the Ministry certificate bundle from gosuslugi.ru, extract the non-GOST files, and create a new local root with appropriate basicConstraints, keyUsage, and nameConstraints extensions.

• Generate a fresh 4096-bit local root limited to national domains.
• Create a temporary CSR and extract the public key from the original Ministry root.
• Cross-sign the Ministry root using the local root and a cross_ca_ext configuration that preserves CA capabilities while inheriting the name constraints.

The resulting new_root_ca.crt can then be installed in the system trust store. Verification commands confirm that sites under .ru domains continue to validate while foreign domains such as sberbank.com are rejected when only the constrained root is present.

The author stresses that users must perform these steps themselves; any party holding the private key of a trusted root can still perform interception within the certificate’s permitted scope.