diff options
| author | 2026-02-02 00:35:54 +0300 | |
|---|---|---|
| committer | 2026-02-02 00:35:54 +0300 | |
| commit | bfdd73d7324a4f66a16f55d4fb064b0ff08d40e9 (patch) | |
| tree | 27fff9c802dcdd22960bb2e776e58278000d0364 /content/posts/2023-07-24-tls.md | |
| parent | Поправил шаблон (diff) | |
| download | blog-bfdd73d7324a4f66a16f55d4fb064b0ff08d40e9.tar.gz blog-bfdd73d7324a4f66a16f55d4fb064b0ff08d40e9.tar.bz2 blog-bfdd73d7324a4f66a16f55d4fb064b0ff08d40e9.tar.xz blog-bfdd73d7324a4f66a16f55d4fb064b0ff08d40e9.zip | |
Большая чистка блога
Diffstat (limited to 'content/posts/2023-07-24-tls.md')
| -rw-r--r-- | content/posts/2023-07-24-tls.md | 85 |
1 files changed, 0 insertions, 85 deletions
diff --git a/content/posts/2023-07-24-tls.md b/content/posts/2023-07-24-tls.md deleted file mode 100644 index 43ee345..0000000 --- a/content/posts/2023-07-24-tls.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -categories: -- Без рубрики -date: '2023-07-24T20:04:17Z' -tags: -- it -- Россия -- TLS -title: Немного мыслей о TLS (HTTPS) в России ---- - -Накопилось немного мыслей относительно того, что может грозить нам (и мне) в -связи с трендом на “балканизацию” рунета. - -И самое болезненное место — HTTPS который нынче стандарт де-факто в современных -интернетах. А болезненное оно потому, что целиком и полностью контролируется -другой стороной нынешного противостояния. Все доверенные удостоверяющие центры -принадлежат странам “коллективного запада”. Помню, были ещё какие-то китайские, -вроде, но с ними был какой-то скандал и не факт что они есть. - -Есть относительно [доверенный УЦ от Минцифры](https://www.gosuslugi.ru/tls). Это -здорово и я это всецело поддерживаю. Вот только есть момент. Он не для нас, -простых людей, и при попытке его получить видим то, что на скриншоте ниже. А -сранный Firefox вообще хочет его внести в черный список, чтобы даже специально -его нельзя было установить. В общем, пока его я поставить не могу даже при всём -желании. - -Какие ещё альтернативы есть, если нас вдруг прокинет 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).
\ No newline at end of file |
