📣 Приглашаю вас познакомиться с моими публикациями!

В портфолио на бирже копирайтинга вы найдете статьи различной тематики 📋 Все материалы доступны для покупки ✅  

➡️👉 Купить мои статьи на бирже ⬅️

Зеленый замок на localhost: создаем свой Certificate Authority для локальной разработки

Помню, как впервые столкнулся с этой проблемой. Разрабатываю новый проект, запускаю локально, открываю браузер - и вместо привычной работы вижу огромное красное предупреждение "Ваше подключение не защищено". Можно, конечно, каждый раз нажимать "Дополнительно" и "Все равно продолжить", но честно говоря, это начинает раздражать уже на второй день. А потом выясняется, что половина современных API просто отказывается работать без HTTPS. Service Workers? Нужен HTTPS. Геолокация? Только HTTPS. Secure cookies? Снова HTTPS. И тут я задался вопросом: неужели нет способа получить нормальный зеленый замок в адресной строке для локальной разработки?

Оказывается, решение существует, причем не одно. И сегодня я расскажу, как настроить локальный Certificate Authority так, чтобы браузер перестал ругаться, а вы могли спокойно разрабатывать в условиях, максимально приближенных к продакшену.

Почему самоподписанные сертификаты не работают как надо

Многие пробовали просто создать самоподписанный сертификат. Казалось бы, пара команд OpenSSL - и готово. Но браузер упорно показывает ошибку ERR_CERT_AUTHORITY_INVALID. В чем дело?

Вся суть в цепочке доверия. Когда вы открываете сайт с HTTPS, браузер проверяет сертификат, обращаясь к списку доверенных центров сертификации (Certificate Authorities). Эти корневые CA уже встроены в операционную систему и браузер. Когда вы создаете самоподписанный сертификат, вы подписываете его сами - без участия известного центра. Браузер не знает, кто вы такой, и не может проверить подлинность. Отсюда и все предупреждения.

Решение элегантно: создать собственный локальный CA и добавить его в список доверенных на вашей машине. После этого все сертификаты, выпущенные этим центром, автоматически станут доверенными для вашей системы. Никаких предупреждений, никаких исключений - чистая работа с зеленым замком.

Быстрый путь: инструмент mkcert для тех, кто ценит время

Если вам нужно настроить HTTPS за пять минут и не хочется погружаться в дебри OpenSSL, mkcert - ваш выбор. Этот инструмент автоматически создает локальный центр сертификации и устанавливает его во все нужные хранилища операционной системы. Работает на macOS, Linux и Windows, поддерживает даже Firefox с его отдельным хранилищем сертификатов.

Установка проста до неприличия. На macOS через Homebrew:

brew install mkcert
brew install nss  # для поддержки Firefox

На Linux сначала ставим библиотеки для Firefox, затем сам mkcert:

sudo apt install libnss3-tools
wget https://github.com/FiloSottile/mkcert/releases/download/v1.4.4/mkcert-v1.4.4-linux-amd64
sudo mv mkcert-v1.4.4-linux-amd64 /usr/local/bin/mkcert
sudo chmod +x /usr/local/bin/mkcert

В Windows используем Chocolatey или Scoop:

choco install mkcert

После установки запускаем магическую команду:

mkcert -install

Инструмент создает корневой центр сертификации (файлы rootCA.pem и rootCA-key.pem), добавляя его во все системные хранилища доверенных корней. Причем делает это не только для системы и Chrome/Edge, но и для Firefox, который использует собственную базу данных сертификатов NSS.

Теперь создание сертификата для любого домена занимает одну строку:

mkcert localhost 127.0.0.1 project.test api.localhost "*.dev.local"

Получаете два файла: сертификат (например, localhost+4.pem) и приватный ключ (localhost+4-key.pem). Настраиваете свой сервер на использование этих файлов - и все, зеленый замок появляется автоматически. Инструмент сам правильно настраивает Subject Alternative Names (SAN), о которых многие забывают при ручном создании, а современные браузеры их требуют обязательно.

Критически важный момент безопасности: файл rootCA-key.pem дает полную власть выпускать сертификаты от имени вашего локального CA. Если злоумышленник получит этот ключ, он сможет создавать доверенные сертификаты для любых доменов на вашей машине и перехватывать защищенный трафик. Поэтому никогда не делитесь этим файлом и храните его в безопасности.

Альтернатива для продвинутых: lcl.host с автоматизацией всего процесса

В марте 2024 года появился новый инструмент lcl.host от команды Anchor, который идет еще дальше mkcert. Это не просто генератор сертификатов - это полноценное решение для HTTPS в разработке с автоматическим обновлением сертификатов, поддержкой Docker, WSL и даже автоматической настройкой DNS.

Основное преимущество lcl.host перед mkcert - автоматическое управление жизненным циклом сертификатов. Вы не просто получаете сертификат один раз, система сама следит за их обновлением через протокол ACME (тот самый, который использует Let's Encrypt). Плюс все поддомены lcl.host автоматически резолвятся в 127.0.0.1, так что не нужно править /etc/hosts.

Установка на macOS:

brew install anchordotdev/tap/anchor

На Windows:

choco install anchor --version=0.0.22

Затем просто запускаем интерактивную настройку:

anchor lcl

Инструмент проведет через весь процесс: настроит trust stores, создаст личный CA в вашем аккаунте Anchor, выдаст сертификаты. Особенно удобно для команд - каждый разработчик может использовать общий CA, но приватные ключи остаются локальными.

Интересная особенность для Docker и WSL: lcl.host понимает, что в контейнерах и виртуальных машинах свои trust stores, отдельные от хост-системы. Поэтому на хосте вы запускаете anchor trust, чтобы браузеры доверяли сертификатам из контейнеров. Это решает частую проблему, когда сертификат работает внутри контейнера, но браузер на хосте ему не доверяет.

Путь для тех, кто хочет полного контроля: OpenSSL вручную

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

Начинаем с создания корневого CA. Генерируем зашифрованный приватный ключ:

openssl genrsa -aes256 -out myCA.key 4096

Используем 4096 бит для максимальной надежности и AES-256 для шифрования ключа. Выбирайте надежный пароль - он защитит ваш центр сертификации. Затем создаем корневой сертификат, действительный 10 лет:

openssl req -x509 -new -nodes -key myCA.key -sha256 -days 3650 -out myCA.pem

Система попросит ввести информацию об организации. Большинство полей можно заполнить произвольно, но Common Name стоит сделать узнаваемым - например, "My Local Development CA". Это поможет потом отличить ваш сертификат среди других в списке.

Теперь самое важное: добавить корневой сертификат в доверенные хранилища. Без этого шага браузер будет продолжать ругаться.

На macOS используем системную утилиту:

sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" myCA.pem

Или через GUI: открываем Keychain Access, импортируем myCA.pem, двойной клик по сертификату и устанавливаем "Always Trust".

На Linux копируем в системную директорию:

sudo cp myCA.pem /usr/local/share/ca-certificates/myCA.crt
sudo update-ca-certificates

В Windows открываем certmgr.msc, идем в "Trusted Root Certification Authorities" → "Certificates" и импортируем через "All Tasks" → "Import".

Firefox требует отдельного импорта: Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import.

После этого создаем сертификат для конкретного домена. Тут есть важный нюанс: современные браузеры требуют Subject Alternative Names. Простого Common Name уже недостаточно с 2017 года согласно RFC 2818. Создаем файл domains.ext:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost
DNS.2 = project.test
DNS.3 = *.dev.local
IP.1 = 127.0.0.1
IP.2 = ::1

Генерируем ключ для домена, создаем Certificate Signing Request и подписываем его нашим CA:

openssl genrsa -out project.test.key 2048
openssl req -new -key project.test.key -out project.test.csr -subj "/CN=project.test"
openssl x509 -req -in project.test.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial -out project.test.crt -days 825 -sha256 -extfile domains.ext

Обратите внимание на срок действия 825 дней - это максимум для совместимости с требованиями Apple. Компания ограничивает максимальный срок 398 днями для публичных CA, но для локальных можно чуть больше. Ставить 10 лет не стоит - могут быть проблемы на macOS и iOS.

Для энтузиастов автоматизации: Smallstep CA как полноценный ACME-сервер

Если вы хотите построить настоящую инфраструктуру управления сертификатами для разработки, Smallstep CA - это следующий уровень. Это полноценный Certificate Authority сервер с поддержкой ACME протокола, автоматическим обновлением сертификатов и множеством методов аутентификации.

Установка step CLI:

curl -sSL https://get.step.sm/install.sh | bash

Инициализация CA:

step ca init

Мастер установки спросит название вашего PKI, DNS-имя CA (например, ca.localhost), порт (по умолчанию 443, но для разработки удобнее 8443) и данные первого provisioner. После этого запускаем CA-сервер:

step-ca $(step path)/config/ca.json

Теперь можно получать сертификаты через ACME или другими способами. Например, через токен:

step ca certificate localhost localhost.crt localhost.key

Smallstep CA поддерживает не только обычные TLS-сертификаты, но и SSH-сертификаты для бесшовной авторизации между серверами. Можно настроить автоматическое обновление сертификатов каждые 24 часа - это приучает инфраструктуру к короткоживущим сертификатам, что повышает безопасность.

Для продвинутых сценариев Smallstep поддерживает интеграцию с OAuth провайдерами (Okta, Google, Azure AD), cloud instance identity documents для AWS/GCP/Azure, и даже single-sign-on для SSH через сертификаты вместо ключей.

Веб-серверы с автоматическим HTTPS: Caddy и Traefik

Иногда не хочется вообще заморачиваться с сертификатами вручную. Для таких случаев существуют веб-серверы со встроенной автоматизацией HTTPS.

Caddy - это веб-сервер на Go с автоматическим HTTPS из коробки. Для публичных доменов он получает сертификаты от Let's Encrypt, а для localhost и внутренних IP автоматически создает собственный локальный CA на базе библиотек Smallstep. Причем Caddy даже предложит установить корневой сертификат в системное хранилище при первом запуске.

Простейший Caddyfile для разработки:

localhost {
    reverse_proxy :3000
}

project.test {
    root * /var/www/project
    file_server
}

Запускаете caddy run - и все сайты автоматически работают по HTTPS с доверенными сертификатами. Caddy сам создаст CA, сгенерирует сертификаты, настроит редиректы с HTTP на HTTPS. Никаких конфигов OpenSSL, никаких ручных импортов в trust store.

Traefik - другой популярный выбор, особенно для Docker-окружений. Он умеет автоматически обнаруживать контейнеры и настраивать для них маршруты с HTTPS. Пример docker-compose.yml:

version: '3'
services:
  traefik:
    image: traefik:v2.10
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./traefik.yml:/etc/traefik/traefik.yml
  
  app:
    image: nginx
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.localhost`)"
      - "traefik.http.routers.app.tls=true"

Traefik автоматически выдаст сертификат для app.localhost через свой встроенный CA. Для продакшена можно настроить интеграцию с Let's Encrypt.

Интеграция с реальными проектами и фреймворками

Получить сертификаты - только половина дела. Нужно правильно настроить сервер разработки.

Для Nginx конфигурация стандартная:

server {
    listen 443 ssl http2;
    server_name project.test;
    
    ssl_certificate /path/to/project.test.crt;
    ssl_certificate_key /path/to/project.test.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    
    location / {
        root /var/www/project;
        index index.html;
    }
}

server {
    listen 80;
    server_name project.test;
    return 301 https://$server_name$request_uri;
}

Для Node.js создаем HTTPS-сервер:

const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('./project.test.key'),
  cert: fs.readFileSync('./project.test.crt')
};

https.createServer(options, app).listen(443);

В React и Vite есть плагин vite-plugin-mkcert, который автоматизирует весь процесс:

npm install -D vite-plugin-mkcert

import { defineConfig } from 'vite';
import mkcert from 'vite-plugin-mkcert';

export default defineConfig({
  plugins: [mkcert()],
  server: {
    https: true
  }
});

При первом запуске плагин автоматически создаст CA через mkcert, выдаст сертификат и настроит dev-сервер.

Для Docker монтируем сертификаты в контейнер. Пример docker-compose.yml:

version: '3'
services:
  nginx:
    image: nginx:latest
    ports:
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./certs:/etc/nginx/certs

Не забудьте добавить файлы сертификатов в .gitignore - приватные ключи не должны попадать в репозиторий.

Подводные камни и важные нюансы безопасности

Есть моменты, которые нужно знать заранее, чтобы избежать проблем.

RFC 2818 отменил использование Common Name для проверки имени хоста еще в 2000 году, сделав обязательным указание Subject Alternative Names. Если забудете добавить SAN, современные браузеры откажутся принимать сертификат, даже если он подписан доверенным CA.

Node.js не использует системное хранилище корневых сертификатов по умолчанию. Нужна дополнительная настройка через переменную окружения:

export NODE_EXTRA_CA_CERTS=/path/to/myCA.pem

Без этого приложения на Node.js, делающие HTTPS-запросы к вашим локальным сервисам, будут падать с ошибкой UNABLE_TO_VERIFY_LEAF_SIGNATURE.

Срок действия сертификатов имеет значение. Apple ограничивает максимальный срок 398 днями для сертификатов, выданных после 1 сентября 2020 года. Выпустите сертификат на 5 лет - получите проблемы на всех устройствах Apple.

Никогда, слышите, НИКОГДА не используйте локальный CA в продакшене. Это исключительно инструмент разработки. Для боевого окружения используйте Let's Encrypt или коммерческие центры сертификации. Локальный CA создан для того, чтобы только ваша машина доверяла сертификатам. Внешний мир их не примет, а если вы случайно скомпрометируете приватный ключ CA, последствия могут быть катастрофическими.

В командной разработке не делитесь приватным ключом CA между разработчиками. Каждый должен создать свой локальный CA. Если нужна синхронизация, используйте lcl.host или Smallstep с централизованным CA-сервером, но пусть каждый разработчик получает свои сертификаты индивидуально.

Работа с мобильными устройствами и тестирование

Часто нужно протестировать приложение на реальном смартфоне. Для этого создаем сертификат с IP-адресом вашей машины в локальной сети:

openssl req -x509 -newkey rsa:4096 -sha256 -days 365 \
  -nodes -keyout dev.key -out dev.crt \
  -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1,IP:192.168.0.100"

Замените 192.168.0.100 на ваш локальный IP. Затем экспортируйте корневой сертификат CA на телефон.

На Android копируем .crt файл на SD-карту, идем в Settings → Security & Location → Advanced → Encryption & Credentials → Install from SD Card. Выбираем сертификат, даем имя, указываем "VPN and Apps" для использования.

На iOS отправляем .pem файл по email себе, открываем на телефоне, iOS предложит установить профиль. После установки идем в Settings → General → About → Certificate Trust Settings и включаем доверие для нашего CA.

Теперь можно открыть https://192.168.0.100 на телефоне - и Service Workers заработают даже в локальной сети.

Удаление и очистка когда закончили

Если решите отказаться от локального CA, важно правильно его удалить. Оставлять неиспользуемые корневые сертификаты в системе небезопасно.

Для mkcert это одна команда:

mkcert -uninstall

Инструмент автоматически удалит корневой сертификат из всех хранилищ, которые он настраивал.

При ручной настройке через OpenSSL процесс сложнее. На macOS открываем Keychain Access, находим свой сертификат CA по имени (тому, что указывали в Common Name) и удаляем его.

В Linux:

sudo rm /usr/local/share/ca-certificates/myCA.crt
sudo update-ca-certificates --fresh

Windows: открываем certmgr.msc, идем в "Trusted Root Certification Authorities" → "Certificates", находим наш CA и удаляем через контекстное меню.

Firefox: Settings → Privacy & Security → Certificates → View Certificates → Authorities, находим наш CA и удаляем.

Я прошел все эти пути - от быстрого mkcert до детального ручного OpenSSL, попробовал lcl.host и даже поднял Smallstep CA для экспериментов. Для ежедневной работы выбрал mkcert: зачем тратить время на ручную настройку, когда можно автоматизировать? Две команды - и работаешь с нормальным HTTPS. Но понимание процесса, которое дает ручной подход через OpenSSL, бесценно. Когда что-то идет не так (а поверьте, оно идет), знание основ помогает быстро найти проблему вместо бесконечного копирования команд из интернета.

Выбирайте инструмент под свою задачу. Нужна скорость для личного проекта - mkcert. Работаете в команде - lcl.host с общим CA. Строите сложную инфраструктуру с микросервисами - Smallstep CA или Caddy. Хотите понять, как все устроено - OpenSSL вручную.

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

👉 Подписывайтесь на канал сайта в Telegram и YouTube