I think noone.
Christian Hohnstädt, Programming, Translation and Testing XCA
Transfer:
I think that no one else has looked so deep into my code like you.
Christian Hohnstädt, developer of XCA

Certification authority (CA) is a rather complex organism that includes not only a hardware and software complex consisting of many components, but also requiring a whole staff of highly qualified specialists to ensure its efficiency, etc. You can ask, why do we need a certification center, what products does it produce and where does it apply?
What is common between x509 certificate and citizen passport?
What is common between the passport office and the Certification Authority?
The main function of the TC center is the production and maintenance of electronic signature verification key certificates (CLEP), including the creation of a key pair upon request of the certificate holder. At once I will make a reservation, in my deep conviction, the last service of the center's center is harmful and dangerous.
Anyone who has received a certificate and a key pair (private and public key, or, as they also call it, an electronic signature verification key), can at any time refuse his electronic signature (ES) under the document and declare that his key could have been stolen from the CA in the moment of its generation. Therefore, it is correct to generate the key pair yourself and store it as a pupil of an eye, and if it is generated in the CA, then only on a PKCS # 11 token / smartcard with a non-recoverable key.
Note that CAs issue certificates in accordance with X.509 v.3 (
RFC 5280 ).
In general, the TC functions largely coincide with the
functions of the passport office , which are under the authority of the Ministry of Internal Affairs of Russia.
The certificate, as well as a passport, is issued on the basis of an application and the provision of a number of documents. The list of documents for obtaining a certificate is at
any certification center that is accredited by the Ministry of Communications.

What is the main thing in a passport received by a citizen? This is a series and number, by whom and when issued, a photograph and a personal signature of the citizen in the passport, certified by the signature of the ATS officer and sealed.
And what is the main thing in the certificate? He also has a serial number, by whom it was issued, information about a citizen, including both SNILS and TIN, and an analogue of a photograph and a citizen’s handwritten signature is the public key or electronic signature verification key. And this is all certified by the CA electronic signature. And the resulting document (file) is called a certificate. You ask, where is the private key, with the help of which the electronic signature is actually put under the documents? And the private key, as we said above, should be kept by the citizen on an electronic medium (flash drive, token / smartcard), just like the ability to put a personal signature, the sample of which he left in his passport, he owns and he alone. Therefore, you can always absolutely confidently say the actual signature of a citizen under the document or not. Oddly enough a similar situation with an electronic signature. Having a private key, a citizen can unequivocally
get the public key and check it with a certificate for it with a certificate or not!

And what should a citizen do if he is stolen or lost a passport? It is urgently necessary to declare to the passport office, ATS. After that, the passport is invalid and it falls into the
list of invalid Russian passports . From this point on, any legal action referring to the lost passport is invalid. The situation is similar with certificate revocation. If the private key has been lost (and it is usually stored on the discarded media - flash drive, token, smart card, etc.) or there is a suspicion that it was copied, then you should immediately contact the CA to revoke the certificate (invalidated). In this case, he enters the CAC - a list of revoked certificates. I want to note that the certificate is not revoked when the certificate has disappeared, namely, the private key. The certificate itself is a public thing and you can always duplicate it at the CA.
')
Why do you need x509 certificate?

And so why do we need a certificate for a citizen of the Russian Federation and legal entities? The most recognizable is access to the
Gosuslug portal . No less significant is access to the FTS portal. Next - electronic trading and more. As a rule, this list is on each CA registered with the Ministry of Communications and Mass Media.
With legal entities and citizens of the Russian Federation everything is clear. Why should an electronic signature verification certificate be necessary for an employee of a certain company? It turns out for a lot. A personal certificate (certificate and key pair) stored on a token or a smart card with an PKCS # 11 interface can serve as a pass to the enterprise’s territory and provide access to a computer, allows you to
sign and encrypt documents , access your personal account on the enterprise’s portal, use corporate VPN services, have access to the enterprise portal via an authorized HTTPS. And for this, it is not at all necessary to obtain a certificate for the internal corporate purposes outside the enterprise at the TC accredited by the Ministry of Communications and pay the money for it. On the other hand, the deployment of a full-scale CA in small and medium-sized enterprises is not only beyond its power, but also similar to the firing of a cannon at sparrows. Small and medium businesses do not need most of the functionality of such complexes: they do not need scalability, hot backup, separation of powers, etc.
Prerequisites for the emergence of XCA (X Window System Certification authority)
For issuing x509v.3 certificates for publication, one could use the widely used command-line utility
OpenSSL , in particular, it allows one to perform the following functions:
- key generation (for example, openssl genrsa ...);
- formation of a request in the PKCS # 10 format for obtaining an x509 v.3 certificate;
- edition of the certificate x509 v.3;
- formation of the list of revoked certificates (CAC / CRL);
- etc.
If you look closely, it turns out that all these functions are the CA, moreover, one of the commands of the OpenSSL utility, namely, the CA command is a CA with the minimally necessary functionality:
$openssl ca -md <hash> -in <req_file> -out <cert_file>
Where:
- ca - command for working with CA
- md - an option indicating which hash function (for example, sha1, sha512, gosthash) to use to issue an electronic signature verification key certificate
- in - option indicating that the request for the certificate of the ES verification key should be taken from the file <req_file>
- out - option indicating that the generated certificate of the ES verification key certificate should be written to the file <cert_file>
The disadvantages of using the OpenSSL command utility are obvious:
- a large number of teams and an even greater number of command parameters, in particular, at least 5 commands are required for issuing a certificate;
- rather complicated configuration file openssl.cnf;
- but the most important thing is the lack of a unified certificate storage (database), which makes it very difficult to manage certificates
It is the last point that distinguishes, for the better, the project similar to the essence of the
OpenSSL project (Network Security System), which is widely used to work with certificates in Mozilla projects, Google Chrome browsers (LINK -), etc. And if we also talk about usability, I would like to have a single graphical interface based on the X Windows System for issuing and managing certificates (Certification authority).
The X Window System is a window system that provides standard tools and protocols for building a graphical user interface.
XCA functionality

And based on these prerequisites, an open source project (
Copyright )
XCA was born, using the OpenSSL library for cryptographic transformations, the Qt library for the graphical interface, and the C ++ language as the programming language. Qt Designer (designer utility) was used to design a graphical interface, which makes it very easy to customize the graphical interface to meet the specific requirements of Russian legislation and regulatory acts, for example, the form of a graphical interface for a new certificate (file ~ / src / ui / NewX509.ui) :

To store CA objects in XCA, a database is created, access to which is protected by a password.
The XCA graphic interface as a certification center is implemented in the form of five functional tabs and two drop-down menus:

- database management functions for storing information about keys, certificates and other XCA objects;

- functions of creating and managing keys;

- certificate request management functions (PKCS # 10);

- certificate management functions x509 v3;

- template management functions for requests;

- management functions of certificate revocation lists (CAC / CRL);

- tokens / smartcard management functions PKCS # 11;
It is safe to say that the XCA graphical application is the Center for issuing and managing Certificates (hereinafter referred to as the XCA CA).
About support of Russian cryptoalgorithms in XCA
Now we will be interested in the support of Russian cryptoalgorithms in the CA XCA. And if this happened before 2012, everything would be fine: by that time, support for both GOST R 34.10-2001 and GOST R 34.11-94 and GOST 28147-89 already appeared in the OpenSSL project. But in 2012, the new cryptographic algorithms GOST R 34.10-2012 and GOST R 34.11-2012 were approved, and in 2015, new cipher algorithms for grasshopper and magma were approved, namely, GOST R 34.12-2015 and GOST R 34.13 -2015.
Unfortunately, at present, OpenSSL does not support new Russian algorithms. In this case, there are two ways to solve the problem. The first is related to the development of a
new engine , similar to the existing libgost, with the support of new Russian algorithms. The second way is to directly embed Russian algorithms in OpenSSL. The second way seems to be more preferable, since in the first case one cannot go without upgrading OpenSSL, although from the point of view of implementing the new requirements of TK-26, at least to the PKCS # 12 container. Embedding new algorithms implies first of all the inclusion of Russian OIDs recommended by TC-26 in the OpenSSL project (
obj_mac.h ):
#define SN_cryptopro "cryptopro" #define NID_cryptopro 805 #define OBJ_cryptopro OBJ_member_body,643L,2L,2L #define SN_cryptocom "cryptocom" #define NID_cryptocom 806 #define OBJ_cryptocom OBJ_member_body,643L,2L,9L #define SN_id_tc26 "id-tc26" #define NID_id_tc26 958 #define OBJ_id_tc26 OBJ_member_body,643L,7L,1L …
For the convenience of embedding GOST-algorithms in XCA and identity with OpenSSL, we also note the entered constants that determine the type of key for GOST:
#define EVP_PKEY_GOST3410 NID_id_GostR3410_2001 #define EVP_PKEY_GOST3410_2012_256 NID_id_GostR3410_2012_256 #define EVP_PKEY_GOST3410_2012_512 NID_id_GostR3410_2012_512
Here’s how the struct typelist typelist [] structure could now look like in the NewKey.cpp file:
static const struct typelist typeList[] = { { "RSA", EVP_PKEY_RSA }, { "DSA", EVP_PKEY_DSA }, #ifndef OPENSSL_NO_EC { "EC", EVP_PKEY_EC }, #endif { "GOSTR3410-2001", EVP_PKEY_GOST3410}, { "GOSTR3410-2012-256", EVP_PKEY_GOST3410_2012_256}, { "GOSTR3410-2012-512", EVP_PKEY_GOST3410_2012_512}, };
And such a refinement of OpenSSL and allows you to embed Russian cryptographic algorithms in the CA «XCA». Now CA "XCA" can perform all the functions of the CA, starting with the generation of any GOST s keys:

issuing certificates and ending with issuing lists of canceled certificates (CRL / CAC):

Above, we said that employees should receive a private key and certificate on discarded media. Tokens / smartcards (token / smartcard) with a PKCS # 11 interface are used as such media in CA “XCA”. If we talk about the support of Russian cryptography, then the project needs to be finalized to support
PKCS # 11 tokens in accordance with the recommendations of TC-26 (
pkcs11_gost.h ):
… #define NSSCK_VENDOR_PKCS11_RU_TEAM 0xd4321000
Accommodation CA "XCA" in the enterprise
And so, in the end, we will have a fully functional CA of the enterprise scale, fully supporting Russian cryptography.
Where to place CA "XCA"? The most reasonable thing is the personnel department or the security service. When applying for a job in one of these services, the employee receives here, among other things, the token on which the non-recoverable key is generated:

and installed his certificate:

As a result, both the root self-signed certificate of the center and the certificates of the employees of the enterprise will be stored in the database of the CA “XCA”:

The database also contains information about where private keys are stored:

Christmas chores
And now, after a painstaking study of the project, the following letter was sent to its author, Christian Hohnstädt, on the eve of the New Year:
Hello, Christian!
We monitor your product XCA. Exploring it, we raise our professional
level. We adapt it to use Russian cryptographic algorithms. In gratitude
for your work we want to send you a gift (a bottle of Russian vodka),
but, unfortunately, do not know your post address. Please let us know
it, so we can send you a gift.
Translated, it looks like this:
Hello, Christian!
We monitor your XCA product. Exploring it, we improve our professional level. We adapted it for Russian cryptographic algorithms. In gratitude for your work, we want to send you a gift (a bottle of Russian vodka), but, unfortunately, we do not know your mailing address. Please let us know.
And the author responded:
Thanks, please send it to me at my company address.
I'm usually not at home when parcel services deliver packets.
Innominate Security Technologies
Christian hohnstaedt
Rudower chaussee 13
12489 Berlin
Germany
What is remarkable in the author's response:
Thank you, please send it to the address of my company. Usually I'm not at home when the delivery service delivers the parcel.

It turned out that German programmers as well as Russian and all programmers in the world spend most of their time at work!
And of course, our traditionally Russian present is a bottle of vodka and a box of chocolates, but with the addition of a soft toy Little Fox, was delivered to the Author !!!
But before that there was a letter, an excerpt from which was placed at the beginning of the article:
If your programmers found issues or bugs in my code,
I can fix them, too.
I think noone.
And here is the translation:
If your programmers have found errors in my code, I ask you to inform me about them so that I can fix them.
I think that no one else has looked so deep into my code like you.
Such an assessment is worth a lot.
What can I add? Only that CS "XCA" operates under Linux, Mac OS X, other Unix and MS Windows forks.
PS One can only dream of such cooperation and understanding of the programmers of two great countries - the Russian Federation and the Federal Republic of Germany.