OpenSSL based certification authority
When I worked as a system administrator, I needed to implement a VPN for several dozen company branches, intranets and mail on servers in Moscow with harsh protection and access via VPN in general from everywhere. At the same time, the entire system was invented and its deployment was to be organized in one person. The budget was thousands of dollars and a half, it was 4 years ago, for some time I honestly tried to find more or less affordable software, then dishonestly tried to find something on torrents — it's empty. As a result, OpenSSL and OpenVPN. In this introductory text I would like to talk about OpenSSL.
In the end, were deployed:
The following will be interesting to corporate techies rather than ordinary users. Provided, if: the organization is not a state, there is a goal to save money, there is a desire to try some “things” without splitting into the R & D sum with six zeros.
')
It is assumed that readers are familiar with the concepts of VPN (in this case, Virtual Private Network) and SSL (Secure Sockets Layer), and that they are electronic certificates in x.509 format.
In the resulting system, certificates could be updated, revoked, used for authentication, encryption of code, files, mail, and in the case of compromise, withdraw a branch without killing the entire CA. To do this, we had to be very careful about the OpenSSL configuration files, build the Certificate Revocation List (CRL) generation procedure and the correct CA hierarchy. Only then the chosen implementation allowed the use of certificates, incl. and in automatic processes, where there was no one to press the button " Yes, I still trust this certificate, although it is overdue and released incorrectly and is not intended for this at all ."
It is important to remember ( as it turned out ) that the issuance and use of digital signature certificates is not only technical, but also an organizational process, without which the benefits of using this kind of protection will disappear. The disc with CA, for example, after issuing all certificates, it is better to remove or disconnect ( if it is USB ) and put it in a safe. And start a magazine.
For the intranet site (the first echelon - Apache, what was behind it - it doesn’t matter ) multifactor authentication was implemented. Usually, the first and only factor in authentication is the knowledge of the login and password or the login and pin code; only the client is presented to the server, and the server does not need to prove that it is he, hence the possibility of theft of the login / password and / or substitution of the server. In my case it was unacceptable, so the need to have a certificate was added to the knowledge of the login / password. Certificates were unloaded from CA in the PKCS12 (PFX) format with a password.
Something was added to the server's configuration:
Those. allow anyone whose certificate is issued by My LTD OpenSSL CA ( in reality, of course, the name is different )
You can also restrict access by name:
The server logs are written using the following structure:
The received certificate together with the keys was installed on the user's computer ( into the registry encrypted on the pin code ) is a very frequent case, and the certificate can only be used on this computer and if the operating system is reinstalled, you need to receive the certificate again, of course the private key was generated on the computer, and not issued to you on a diskette when visiting the CA, which can be considered a profanation with particular cynicism, because in fact it becomes the owners of your supposedly private key ( with the possibility of Posting for you the "electronic signature" ) also the CA, and at a certain level of sloppiness, all succeeding administrators in the CA. But at the TC there is an opportunity to provide a service for “restoring” the certificate.
Because I was myself to the TC, I was spared both from such a “service” and from copying certificates “by memory” by technical specialists (and not very much).
To traveling employees certificates were issued on hardware media - Aladdin USB dongle. Banks and CAs offered (and offered) to legal entities to use floppy disks for this purpose, or a modern version - flash drives. This is more convenient, but leads to another danger - the ability to make a duplicate. In the ideal case, keys and certificates should be stored on a smart card, which is additionally protected by a pincode, has its own crypto processor on board, a random number generator, which is believed to greatly reduce the chances of potential attackers to decide to pick up your key. In addition, smart cards are almost impossible to copy.
Aladdin eToken USB keys are just such cards, only in the form of a USB stick.
In the case of authentication, only a small amount of data required for the procedure is encrypted, but if you wish, you can encrypt all the traffic between the client and the server. If you need to use the certificate for encryption on a server with a large number of clients, you need to put something more serious in the server, for example, a crypto board, a free IBM HTTP Server ( the same Apache, in fact ), even some of them supports
Of course, no one bothers to use smart cards that look like ordinary plastic cards, but then every workplace on which such a card will need to be used must have a card reader.
After we received a certificate from the CA, placed it on a “token”, and closed the token with a pin-code, we are able to perform two-factor two-way authentication. The first factor - we have a token, the second factor - we know a pin-code from it. And having a certificate, we can verify that the server is really the one for whom it claims to be, in this case, bobik.ru and bobik.ru will not be confused, because the Russian “o” in the second version will give a name mismatch ( for a computer this is all - different letters ).
Due to the fact that the list of revoked certificates (CRL) was registered (and regularly updated) in the server settings, it was always possible to immediately suspend access to the site of any user, incl. in case of loss (or suspicion of loss) of the USB key, or when the employee is dismissed.
Many domestic CAs specify the location of the CRL, and they forget to upload or update the list itself, and when, say, Outlook cannot verify the certificate on the revoked list and hangs a warning, the CA consultant by phone can offer you to ignore this warning. If the client is a different server, if the certificate cannot be verified, it will simply break the connection.
If necessary, the certificate was reissued with the same private key, which made it possible not to lose access to previously encrypted data.
In general, everyone understands that the certificate is a good thing, it remains to release it correctly. After a rather lengthy run-in and study of the “documentation” of several hundred pages ( in fact, it was a tutorial on PKI and cryptography from Intuit ), it turned out that the OpenSSL configuration examples available on the Internet at that time are suitable only for the purposes of “playing around”, For some time I came across the fact that the certificates I issued did not work in Outlook, then in Thunderbird, then in Firefox. IE was the most omnivorous.
For everything to be a little more serious, a small straightening is needed:
The next step of the knee automation can be to write an interface for viewing the list of certificates. The list is named index.txt, an understandable format, and I wrote an interface for it on the HTA. To simplify debugging, the HTA called batch files for individual procedures. The required set is as follows:
In the end, were deployed:
- certificate issuing center (CA - Certificate Authority, the same CA - Certifying Center, in domestic terminology, the organization authorized to issue certificates),
- Intranet site with client certificate access authorization,
- VPN with mutual authentication of servers, clients and dynamic routing,
- Authorize clients on the corporate IM server using the same certificates.
The following will be interesting to corporate techies rather than ordinary users. Provided, if: the organization is not a state, there is a goal to save money, there is a desire to try some “things” without splitting into the R & D sum with six zeros.
')
It is assumed that readers are familiar with the concepts of VPN (in this case, Virtual Private Network) and SSL (Secure Sockets Layer), and that they are electronic certificates in x.509 format.
Ca
In the resulting system, certificates could be updated, revoked, used for authentication, encryption of code, files, mail, and in the case of compromise, withdraw a branch without killing the entire CA. To do this, we had to be very careful about the OpenSSL configuration files, build the Certificate Revocation List (CRL) generation procedure and the correct CA hierarchy. Only then the chosen implementation allowed the use of certificates, incl. and in automatic processes, where there was no one to press the button " Yes, I still trust this certificate, although it is overdue and released incorrectly and is not intended for this at all ."
It is important to remember ( as it turned out ) that the issuance and use of digital signature certificates is not only technical, but also an organizational process, without which the benefits of using this kind of protection will disappear. The disc with CA, for example, after issuing all certificates, it is better to remove or disconnect ( if it is USB ) and put it in a safe. And start a magazine.
Site
For the intranet site (the first echelon - Apache, what was behind it - it doesn’t matter ) multifactor authentication was implemented. Usually, the first and only factor in authentication is the knowledge of the login and password or the login and pin code; only the client is presented to the server, and the server does not need to prove that it is he, hence the possibility of theft of the login / password and / or substitution of the server. In my case it was unacceptable, so the need to have a certificate was added to the knowledge of the login / password. Certificates were unloaded from CA in the PKCS12 (PFX) format with a password.
Something was added to the server's configuration:
<Location /location1>
SSLOptions +FakeBasicAuth +StdEnvVars
SSLVerifyClient require
SSLVerifyDepth 2
SSLRequire %{SSL_CLIENT_I_DN_CN} in {"My LTD OpenSSL CA"}
Those. allow anyone whose certificate is issued by My LTD OpenSSL CA ( in reality, of course, the name is different )
You can also restrict access by name:
<Location /location2>
SSLOptions +FakeBasicAuth +StdEnvVars
SSLVerifyClient require
SSLVerifyDepth 2
SSLRequire %{SSL_CLIENT_S_DN_CN} in {"Ivan A Ivanov", \
"Petr B Petrov"}
The server logs are written using the following structure:
CustomLog ../logs/ssl/ssl_request.log \
"\"%t\",\"%h\",\"%{SSL_CLIENT_S_DN_CN}x\",\"%r\",\"%s\"" env=!dontlogit
Certificate distribution
The received certificate together with the keys was installed on the user's computer ( into the registry encrypted on the pin code ) is a very frequent case, and the certificate can only be used on this computer and if the operating system is reinstalled, you need to receive the certificate again, of course the private key was generated on the computer, and not issued to you on a diskette when visiting the CA, which can be considered a profanation with particular cynicism, because in fact it becomes the owners of your supposedly private key ( with the possibility of Posting for you the "electronic signature" ) also the CA, and at a certain level of sloppiness, all succeeding administrators in the CA. But at the TC there is an opportunity to provide a service for “restoring” the certificate.
Because I was myself to the TC, I was spared both from such a “service” and from copying certificates “by memory” by technical specialists (and not very much).
To traveling employees certificates were issued on hardware media - Aladdin USB dongle. Banks and CAs offered (and offered) to legal entities to use floppy disks for this purpose, or a modern version - flash drives. This is more convenient, but leads to another danger - the ability to make a duplicate. In the ideal case, keys and certificates should be stored on a smart card, which is additionally protected by a pincode, has its own crypto processor on board, a random number generator, which is believed to greatly reduce the chances of potential attackers to decide to pick up your key. In addition, smart cards are almost impossible to copy.
Aladdin eToken USB keys are just such cards, only in the form of a USB stick.
In the case of authentication, only a small amount of data required for the procedure is encrypted, but if you wish, you can encrypt all the traffic between the client and the server. If you need to use the certificate for encryption on a server with a large number of clients, you need to put something more serious in the server, for example, a crypto board, a free IBM HTTP Server ( the same Apache, in fact ), even some of them supports
Of course, no one bothers to use smart cards that look like ordinary plastic cards, but then every workplace on which such a card will need to be used must have a card reader.
After we received a certificate from the CA, placed it on a “token”, and closed the token with a pin-code, we are able to perform two-factor two-way authentication. The first factor - we have a token, the second factor - we know a pin-code from it. And having a certificate, we can verify that the server is really the one for whom it claims to be, in this case, bobik.ru and bobik.ru will not be confused, because the Russian “o” in the second version will give a name mismatch ( for a computer this is all - different letters ).
Certificate Revocation Lists
Due to the fact that the list of revoked certificates (CRL) was registered (and regularly updated) in the server settings, it was always possible to immediately suspend access to the site of any user, incl. in case of loss (or suspicion of loss) of the USB key, or when the employee is dismissed.
Many domestic CAs specify the location of the CRL, and they forget to upload or update the list itself, and when, say, Outlook cannot verify the certificate on the revoked list and hangs a warning, the CA consultant by phone can offer you to ignore this warning. If the client is a different server, if the certificate cannot be verified, it will simply break the connection.
If necessary, the certificate was reissued with the same private key, which made it possible not to lose access to previously encrypted data.
OpenSSL Finishing
In general, everyone understands that the certificate is a good thing, it remains to release it correctly. After a rather lengthy run-in and study of the “documentation” of several hundred pages ( in fact, it was a tutorial on PKI and cryptography from Intuit ), it turned out that the OpenSSL configuration examples available on the Internet at that time are suitable only for the purposes of “playing around”, For some time I came across the fact that the certificates I issued did not work in Outlook, then in Thunderbird, then in Firefox. IE was the most omnivorous.
For everything to be a little more serious, a small straightening is needed:
- if you want your system to live for more than a year, increase the number of days to 3650 before issuing the root CA certificate, then return it back, it’s better to leave the year or six months for user certificates
- in the [CA_default] section
set the unique_subject parameter to “yes” - this will not allow you to issue 2 identical certificates - in the [user_cert] section
add
ExtendedKeyUsage = clientAuth - section for servers may look like this
[ server_cert ]
basicConstraints = CA:FALSE
nsCertType = server
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = nsSGC, serverAuth - in the section [v3_ca]
to change
basicConstraints = CA:TRUE, pathlen:5 - uncomment nsCertType and keyUsage
- add
extendedKeyUsage = serverAuth, clientAuth
Certificate Automation
The next step of the knee automation can be to write an interface for viewing the list of certificates. The list is named index.txt, an understandable format, and I wrote an interface for it on the HTA. To simplify debugging, the HTA called batch files for individual procedures. The required set is as follows:
- Separately filed environment variable settings
- issuing an arbitrary certificate - a minimum of settings, asking a bunch of questions, allowing you to issue a certificate, say, for partners, then sign in our CA
- issuing a root CA certificate - called once or several times if a tree is being built, with pens
- issuing a server certificate is understandable, openssl is called with the -extensions server_cert parameter, and in the [server_cert] section there must be the necessary parameters in the config, another difference is that it is not packaged in PFX and creates unpacked versions of keys, some servers may need
- issuing a user certificate
- certificate revocation is an interesting process: the necessary one was extracted from the archive (you need to do it yourself) of the issued certificates (by name, but you can also by serial number), then it was already reviewed by it
- User certificate update - first, the old certificate was revoked (with batch file No. 6), then a new certificate was created (with batch file No. 5) for the old key
- updating the list of revoked certificates is a simple command, but in my case it was accompanied by the launch of a Perl script that prepared the resulting list and placed it in a directory ( address book, as it is sometimes called ) Lotus Domino, from there it was easier to get (via LDAP, is almost a standard way of distributing CRL)
Source: https://habr.com/ru/post/107467/
All Articles