About PKI "on fingers" in 10 minutes

Published on August 10, 2017

About PKI "on fingers" in 10 minutes



    I suggested to colleagues to conduct an internal mini-lecture on sabzh - the idea came up. He sat down to write a lecture plan and ... some freaked out - eventually woke up, adding a small guide. I thought it would be useful to add something here to quickly understand what PKI is, why it is needed and how it works, as I was preparing to refresh my memory while searching for information, including on my favorite Habrahabr, but articles in this format not found.

    I am writing on the example of our everyday tasks that many are familiar with: passwordless access to OpenVPN servers and protection of access to resources using HTTPS.

    You can’t do without theory


    PKI (Public Key Infrastructure) is about security. It is understood that each entity in the infrastructure has its own key, by which it is uniquely identified. That is, if the key is stolen, the stolen entity may appear to be the affected entity. PKI is needed in order to quickly minimize the consequences of such theft. The key is represented in two parts: public and private.

    The analogue is RSA keys for SSH, but it is difficult to call them infrastructure, since there is no centralized mechanism for managing them. Also, the difference is that the public part of the key in the key pair for SSH is unchanged, and the certificate (public part of the PKI member key) can be reissued at any time.

    In PKI, there is one (in fact, there must be at least two) or several Certification Authority - certification authorities (certification authorities) that give out the public parts of their keys to customers who are issued certificates signed by them. Thus, the participants in the infrastructure “understand” who is managing them and whether the certificate issued by him or their “comrades” is valid at the current time (one of the most important attributes of certificates is their validity period). Or, a server that has a public part of the CA key of the infrastructure in which it and its clients work, understands that a client with a valid certificate came to it, and allows it something, or prohibits it otherwise.

    OpenVPN: how it happens


    In fact, many companies already have a “PKI” for this case and it has a name because it is one of the employees. We will name such a person, for example, Poluekt (s) and tell how it usually works, and then I will tell you how it should be ideally.

    When a new employee appears in the company, Poluekt creates and sends him an archive, in which, in addition to the configuration of the OpenVPN client itself, there are files (for example, employee A. Ivanov):

    • a.ivanov-office. key - its private key, the very pulp that needs to be stored as the apple of an eye and not shown to anyone (the analogue in SSH is the id_rsa file);
    • a.ivanov-office. csr - Certificate Signing Request, a request for signing a certificate, which describes who needs to issue a certificate for, is generated on the basis of the previous file so as not to “burn” the private key (for the operation of OpenVPN itself, you don’t need to see a bit);
    • a.ivanov-office. crt - the coveted certificate that he presents to the OpenVPN server to allow it to connect (in fact, this is the public part of the key);
    • ca. crt is the certificate of our CA so that the OpenVPN client presents it to the server, so that it matches it with the private part that it has and makes sure that it was he who signed the certificate, and not someone else. "Detail", which indicates the affiliation of OpenVPN client A. Ivanov to the PKI on which the server is running.

    These are simple text files in a special PEM format. It’s very convenient, unlike, for example, the cerebral Java Keystore or PFX from Microsoft: you can merge certificates into a single file with a simple cat to form CA chains (the so-called bundle, which is useful for nginx, for example, in the configuration of which there is no separate directive for CA certificate directions), you can combine CA certificates and your own, and even your private key, if you need it for some reason. And another useful thing: you can register a CA certificate directly in the configuration of the OpenVPN client, between the <ca> </ca> tags. Probably, it should be possible to register the certificate in this way. However, I am already distracted by particulars.

    At Acme, all these files are generated by the Semiect ...

    And now as it should be


    In my example, simplified:

    • I locally generate my private key (it’s possible and, perhaps, logically, to use the one already ready from ~ / .ssh / id_rsa):

    openssl genrsa -out openvpn.key 2048

    • I am preparing a certificate signing request - CSR, for which I am filling out a short form:

    openssl req -new -key openvpn.key -out a.vrublevskiy-office.csr
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [XX]:RU
    State or Province Name (full name) []:.
    Locality Name (eg, city) [Default City]:Moscow
    Organization Name (eg, company) [Default Company Ltd]:Pixonic
    Organizational Unit Name (eg, section) []:Sysadmins Dept
    Common Name (eg, your name or your server's hostname) []:Alexander Vrublevskiy
    Email Address []:a.vrublevskiy@pixonic.ru

    Please enter the following 'extra' attributes
    to be sent with your certificate request
    A challenge password []:
    An optional company name []:


    (it’s better not to specify the password at the end, otherwise you will have to enter it every time you connect, and we have just the certificates according to the certificates to prevent this; moreover, we have OTP from Google at Pixonic );

    • I am sending the resulting a.vrublevskiy-office file. csr Half Act;

    • The half-act, having received my request and having both parts of the CA key (here ca.key and ca.crt), issues a certificate for me by signing it with the CA key (fashionable hipsters use easy-rsa, but we are harsh bearded admins):

    openssl x509 -req -in a.vrublevskiy-office.csr -CA ca.crt -CAkey ca.key -out a.vrublevskiy-office.crt -days 90

    • The half-act sends me the resulting file.

    A reasonable question arises: why such difficulties? What is the PKI trick? I answer. The fact is that there is simply no chip in this chain. And it is called - CRL (Cerificate Revocation List). This is a list of revoked certificates that is published by CA, and into which Poluect can enter my certificate, issued and signed earlier, in case it turned out that, for example, I had been overused with substances and was able to dictate my private key to competitors (well, or they stole from me laptop).

    Do you need this feature - a question for discussion. Accordingly, how to implement it, so far, is beyond the scope of this article.

    And about the validity of the client certificate: if we assume that I got a job at Pixonic under a temporary contract for 3 months and we did not renew it, then in the described situation my access to the VPN will automatically be disconnected after 90 days from the date of issue of the certificate. What will not happen with SSH access if colleagues forget to disconnect an account in FreeIPA or remove a line from authorized_keys by hand. C is sesurite.

    Now according to Borschev HTTPS


    Suppose you want to "enable SSL" for your site so that visitors have a beautiful lock in the browser. Here, in fact, everything is the same, but with some nuances:

    • Obviously, on your side you can only generate a private key and a certificate signing request.
    • When generating a request as a Common Name, you must specify the ServerName of your virtual host and all the aliases that you specify for it in the web server configuration. For example, domain.tld and www.domain.tld , although "www" CAs are usually added themselves when issuing certificates. Most often, you can simply specify * .domain.tld (to request the so-called wildcard certificate), but is it possible, you need to find out from a particular CA, and also clearly understand the consequences of such a decision. As a rule, public CAs do not allow you to use an IP address as an alias.
    • When generating a request, you should not specify a challenge password, otherwise you will have to enter it manually each time you restart the web server.
    • Typically, public CAs are venerable offices like Comodo, Symantec, and GoDaddy. Issuing a certificate costs money, but a good certificate costs a lot of money. However, apart from them, relatively recently, Let's Encrypt exists - a free project that many tend to trust, but I would very well think about what resources and under what circumstances to protect them with certificates.
    • These guys agreed with other guys in such a way that the latter preinstall the certificates (public key parts, i.e. ca.crt from the previous example) of these CAs into their browsers. That is, PKI as such is out of the question. It’s just that everyone agreed to trust certain companies. This is not bad, since HTTPS is ultimately needed to encrypt traffic, and you can also encrypt it with a self-signed key pair. Rather, this is a matter of prestige, so as not to shine on the entire Internet with a warning about an expired / invalid certificate.
    • Some very talented CAs offer the convenience of generating a private key and CSR for you. This is not necessary. I hope it’s clear why.
    • On the validity period of certificates. You should always think in advance of a system for their timely update. This is especially true for certificates from Let's Encrypt, whose validity period is only 3 months (at the time of writing).
    • And about the agreements between "these guys." As it turned out after a recent enchanting story with Google and Symantec, now you need to be able to lay straws on such a “funny” case.

    So it goes. I hope that the understanding promised at the beginning of the article has appeared.

    PS Of course, a venerable pro-guard who ate this dog may have hair stirring in the most immodest places from how such a complicated thing as PKI is described in the article. I wrote this small guide for those who seem to encounter this at work, but do not really understand what and why it is doing. And there is enough hardcore “matan” in me without these in your Internet. If, despite this, you have something to say, welcome to the comments.