aboutsummaryrefslogtreecommitdiff
path: root/content/posts/2023-07-24-tls/index.md
blob: da413dcb76f40fe720a442404be15023d46269d5 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
+++
categories = ['Без рубрики']
date = '2023-07-24T20:04:17Z'
tags = ['it', 'Россия', 'TLS']
title = 'Немного мыслей о TLS (HTTPS) в России'
+++

Накопилось немного мыслей относительно того, что может грозить нам (и мне) в
связи с трендом на “балканизацию” рунета.

И самое болезненное место — HTTPS который нынче стандарт де-факто в современных
интернетах. А болезненное оно потому, что целиком и полностью контролируется
другой стороной нынешного противостояния. Все доверенные удостоверяющие центры
принадлежат странам “коллективного запада”. Помню, были ещё какие-то китайские,
вроде, но с ними был какой-то скандал и не факт что они есть.

Есть относительно [доверенный УЦ от Минцифры](https://www.gosuslugi.ru/tls). Это
здорово и я это всецело поддерживаю. Вот только есть момент. Он не для нас,
простых людей, и при попытке его получить видим то, что на скриншоте ниже. А
сранный Firefox вообще хочет его внести в черный список, чтобы даже специально
его нельзя было установить. В общем, пока его я поставить не могу даже при всём
желании.

![Услуга предоставляется только юридическим
лицам](/img/posts/20230724_202627.webp)

Какие ещё альтернативы есть, если нас вдруг прокинет Let’s encrypt?

1. Не использовать HTTPS вообще. Я же не магазин и у меня нет форм логина,
   которые требуют шифрования. Так-то оно так, да не так. Браузеры уже сейчас
   очень косо смотрят на “обычные”, не HTTPS сайты, а в дальнейшем, не удивлюсь
   если перестанут открывать вообще. Так же на HTTP сайтах не работают
   прикольные браузерные API типа геолокации (наверное, это в каком-то роде даже
   плюс 😉 ). Ну и ещё проблема, что, например, этот сайт без HTTPS вообще не
   может работать, ибо для доменов зоны .dev насильно включено HSTS и они не
   могут работать не по HTTPS. Последнее то я решу старым добрым доменом
   neonxp.ru, но тем не менее.
2. Самоподписанные сертификаты. Вот это уже более менее похоже на правду! Да,
   такие сайты надо добавлять в исключения и мороки с сертификатами чуть больше.
   Но тут та же история с доменами .dev. Для них самоподписаные не катят. Выход
   — опять таки старый добрый neonxp.ru.

К чему я всё это? А то что в случае “балканизации” мы остаемся без нормального
валидного HTTPS. Для себя я выбрал второй путь, с самоподписанными
сертификатами. Чекнуть как работает можно на зеркале блога на
<https://neonxp.ru> . Там я выпустил сам себе сертификат на домен от своего
собственного удостоверяющего центра 🙂 А доверять ему или не доверять — дело
посетителей сайта.

Если доверяете мне то [вот сертификат моего УЦ](/files/root_ca.crt), а установка
такая же как сертификата Минцифры 🙂

Ну и совсем краткая инструкция как выпустить сертификат для себя:

1. `openssl genrsa -out root_ca.key 4096` — создание секретного ключа УЦ (должен
   храниться в безопасности!)
2. `openssl req -x509 -new -key root_ca.key -days 3650 -out root_ca.crt` —
   создаем сам сертификат УЦ (он НЕ секретный). Я указал срок действия 10 лет,
   но это потому что я ленивый и не хочу его перегенеривать каждый год. Так
   делать не советую.
3. `openssl genrsa -out server.key 4096` — создаем секретный ключ уже для
   конкретного сайта (и поддоменов)
4. `openssl req -new -key server.key -subj "/CN=neonxp.ru/CN=*.neonxp.ru" -out
   server.csr` — генерируем файл запроса для конкретного сайта
5. Создаем файл `openssl.cnf` с примерно таким содержимым:  
    ```
    [SAN]
    subjectAltName = @alt_names
    [alt_names]
    DNS.1 = neonxp.ru
    DNS.2 = *.neonxp.ru
    ```
6. И, наконец, создаем сертификат для сайта, который будет подписан ключами
   server.key и root\_ca.key (то есть и своим удостоверяющим центром тоже):
    ```
    openssl x509 -req -in server.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out server.crt -days 365 -extensions SAN -extfile openssl.cnf
    ```

В общем, всё. Полученные root_ca.crt (но не root_ca.key!), server.key и
server.crt можно вносить в конфигурацию используемого вебсервера. А так же
внести root_ca.crt в доверенные для себя.

Так у меня выглядят [сертификат на сайт](/img/posts/20230724_204209.webp) и
[сертификат УЦ](/img/posts/20230724_204325.webp).