Генератор самоподписанных сертификатов
Сертификат и его закрытый ключ для внутреннего сервиса — без заучивания заклинаний openssl: введите общее имя, перечислите каждое имя и IP, которые сертификат должен покрывать, выберите срок действия и размер ключа и скачайте оба PEM-файла. Ключи создаются локально в вашем браузере и никогда не загружаются на сервер — эта страница вообще не делает сетевых запросов, и ключ существует только в вашей вкладке, пока вы его не сохраните.
Большие ключи создаются медленнее: 4096 бит на скромной машине может занять некоторое время. Работа происходит на вашей машине, в этой вкладке — оставьте её открытой и дайте ей закончить.
Самоподписанный: субъект и издатель совпадают, поэтому за этим сертификатом не стоит никакой публичный орган. Браузеры будут предупреждать, пока он не будет добавлен в хранилище доверия машин, которые его используют.
- Покрываемые имена (SAN)
- Действителен с
- Действителен до
- Отпечаток SHA-256
Сертификат (PEM)
Закрытый ключ (PEM) — держите в секрете
Установите оба файла на сервер (сертификат и ключ как пару), ограничьте права на файл ключа служебной учётной записью и запишите дату истечения там, где вы её увидите, — тихо истёкший внутренний сертификат — классический сбой, устроенный собственными руками. Парсер сертификатов прочитает созданный сертификат обратно, если вы хотите перепроверить то, что развернули, а сопоставитель сертификата и ключа докажет, что скачанная пара принадлежит друг другу, — он группирует файлы по их общему открытому ключу, поэтому ключ, оставшийся от старой пары, не может незаметно проскользнуть в развёртывание.
Для чего нужен самоподписанный сертификат
Самоподписанный сертификат — это сертификат, у которого издатель и субъект совпадают: он ручается сам за себя. Это звучит как изъян, и для публичной сети это изъян — у браузера посетителя нет причин верить слову незнакомца. Но большая доля TLS никогда не встречается с публикой: внутренние панели, лабораторные и тестовые окружения, домашние лабораторные сервисы, интерфейсы администрирования сетевого оборудования и разговоры между сервисами внутри одной организации. Для них публика — это машины, которые вы контролируете, и у вопроса доверия есть другой ответ: вы устанавливаете сертификат (или свой собственный маленький CA) в хранилища доверия, которыми управляете, один раз, намеренно. Взамен вы получаете шифрование и идентичность внутри своих собственных стен, при том что публичный CA никогда не узнает ваши внутренние имена хостов — имена, которые сами по себе являются картой вашей инфраструктуры.
Ритуал создания раньше был командой openssl, которую никто не мог запомнить и все копировали и вставляли, а SAN прикручивались через файл конфигурации, потому что флага для них в старых версиях не существовало. Эта страница существует для того, чтобы форма сертификата была вместо этого видна: имена — это список, который вы можете прочитать, срок действия — это число дней, которое вы выбираете, зная, что он истечёт, а размер ключа — это решение, а не значение по умолчанию, которого вы никогда не замечали. Чего она намеренно не делает — не притворяется CA: нет цепочки, нет промежуточного звена, нечего отзывать. Один сервис, один сертификат, одна дата истечения, за которой нужно следить.
Как заставить клиентов его принимать
Создать сертификат — лёгкая половина; доверие — это развёртывание. На горстке ваших собственных машин добавление сертификата в хранилище доверия операционной системы (или браузера) навсегда прекращает предупреждения, а такие инструменты, как curl и git, принимают указатель --cacert для каждой команды вместо опасной привычки отключать проверку — флаг -k приучает всех игнорировать именно то предупреждение, которое поймало бы настоящую атаку. Когда публика вырастает за пределы горстки машин, переходите от одиночных самоподписанных сертификатов к маленькому частному CA: подписывайте им сервисные сертификаты, распространяйте только сертификат CA, и ротация перестаёт быть туром по каждому клиенту. А когда сервис всё же оказывается обращённым к публике, замените сертификат на публично доверенный — проверка SSL проверяет, что сервер на самом деле предъявляет, когда он уже работает, а это и есть момент, когда самоподписанный перестаёт быть выбором.
Связанные инструменты: прочитайте любой сертификат обратно с помощью парсера SSL-сертификатов или проверьте, что предъявляет живой сервер, с помощью проверки SSL.
Дополнительное чтение: одна рутина надёжности — почему внутренние сертификаты и даты их истечения принадлежат той же странице планирования, что ротации и резервные копии.
Создание сертификатов использует node-forge по лицензии BSD-3-Clause, загружается только при нажатии кнопки «Создать». Никакая часть этого инструмента не делает сетевых запросов.
Часто задаваемые вопросы
Где стоит использовать самоподписанный сертификат?
На вещах, с которыми разговариваете только вы и ваши собственные системы: внутренние панели, лабораторные и тестовые окружения, домашние лабораторные сервисы, страницы администрирования устройств и как заполнитель, который позволяет серверу стартовать до выпуска настоящего сертификата. Правило — охват: если браузер незнакомца когда-нибудь его увидит, ему вместо этого нужен публично доверенный сертификат — такие бесплатны в Let’s Encrypt.
Почему браузеры предупреждают о самоподписанных сертификатах?
Потому что «самоподписанный» означает, что единственный, кто ручается за сертификат, — он сам. Шифрование работает — соединение приватно, — но ничто не доказывает, что сервер — тот, за кого себя выдаёт, а это та половина TLS, которую обычно предоставляет центр сертификации. Поэтому браузеры предупреждают, пока сертификат (или CA, который вы контролируете) не будет добавлен в хранилище доверия машин, которые его используют.
Почему общее имя тоже появляется в списке SAN?
Современные браузеры полностью игнорируют поле общего имени и вместо этого проверяют список альтернативных имён субъекта. Сертификат, чьё главное имя отсутствует в его собственном списке SAN, терпит неудачу на том самом имени, для которого он был создан, — самая частая ошибка самоподписания, — поэтому эта страница всегда добавляет общее имя в SAN.
Достаточно ли RSA на 2048 бит, или стоит выбрать 4096?
RSA на 2048 бит — текущий базовый уровень, и для внутренних сервисов его достаточно; это то, что до сих пор использует большинство публичных сертификатов. 4096 бит покупают запас против будущего криптоанализа ценой более медленного создания и немного более медленных рукопожатий. Это имеет смысл для долгоживущего внутреннего CA или сервиса, который вы не можете легко перевыпустить. Создание в любом случае происходит на вашей собственной машине — 4096 бит может занять некоторое время, и вкладка работает, а не зависла.
Безопасно ли создавать закрытый ключ на веб-странице?
На этой странице — да, из-за того, как она построена: пара ключей создаётся локально в вашем браузере с помощью библиотеки node-forge, страница вообще не делает сетевых запросов, и ничто из созданного вами не загружается, не записывается в журнал и не хранится. Общая привычка всё равно стоит того: создавайте ключи только на страницах (и машинах), которым доверяете, и обращайтесь с файлом закрытого ключа как с секретом с того момента, как он существует.