Al igual que muchos otros países, Rusia utiliza certificados x509 emitidos por Autoridades de Certificación Rusas (UC) autorizadas para la gestión oficial de documentos electrónicos. Y a diferencia de muchos otros países, utiliza sus propias cifras.
Durante mucho tiempo quise automatizar la verificación de firmas de las respuestas de las autoridades (me corresponde mucho) y la verificación de "descargas" de Roskomnadzor para autenticidad (por la naturaleza de la actividad pública). El mayor problema era obtener certificados intermedios de la cadena. Debido a que había un archivo Excel arrastrado de CA raíz en el sitio web del Ministerio de Comunicaciones y eso es todo. Y los intermedios tuvieron que buscarse en los sitios de las respectivas AC. La vida es un dolor.
¿Qué son los "certificados intermedios" ? Déjame recordarte cómo funciona. Supongamos que queremos verificar alguna carta firmada. La carta está firmada con una llave. Hay un certificado que certifica esta clave. El certificado fue emitido por alguien y también firmado por alguna clave con el certificado adjunto. Y ese certificado es exactamente el mismo. Y así sucesivamente hasta el momento en que se expida el certificado. Al verificar, hemos (traído, entregado del paquete, nos dieron una unidad flash) un cierto conjunto de estos certificados finales, que creemos. Creemos porque creemos en quien nos los dio. En el mundo de la web, confiamos en el navegador y su conjunto de certificados raíz. En el mundo de la web, cuando se conecta a través de HTTPS, los certificados intermedios también se transfieren del servidor al cliente. Por lo tanto, en el mundo de la web, siempre tenemos toda la cadena.
De repente (no sé exactamente cuándo) e imperceptiblemente en el sitio web del Servicio del Estado apareció un enlace:
e-trust.gosuslugi.ru/CAEscribí apresuradamente
un programa que convierte un archivo XML con una lista de CA y certificados de este sitio en el formato familiar PEM.
Luego lo automaticé y obtuve un
repositorio de certificados constantemente mantenido en la forma familiar para el mundo * NIX.
Cifrado GOST
El cifrado GOST es compatible con LibreSSL; no recuerdo qué versión. Pero en Alpine Linux desde 3.5 ya es compatible. Con OpenSSL, las cosas se vuelven más complicadas. El cifrado GOST viene con OpenSSL desde la versión 1.0.0 a la versión 1.0.2 inclusive. Pero, por ejemplo, CentOS no tiene cifrado GOST. Los usuarios de CentOS deben sufrir. Para Debian, Mint, Ubuntu con OpenSSL versión 1.1.0 y superior, se requiere la instalación del paquete libengine-gost-openssl1.1, respaldado por el entusiasta del cifrado Vartan Khachaturov (por cierto, puede ayudarlo).
Bueno, en 2018 tenemos Docker, y en Alpine Linux, como mencioné, todo funciona.
Como usarlo
Breves ejemplos para comprobar la "descarga" de Roskomnadzor con una firma ininterrumpida. El archivo "upload" es dump.xml, la firma sin etiquetar es dump.xml.sig. Incluso los verifiqué antes solo en la integridad de la firma, pero no en la correspondencia con la fuente.
Usando OpenSSL:
git clone https://github.com/schors/gost-russian-ca.git ./ openssl smime -verify -engine gost \ -CAfile gost-russian-ca.git/certs/ca-certificates.pem \ -in dump.xml.sig -inform DER -content dump.xml -out /dev/null
Usando LibreSSL:
git clone https://github.com/schors/gost-russian-ca.git ./ openssl smime -verify -CAfile gost-russian-ca.git/certs/ca-certificates.pem \ -in dump.xml.sig -inform DER -content dump.xml -out /dev/null
Y, por supuesto, puede usar la utilidad c_rehash en la carpeta certs y luego usar la opción -CAdir en lugar de -CAfile.
Y a partir de ahora, no puede usar el sitio web del Servicio Estatal, Contour y programas extraños como CryptoPro para la simple tarea de verificar una firma. Y lo más importante, ahora es posible automatizar.