Root and intermediate certificates of authorized Certification Authorities of Russia
Like many other countries, Russia uses x509 certificates issued by authorized Russian Certification Authorities (CAs) for official electronic document management. And unlike many other countries, it uses its own ciphers.
I have long wanted to automate the verification of the signatures of the authorities' responses (I correspond a lot) and the verification of Roskomnadzor’s “unloadings” for authenticity (by the nature of social activity). The biggest problem was getting intermediate certificates from the chain. Because there was a vague Excel root CA file on the site of the Ministry of Communications and everything. And the intermediate ones had to be searched on the sites of the corresponding CAs. Life is pain.
e-trust.gosuslugi.ru/CA
I quickly wrote a program that turns the XML file with the list of CAs and certificates from this site into the usual PEM format.
Then I automated it and received a constantly maintained certificate repository in a form familiar to the * NIX world.
GOST encryption is supported in LibreSSL I don’t remember from which version. But in Alpine Linux from 3.5 is already supported. OpenSSL is more complicated. GOST encryption comes with OpenSSL from version 1.0.0 to version 1.0.2 inclusive. But for example in CentOS there is no GOST encryption. CentOS users must suffer. For Debian, Mint, Ubuntu with OpenSSL version 1.1.0 and higher, you need to install the libengine-gost-openssl1.1 package, supported by crypto-enthusiast Vartan Khachaturov (by the way, you can help him).
Well, in 2018 we have a Docker, and in Alpine Linux, as I mentioned, everything works.
Short examples for checking the unloading of Roskomnadzor with a detached signature. The “unloading” file is dump.xml, the detached signature is dump.xml.sig. Even I had previously checked them only for the integrity of the signature, but not for compliance with the source.
Using OpenSSL:
Using LibreSSL:
And, of course, you can use the c_rehash utility in the certs folder , and then use the -CAdir option instead of -CAfile.
And from this point on, you can not use the website of Gosuslug, Kontur and strange programs like CryptoPro for a simple signature verification task. And most importantly, it is now possible to automate.
I have long wanted to automate the verification of the signatures of the authorities' responses (I correspond a lot) and the verification of Roskomnadzor’s “unloadings” for authenticity (by the nature of social activity). The biggest problem was getting intermediate certificates from the chain. Because there was a vague Excel root CA file on the site of the Ministry of Communications and everything. And the intermediate ones had to be searched on the sites of the corresponding CAs. Life is pain.
What is "intermediate certificates" . Let me remind you how it works. Suppose we want to check some kind of signed letter. The letter is signed with a key. There is a certificate that certifies this key. The certificate was issued by someone and also signed by a key with the attached certificate. And that certificate is exactly the same. And so on until the moment when the certificate is issued to itself. When checking, we have (brought, delivered from the package, we were given on a flash drive) a certain set of these final certificates, which we believe. We believe because we believe the one who gave them to us. In the web world, we trust the browser and their set of root certificates. In the world of the Web, when connecting over HTTPS, intermediate certificates are also transmitted from the server to the client. Therefore, in the world of the web, we always have the whole chain.Suddenly (I don’t know exactly when) and imperceptibly, a link appeared on the State Services website:
e-trust.gosuslugi.ru/CA
I quickly wrote a program that turns the XML file with the list of CAs and certificates from this site into the usual PEM format.
Then I automated it and received a constantly maintained certificate repository in a form familiar to the * NIX world.
GOST encryption
GOST encryption is supported in LibreSSL I don’t remember from which version. But in Alpine Linux from 3.5 is already supported. OpenSSL is more complicated. GOST encryption comes with OpenSSL from version 1.0.0 to version 1.0.2 inclusive. But for example in CentOS there is no GOST encryption. CentOS users must suffer. For Debian, Mint, Ubuntu with OpenSSL version 1.1.0 and higher, you need to install the libengine-gost-openssl1.1 package, supported by crypto-enthusiast Vartan Khachaturov (by the way, you can help him).
Well, in 2018 we have a Docker, and in Alpine Linux, as I mentioned, everything works.
How to use it
Short examples for checking the unloading of Roskomnadzor with a detached signature. The “unloading” file is dump.xml, the detached signature is dump.xml.sig. Even I had previously checked them only for the integrity of the signature, but not for compliance with the source.
Using 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/nullUsing 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/nullAnd, of course, you can use the c_rehash utility in the certs folder , and then use the -CAdir option instead of -CAfile.
And from this point on, you can not use the website of Gosuslug, Kontur and strange programs like CryptoPro for a simple signature verification task. And most importantly, it is now possible to automate.