Certification Center based on OpenSSL, SQLite3 and Tcl /Tk

Certification Center based on OpenSSL, SQLite3 and Tcl /Tk If you walk along the expanses of Habrahabra, you can find various publications on the issue of creating digital certificates, the organization of the Centers certification (CA) or even Certification Centers ( CU ) based on OpenSSL. Basically, these articles describe, in varying degrees, the use of either the openssl utility or the library functions of OpenSSL to work with certificates. At the same time, the database of certifying centers was built on directories and files, and continues to be built on them, as the command line was used as an administrator interface (even on Android ), And continues to stay with them. A pleasant exception here is the project XCA . advanced qualified EP , and if you add more and stronger Using the EP is impossible without certificates, and for the issuance of certificates and management of them, it is naturally required UTS . And how many tenders are held, how much is deployed by the UC, how much money is spent For ordinary citizens, it seems that the UC is something huge (how is the Center, almost like the Flight Control Center)?
From the point of view of responsibility, the UC is exactly so. After all, the certificates issued by the CA are in fact equated today in the passport.
From a programmatic point of view, everything is not so scary. Thus, the project of CAFL63 certification center was born.
So, what is the Certification Authority today? It includes the Registration Center (CR), which is responsible for receiving applications from citizens for certificates. Today, certificates are issued for legal entities, individuals, individual entrepreneurs. Applications are accepted electronically in the format PKCS # 1? CSR (Certificate Signing Request) or SPKAC. Note that the CSR format is a PKCS # 10 request (DER-encoding) in the PEM encoding with the heading ----- BEGIN REQUEST CERTIFICATE -----.
Users who want to receive a certificate must have a program /utility that will help them create the query:

This utility first of all should generate a key pair containing the public and private keys. Then the utility will provide an electronic questionnaire (see above) that will need to be filled in, ask for what purposes a certificate is needed and eventually form a request:

The request is a completed questionnaire, the purposes for which a certificate is required, the user's public key, and all this is signed by the user's private key. About such a utility that can generate a private key not only in the file, but also in token PKCS # 11 , as well as with using CSP ala Microsoft, we will describe in the next publication. Further, with a package of documents certifying, in particular, the identity of the applicant, and with the electronic medium on which the request is stored (I emphasize the request, the private key is best stored elsewhere), the citizen comes to the CA of the UC.
In the CR, check the documents, the request (the completed data, the correctness of the electronic signature, etc.), and if everything went successfully accept the request, approve it and send it to the Certification Center (CA). But this is ideal. In practice, everything looks different.
Citizens and organizations need a certificate (for access to Service State Service , For tax reporting, to participate in bidding), but they do not know what it is and what to do with it. They are sincerely convinced that in the CA they receive an electronic signature of the facsimile type. But this is a problem of education. Therefore, applicants come to the CA of the UC, present documents. Together with the employee of the CR go to a separate workplace and prepare a request for a certificate. The prepared request on the electronic medium, as already mentioned, is sent to the CR. What needs to be remembered here is the applicant. First and foremost, take the media with the private key created!
The approved request on the electronic medium is transferred to the CA, where on its basis the certificate will be issued.
This is a basic diagram of the work of the UC. Details will become clear below. One remark, for the convenience of demonstrating the query preparation utility, the CR and CA are combined into one demonstration complex. But there are no problems with the diversity of functionality. The simplest of them is to have a copy of CAFL63 on each workstation and use only the required functionality.
When the project was in full swing, the project caught its eye. SimpleCA . The study of this project was very helpful in the final implementation of CA CAFL63.
Distribution and source code CAFL63 for platforms Win32 /Win6? Linux_x86 /Linux_x86_64 can be downloaded here . After downloading the distribution kit, carefully read the file README.txt.
And so, run the CAFL63 utility and the start page appears on the screen:
$ CAFL63

We start the work by clicking the "Create Database" button. Database CA is created using cross-platform DBMS SQLite3 . The DB of the CA contains several tables. The main table mainDB contains only one entry that stores the root certificate, the private key encrypted on the password, and the CA settings. There are two tables related to requests for certificates: current reqDB requests and archive of reqDBArc requests. For certificates, three tables are created: a table of new certDBNew certificates, a CertDB certificate archive table, and a certificate revocation table called CertDBRev. All query and certificate tables use as the primary key. the hash value is (sha1) from the public key. This turned out to be very convenient, for example, when searching for a certificate on demand or vice versa. In the database there is one more table crlDB, in which the lists of revoked certificates are stored. And so, we clicked the button "Create Database":

Creation of the CA begins with the selection of the directory in which we will store the database and the password for accessing the private key of the CA. By pressing the "Next" button, we go to the page for selecting the type and parameters of the key pair for the CA:

Having defined the key pair for the root certificate of the certification center being created, we proceed to fill out the form with information about the owner (the first screenshot we missed):
Note that the CAFL63 utility has a certain "intelligence" and therefore controls not only the presence of data in the fields, but also the correctness (red illumination is incorrect) of filling such fields as TIN, OGRN, SNILS, BIND, e-mail address, etc.
After completing the fields with information about the owner, the CA will be asked to determine the system settings of the CA:
If you are not going to work with Russian cryptography, then you can use the usual OpenSSL. To work with Russian cryptography, you need to specify the appropriate version, modification of OpenSSL. For more information, read README.txt in the downloaded distribution. Also, in accordance with FZ-6? it is proposed to give information about the certification of the CA itself and the CPSI used by it.
After correctly filling in all the fields, once again you will be asked to verify their validity and click the "Finish" button:
After clicking the "Finish" button, the DB of the CA will be created, to which the CA root certificate, the private key, system settings will be saved, and the CAFL63 utility start page appears again. Now that we have a database of the newly created CA, we click the button "Open DB", select the directory from the database and get into the main working window of the CA:
Clicking the competitor "View CA CA", we are convinced that this is exactly our root certificate:
The next step is to prepare the application templates /profiles for legal entities, individuals, individual entrepreneurs ( Tools-> Settings-> Types of Certificates-> New ):
After setting the name of the new profile, it will be suggested to determine its composition:
After preparing profiles, the UC is ready to receive applicants and applications from them. As noted above, the applicant can come with both a ready application for a certificate and without it.
If the applicant came with a completed application, then after checking his documents, the application is imported into the DB of the UC. To do this, select the tab "Requests for certificates" on the main working window, click the "Import query.CSR" button and select the file with the request. After that, a window with information about the request will appear:
After reviewing the request and making sure it is correctly filled in, you can click the "Import" button to put it into the database. Just note that if you try to repeatedly enter a query in the database, the CA will receive the message:
Requests in the DB of the CA are marked (column "Type") either as "Locale" created at the CA, or as "Import" created by the applicant himself, and also the time of receipt of the application in the CA is fixed. This can be useful in the analysis of conflict situations.
If the applicant came without an application and asked to create it, it is first of all necessary to determine ( Specifications-> Types of Certificates-> Person-> Edit ) With the key pair type ( .-> Key Pair ), For what goals ( .-> Key Usage ) you need a certificate:
Then, to create the query, you must click the "Create Request /CSR" button:
After you have defined the profile and clicked the "Next" button, then the further procedure differs little from the release of the root certificate. One important note, remember the storage of the private key and the password for accessing the key.
The created or imported order is located in the DB of the CA and is displayed on the main window on the tab "Requests for certificates". The incoming requests are in the "review" stage (column "Status" of the tab "Requests for a certificate" and "Archive of Requests"). For each new request, a decision must be made (drop-down menu when the right mouse button is pressed on the selected query):
Each request must be either rejected or approved:
If the request is denied, it is moved from the current reqDB request table to the reqDBArc query archive table and, accordingly, disappears on the "Certificates Requests" tab and appears on the "Queries Archive" tab.
The approved application remains in the reqDB table and on the "Requests for certificates" tab before issuing the certificate, and then it also enters the archive.
The procedure for issuing a certificate differs little from the procedure for creating a download (menu item "Issue a certificate"):
The issued certificate immediately appears on the "Certificates" tab. In this case, the certificate itself falls into the certDBNew table of the DB of the UC and remains there until it is published. The certificate is considered published after it is exported to the SQL dump of new certificates, which is sent to the public service. Publishing a certificate results in moving it from the certDBNew table to the certDB table.
If you right-click on the selected line in the "Certificates" tab, a menu with the following functions appears:
If the request was created on the CA with the key generation and its saving in the file, it is necessary to form the container PKCS # 12 and transfer it to the applicant:
You should pay attention to the "friendly name" - the quotes in it must be escaped:
After creating the protected container PKCS # 1? the file with the private key of the applicant is destroyed.
And so, the UC began its life, issued the first certificate. From the tasks of the CA, it is an organization of free access to the issued certificates. Publication of certificates usually goes through Web-services. There are this service is and in CAFL63:
To publish certificates and lists of revoked certificates on a public service, the CA preloads certificates or files ( Certificates-> Export of certificates ), Or makes the SQL -dump of the entire certificate table from which it is possible to create the certificate DB and load them into it, and then SQL-dump new certificates from which they will be added to the public service database:
The last screenshot is made on the Windows platform and demonstrates the cross-platform DB of the UC: it was simply copied from the Linux platform.
The basic function of the CA is to publish a list of revoked certificates by analogy with how this makes the Ministry of Internal Affairs of relatively lost passports. The certificate can be withdrawn at the request of the owner. The main reason for the recall is the loss of the private key or the loss of confidence in it.
To revoke a certificate, just select it on the "Certificates" tab, right-click and select the "Certificate Revocation" menu item:
The recall procedure does not differ from the procedure for creating a request or issuing a certificate. The revoked certificate falls into the cerDBRev table of the CA database and appears in the "Revoked certificates" tab.
It remains to consider the last function of the CA - the release of the CRL - the list of revoked certificates. The CRL list is generated on the "Revoked certificates" tab when you click the "Create CRL /CRL" button. All you need to do here is to enter the administrator's password and confirm your intention to issue a CRL:
The released CRL falls into the crlDB table of the database and is displayed in the "CRL /SOS" tab. To view the CRL or export it for publication on a public service, you must always select the line you want, right-click and select the menu item:
That's all.
You can download the distribution of CAFL63 for Win32 /Win6? Linux_x86 /Linux_x86_6? here . Moreover, this all works successfully and on the Android platform. Imagine which protected CA: on one tablet CA, on another CR and all this in a dedicated room. No enemy is terrible.
If you have any questions, wishes or desire to help, I'm at your service. It seems to me that ifand to conduct case studies together with Forks openssl, then all issues with the CA, except for organizational, could be closed once and for all.
+ +1 -

Add comment