Руководство on Михаил Мальчиков

Как получить OV-сертификат Минцифры для HTTPS в 2026 году

Wed, 02 Sep 2026 09:52:43 +0300

Введение

Однажды вечером я размышлял о цифровых угрозах в условиях текущей экономической блокады. Закрывают доступ ко всему подряд, и я задумался: а могут ли заблокировать Let’s Encrypt? У нас в компании на нём тысяча доменов. Даже vk.ru сейчас на Let’s Encrypt. Последние новости только подкрепили мои опасения: GlobalSign отозвал часть сертификатов. И какие альтернативы предоставляет нам вселенная? У нас же есть система сертификатов Минцифры.

Вечер был томным, всё нужное было под рукой, и я решил получить российские сертификаты для своего сайта. Сначала написал инструкцию для себя, а потом решил поделиться со всеми.

Получать сертификаты будем через Госуслуги — других вариантов я не нашёл. Я делал конфиг для своего сайта, вам, конечно же, нужно подставить свои данные. Часть команд я выполнял в Windows 11 PowerShell, часть — в WSL (Ubuntu) bash.

Госуслуги

Идем на Госуслуги, вбиваем в поиске “SSL-сертификат”, получаем тако диалог с Роботом Максом:

Я: SSL-сертификат

Робот Макс: Уточните свою роль при использовании сертификата безопасности

Я: Владелец сайта

Робот Макс: Вот что я могу предложить по сертификату безопасности для владельца сайта…

Я: Получение и виды сертификатов

Робот Макс: На Госуслугах можно получить сертификаты безопасности OV и DV с алгоритмом шифрования RSA или ГОСТ. Понадобится подтверждённая учётная запись

Различия сертификатов OV и DV (открывается модальное окно)

Как получить на Госуслугах

Подайте заявление на получение OV-сертификата. Сертификат в форматах cer и crt придёт в течение 3 рабочих дней в личный кабинет

Подайте заявление на получение DV-сертификата. Сертификат в форматах cer и crt придёт в течение 1 рабочего дня в личный кабинет

Услуга бесплатная

Госуслуги выдают два вида сертификатов: OV (Organization Validation) и DV (Domain Validation).

Характеристики OV-сертификата:

Подтверждает, что вы владеете и управляете указанным в сертификате доменом, а передача данных пользователей защищена

Защищает несколько доменов

Действует 365 дней с даты выдачи

Доступен гражданам РФ, организациям и ИП

Характеристики DV-сертификата:

Подтверждает, что вы управляете указанным в сертификате доменом, а передача данных пользователей защищена

Защищает один домен

Действует 90 дней с даты выдачи

Доступен гражданам РФ, иностранцам, организациям и ИП

В природе существует ещё и EV (Extended Validation), но это уже другая история.

Я выбираю OV. Далее на выбор дают два варианта: RSA и ГОСТ. Я посчитал, что использование сертификатов Минцифры уже достаточно патриотично, поэтому выбрал RSA.

Ссылка на официальную инструкцию: Создание гражданином запроса на выпуск OV-сертификата с алгоритмом шифрования RSA.

CSR (Certificate Signing Request)

Создаём файл malchikovma.ru.conf, заполняем по образцу секции req_distinguished_name и subjectAltName. Я заказывал сертификат сразу для основного домена и его поддоменов, поэтому в subjectAltName указал сразу две записи.

openssl_conf = openssl_init

[ openssl_init ]
stbl_section = stable_section

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
x509_extensions = v3_req
prompt = no
string_mask = utf8only
utf8 = yes

[ req_distinguished_name ]
CN = malchikovma.ru
SN = Мальчиков
GN = Михаил Александрович
C = RU
SNILS = 12345678901
INN = 123456789012

[ v3_req ]
keyUsage = digitalSignature, keyEncipherment, keyAgreement
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:malchikovma.ru, DNS:*.malchikovma.ru

[ stable_section ]
SNILS = min:11,max:11,mask:NUMERICSTRING,flags:nomask
INN = min:12,max:12,mask:NUMERICSTRING,flags:nomask

Что интересно, в зарубежных примерах обычно указывают параметры “ST = California, L = San Francisco, O = My Company Inc”, а у нас, по классике, нужно указать СНИЛС и ИНН.

Сгенерируем CSR (Certificate Signing Request) на основе конфига:

openssl req -out malchikovma.ru.csr -new -newkey rsa:2048 -nodes -keyout privkey.pem -config malchikovma.ru.conf

На выходе получим файлы malchikovma.ru.csr и privkey.pem.

Опционально, проверим валидность:

openssl req -in malchikovma.ru.csr -noout -text -nameopt utf8 -config malchikovma.ru.conf

Регистратор доменных имен

Далее, нужно подтвердить, что мы владеем доменом. Подтверждение через DNS или файл на сервере? Это все - прошлый век. Идем к своему регистратору имен (у меня это - рег.ру.), покупаем свидетельство о регистрации домена. На момент написания стоимость - 203 рубля.

Далее нам понадобится УКЭП, мы же делаем OV-сертификат. Как у организации, у нас конечно же, должна быть УКЭП. Если у нас ее нет, то ищем удостоверяющий центр поблизости, бронируем время и идем покупать токен примерно за 3 т.р. Я покупал у Тензора, просто потому, что он ближе.

Теперь нужно подписать файл malchikovma.ru.conf и свидетельство о регистрации домена, т.е. создать файлы .sig с помощью УКЭП из любой сторонней программы. Если у вас оплачен КриптоПРО, то можно им, лично я использовал КриптоАРМ.

Снова Госуслуги, DNS

Отправляем все это на госуслуги. Нас просят подтвердить владение доменом еще через DNS (официального документа с подписью недостаточно). Добавляем требуемую TXT запись. Госуслуги требуют по 1 TXT записи на каждый домен, но меня пропустил с 1 записью. Идем спать. На следующий день получаем сертификаты.

Что имеем в архиве?

certificate.cer
certificate.cer.sig
certificate.crt
certificate.crt.sig

Файлы .sig - это подписи, нас сейчас не интересуют. Мы имеем два сертификата, certificate.cer и certificate.crt. Сравнение показывает, что это одинаковые файлы. Зачем? Непонятно.

Подготовка сертификатов

Сертификаты нам предоставляют в бинарном виде (DER), а веб-серверу нужны в текстовом (PEM). Преобразуем DER в PEM:

openssl x509 -inform der -in certificate.crt -out malchikovma.ru.crt

На выходе получаем файл malchikovma.ru.crt.

Но это конечные сертификаты, а для HTTPS нам нужна полная цепочка. Скачиваем корневой и промежуточный (выпускающий) сертификат Минцифры.. Находим среди них те, что в текстовом формате:

для корневого сертификата - russian_trusted_root_ca_pem.crt,
для промежуточного - russian_trusted_sub_ca_pem.crt.

Объединяем сертификаты в цепочку:

cat gosuslugi-malchikovma.ru/malchikovma.ru.crt \
russian_trusted_sub_ca_pem/russian_trusted_sub_ca_pem.crt \
linux_russian_trusted_root_ca_pem/russian_trusted_root_ca_pem.crt > fullchain.crt

Загружаем цепочку сертификатов и приватный ключ, созданный на первом шаге, на сервер. Еще я переименовал crt в pem, чтобы сразу понимать формат.

# /etc/ssl/mincifry/malchikovma.ru
ls -la
# drwxr-xr-x 2 root root 4096 Jul 31 12:17 .
# drwxr-xr-x 3 root root 4096 Jul 31 12:15 ..
# -rw-r--r-- 1 root root 7592 Jul 31 12:17 fullchain.pem
# -rw------- 1 root root 1704 Jul 31 12:17 privkey.pem

Веб-сервер

Указываем на веб-сервере, какие нужно использовать сертификаты. У меня это Nginx:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name malchikovma.ru www.malchikovma.ru;

    ssl_certificate /etc/ssl/mincifry/malchikovma.ru/fullchain.pem;
    ssl_certificate_key /etc/ssl/mincifry/malchikovma.ru/privkey.pem;

    # Рекомендуемые базовые настройки безопасности SSL
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers HIGH:!aNULL:!MD5;
}

Перезагружаем его. Сайт теперь открывается по HTTPS.

Поздравляю! У вас все получилось.

Заключение

После этой незамысловатой процедуры, следующие 365 дней наш сайт будет доступен по HTTPS. А сертификаты подтверждены самим Министерством цифрового развития, связи и массовых коммуникаций Россиийской Федерфции. Но это при условии, что у вас на компьютере установлены их корневые сертификаты. Не будем здесь рассуждать, их наличие - это хорошо или плохо. На хабре в последнее время и так полно постов на эту тему. Мне же, как ИП с УКЭП, они необходимы. А еще, на днях без них перестал открываться Сбербанк. Мы же с вами прошли путем исследователя, которому интересно, как устроен процесс получения.

А теперь серьезно. Этот процесс ужасно медленный и трудоемкий. Сертификат Let’s Encrypt можно получить за пару минут и несколько команд в терминале. Да, я получал OV сертификат, это чуть более ответственная вещь, чем DV. Но для DV сертификата похожая история. Если кто-то из Минцифры читает это, пожалуйста, сделайте инструменты для автоматизации. ACME протокол это позволяет.

Как хостить сайт на GitHub с Hugo

Thu, 17 Oct 2024 16:33:17 +0300

Введение

GitHub позволяет использовать репозиторий как статический веб-сайт. Существует генератор статических сайтов Hugo. Так почему бы не подружить эти инструменты?

GitHub из коробки работает с Jekyll, но я уже потратил вечер на изучение Hugo, и он мне понравился.

Для этого нам понадобится знание Git, Markdown и YAML. А при работе с репозиторием по ssh, еще и умение работать с ключами шифрования на базовом уровне.

Описываю свой опыт, так что все упоминания malchikovma осознанно заменяем на свои собственные. Все происходит на Ubuntu Linux, но на Mac и Windows процесс должен быть примерно таким же.

Создаем сайт на github.io

Для начала создадим простой сайт из репозитория. GitHub выпустил красивую инструкцию на эту тему (pages.github.com). Я следовал ей, но встретил несколько проблем. Как их решить, описываю далее.

Создаем репозиторий в GitHub с именем malchikovma.github.io.

Копируем его локально:

git clone git@github.com:malchikovma/malchikovma.github.io.git malchikovma.ru

Название директории я выбрал “malchikovma.ru” по названию своего домена. Можно указать любое другое: site, blog, etc.

Если возникла проблема с доступом, можно настроить ssh-ключ и указать его в настройках GitHub. Есть официальная инструкция, но на данный момент она не переведена на русский язык: “Создание нового ключа SSH и его добавление в ssh-agent”. Кратко опишу процесс:

Выполняем команду ssh-keygen -t ed25519 -C "malchikovma@gmail.com". В процессе указываем название файла: github_personal_ed25519. Пароль можно не указывать. В результате в директории ~/.ssh получим два файла: github_personal_ed25519 и github_personal_ed25519.pub.
Выполняем команду ssh-add ~/.ssh/github_personal_ed25519. В дальнейшем это позволит не указывать файл ключа вручную.
Добавляем содержимое файла github_personal_ed25519.pub в настройки профиля GitHub: Settings, SSH and GPG keys, New SSH key.

После этого проблема с доступами должна исчезнуть. Альтернативно, можно использовать протокол https, но тогда GitHub будет спрашивать каждый раз логин и пароль. Подробнее: Сведения об удаленных репозиториях.

git clone https://github.com/malchikovma/malchikovma.github.io.git malchikovma.ru

Переходим в свежесозданную директорию, открываем ~~Vim~~ свой любимый редактор и создаем файл index.html с содержимым “Hello GitHub Pages!”.

Публикуем изменения, и в течение минуты наше приветствие будет доступно по адресу malchikovma.github.io.

git add .
git commit -m 'Initial commit'
git push -u origin main

При коммите Git может запросить ваши данные. Указываем их:

git config user.email 'malchikovma@gmail.com'
git config user.name 'Mikhail Malchikov'

Если все получилось, идем дальше.

Настройка Hugo

Установка

Устанавливаем Hugo. На Ubuntu Linux это делается командой sudo apt install hugo. Для других систем смотрим официальное руководство: Hugo - Installation.

Hugo не может создать новый сайт в уже существующей директории, поэтому создаем его рядом, затем перемещаем в созданный ранее репозиторий.

hugo new site malchikovma.ru.bak
cp malchikovma.ru.bak/* malchikovma.ru/

Официальное руководство Hugo - Quick Start несколько отличается от нашего процесса. В частности тем, что там не учитывается интеграция с GitHub.

Hugo использует систему модулей git. Устанавливаем ~~первую приглянувшуюся~~ тему Stack и указываем в конфиге, что используем ее:

git submodule add https://github.com/CaiJimmy/hugo-theme-stack.git themes/stack
echo "theme = 'stack'" >> hugo.toml

Запускаем локальный сервер: hugo server --buildDrafts. Сайт будет доступен по адресу http://localhost:1313/. Он нужен для локальной разработки: посмотреть, как выглядит страница перед публикацией. Hugo использует hot reload, при изменении файлов они автоматически перезагружаются в браузере. Иногда это не помогает и нужно ~~пнуть~~ перезапустить сервер Hugo.

На данном этапе мы должны получить рабочий сайт без контента.

Пишем первый пост

Чтобы создать первый пост, используем команду hugo new content content/post/my-first-post.md. Она создаст файл по указанному пути. Можно создать его и вручную, но команда имеет преимущество: она создаст так называемый front matter: метаданные о публикации в формате TOML. Front matter этой статьи:

+++
title = 'Как хостить сайт на GitHub с Hugo'
date = 2024-10-18T16:33:17+03:00
draft = false
image = 'hugo-logo.webp'
+++

Текст статьи...

Открываем файл в ~~Vim~~ ¹ своем любимом редакторе. Пишем текст в формате Markdown. При сохранении, изменения должны отразиться на сайте.

На этом знакомство с Hugo окончено. Как дальше можно изменить внешний вид сайта пишет автор нашей темы: stack.jimmycai.com.

Одно последнее напутствие: конвертируем формат конфигурации из TOML в YAML. TOML - прекрасный формат, но плохо подходит для вложенных структур, таких как меню и виджеты. Соответственно, меняем расширение файла с .toml на .yaml. Hugo сам поймет, что формат изменился.

Публикация на GitHub

Теперь, при отправке изменений в GitHub, мы не увидим наш прекрасный новый сайт. Дело в том, что GitHub по умолчанию берет содержимое корневой директории, а Hugo публикует результат в директорию public.

Как вариант, в конфигурации Hugo можно указать, чтоб сайт создавался в директории docs: publishdir: docs. В настройках репозитория GitHub также указываем, публиковать директорию docs.

Можно использовать репозиторий в таком виде, а можно генерировать сайт на стороне GitHub через Actions.

GitHub Actions

При детальном рассмотрении, видим, что GitHub использует пайплайн сборки Jekyll для нашего сайта. Даже если мы этого не хотим. Зачем разворачивать образ операционной системы и устанавливать кучу программ, просто чтоб загрузить куда-то HTML файлы? Звучит как полный оверинжиниринг. Но что поделать: используем или дефолтный, или свой.

Сообщество Hugo предоставляет нам готовый скрипт по сборке сайта в GitHub Pages. Директории public и resources/_gen теперь можно не отслеживать и добавить в .gitignore, они нам не понадобятся для публикации.

Создаем файл .github/workflows/hugo.yaml и копируем в него содержимое:

# Sample workflow for building and deploying a Hugo site to GitHub Pages
name: Deploy Hugo site to Pages

on:
  # Runs on pushes targeting the default branch
  push:
    branches:
      - main

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

# Default to bash
defaults:
  run:
    shell: bash

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    env:
      HUGO_VERSION: 0.134.2
    steps:
      - name: Install Hugo CLI
        run: |
          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
          && sudo dpkg -i ${{ runner.temp }}/hugo.deb
      - name: Install Dart Sass
        run: sudo snap install dart-sass
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: recursive
          fetch-depth: 0
      - name: Setup Pages
        id: pages
        uses: actions/configure-pages@v5
      - name: Install Node.js dependencies
        run: "[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true"
      - name: Build with Hugo
        env:
          HUGO_CACHEDIR: ${{ runner.temp }}/hugo_cache
          HUGO_ENVIRONMENT: production
          TZ: America/Los_Angeles
        run: |
          hugo \
            --gc \
            --minify \
            --baseURL "${{ steps.pages.outputs.base_url }}/"
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./public

  # Deployment job
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

Зачем тратить минуту на установку зависимостей при каждой публикации? Можно загрузить уже готовые файлы за секунду. Я попытался удалить шаги сборки из пайплайна и генерировать сайт локально, но тщетно.

В настройках репозитория Pages указываем: использовать для сборки не бранч, а Action. Теперь при пуше в Github, он сам будет создавать директорию public и отправлять ее в сервис Pages.

Свой домен

GitHub бесплатно предоставляет нам свой субдомен с именем пользователя: malchikovma.github.io. Но что, если мы хотим иметь свой, да еще и с сертификатом? У нас есть такая возможность. Для этого нужно приобрести желаемый домен (я это сделал на рег.ру). В панели управления, в разделе “DNS-серверы и управление зоной” указываем следующие значения:

Тип записи	Префикс	Значение
A	@	185.199.108.153
A	@	185.199.109.153
A	@	185.199.110.153
A	@	185.199.111.153
CNAME	www	malchikovma.github.io

Это - IP-адресы GitHub Pages. Предполагаю, что 4 адреса требуются для распределения нагрузки по 4 серверам, а www-запись нужна для получения сертификата Let’s Encrypt ². “@” означает сам наш домен (malchikovma.ru), а www - его субдомен (www.malchikovma.ru).

После этого, на странице настроек Pages, в разделе “Custom domain” указываем наш домен. После проверки DNS, можно указать “Enforce HTTPS”. Теперь наш сайт доступен по адресу malchikovma.ru.

Заключение

У меня давно было желание создать свой сайт, но всегда отталкивали цены на хостинг, постоянные проблемы с CMS ~~и отсутствие идей~~. С SSG и GitHub Pages звезды сошлись.

В статическом контенте масса преимуществ. HTML-страницы открываются мгновенно, практически не требуют серверных мощностей. Появляется возможность кэшировть ответы без лишних усилий. Нет необходимости настраивать и поддерживать CSM, базу данных, PHP, веб-сервер. Файлы занимают минимум места на диске: только сами статьи и материалы к ним. Можно использовать бесплатные хостинги, такие как GitHub Pages. Использование своего домена позволяет “переехать” на другой хостинг в любой момент.

Но негативные моменты тоже есть: мы лишаемся динамического контента, а порог входа слишком велик. Для человека, не занимающегося разработкой ПО, генератор статических сайтов вряд ли подойдет. Слишком многое нужно изучить: Bash, Git, YAML, Markdown. Гораздо проще взять пресловутый WordPress и работать через графический интерфейс. Но если так получилось, что у вас уже есть такой “багаж” знаний, то почему бы не воспользоваться им.

Это скорее шутка, так как Vim известен своей недружелюбностью. Этот пост я пишу в Gnome Text Editor. ↩︎
Подобную систему мы использовали в для пользовательских доменов в собственном конструкторе сайтов. ↩︎