Генератор самопідписаних сертифікатів для localhost і внутрішніх серверів

Онлайн-інструмент для створення самопідписаних сертифікатів для localhost, машини розробника або внутрішнього сервера. Може побудувати невеликий центр сертифікації та видати серверний сертифікат від нього — саме такий підхід справді прибирає попередження браузера: встановіть CA один раз, і всі наступні сертифікати прийматимуться автоматично. Все генерується у браузері через WebCrypto API.

Як користуватися

1
Оберіть режим

Локальний CA плюс сертифікат — те, що вам потрібно, якщо попередження браузера заважає. Один самопідписаний сертифікат підійде для швидкого тесту або API-клієнта, що пропускає перевірку.

2
Вкажіть імена

Усі хости та IP-адреси, які ви вводитимете в адресний рядок. localhost і 127.0.0.1 — різні імена, вказуйте обидва.

3
Встановіть CA

Тільки в режимі CA і тільки один раз на кожній машині. Інструкції для вашої платформи — під сертифікатом CA.

4
Налаштуйте сервер

Збережіть сертифікат і ключ, потім використайте сніпет для nginx або Apache під ними.

🔥 Зараз у тренді
🗣️ Текст у мовлення ✨ Покращення відео ✂️ Обрізати аудіо ✨ Підсилювач аудіо 🎭 Зміна голосу 🎙️ Видалення вокалу 🎬 Відео з аудіо 🎬 Обрізання відео

Згенеруйте HTTPS-сертифікат для локальної розробки в один клік

По одному на рядок. IP-адреси розпізнаються автоматично та потрапляють у SAN як IP-записи — саме так браузери приймають https://127.0.0.1.
Не знаєте, що спробувати?
700+ інструментів — відкрийте сюрприз
🎲 Здивуйте мене

Що вміє інструмент

Локальний CA, а не просто сертифікат
Окремий самопідписаний сертифікат потрібно довіряти кожному браузеру окремо, а Chrome узагалі прибрав цю можливість для localhost. Кореневий CA встановлюється один раз і охоплює всі наступні сертифікати — той самий підхід, що використовує mkcert.
Правильна обробка IP-адрес
Введіть 127.0.0.1 або ::1 — і вони потраплять у SAN як IP-запис, а не DNS-ім’я. Браузери вимагають саме такого розрізнення, і його відсутність — причина, чому https://127.0.0.1 продовжує не працювати навіть із сертифікатом, де ця адреса вказана.
Готова конфігурація сервера
Сніпети для nginx і Apache з потрібними директивами та іменами файлів, а також об’єднаний файл сертифіката в порядку, якого очікують ці сервери.
Інструкції для шести платформ
macOS, Windows, Linux, Firefox (зі своїм сховищем), Android (де CA користувача перестали застосовуватись до застосунків починаючи з версії 7) і Node.js/curl.
Зворотнє датування на годину
Сертифікат стає дійсним за годину до моменту створення — щоб машина з трохи відсталим годинником не відхилила щойно згенерований сертифікат.
ECDSA або RSA
За замовчуванням ECDSA P-256 для швидкого рукостискання; RSA 2048 або 4096 — коли щось у ланцюжку цього потребує.

Часті запитання

Навіщо будувати CA, якщо можна зробити один самопідписаний сертифікат?

Тому що окремий самопідписаний сертифікат потрібно довіряти на кожній машині, у кожному браузері, по одному — а Chrome прибрав можливість постійно довіряти такому сертифікату для localhost. Кореневий CA встановлюється один раз, і будь-який виданий від нього сертифікат одразу приймається, включно з сертифікатами для майбутніх проєктів. Той самий принцип лежить в основі mkcert.

Чи безпечно встановлювати CA на своїй машині?

Це реальний ризик, і він заслуговує чіткої відповіді: той, хто має приватний ключ CA, може видати сертифікат для будь-якого сайту, і машина, що довіряє цьому CA, прийме його. Оскільки ключ генерується у вашому браузері і лише ви маєте до нього доступ, ризик — у тому, що ключ може витекти. Зберігайте його на власній машині, не кладіть у спільні репозиторії й не встановлюйте CA на пристроях, які вам не належать. Якщо ключ таки потрапить до чужих рук — видаліть CA зі свого сховища довіри та згенеруйте новий.

Браузер усе одно показує попередження після встановлення CA.

Три поширені причини. Firefox має власне сховище сертифікатів і не використовує системне — імпортуйте CA туди окремо. Chrome і Safari кешують рішення щодо сертифікатів, тому повністю перезапустіть браузер. І сам сертифікат має містити точне ім’я, яке ви відкриваєте: localhost і 127.0.0.1 — різні записи, і сертифікат з лише одним із них буде відхилений для іншого.

Який термін дії обрати для сертифіката?

Для локальної розробки зручний стандартний термін — 825 днів. Зверніть увагу: macOS і iOS відхиляють будь-який сертифікат із терміном понад 825 днів, навіть самопідписаний, — тож більше значення зламає Safari на пристроях Apple. Сам CA видається на десять років, бо повторне встановлення кореневого сертифіката в кожному браузері — справа клопітка.

Чи підійде це для публічного сайту?

Ні, і нічого тут не вдієш. Відвідувачі не встановили ваш CA, тому їхні браузери покажуть повноекранне попередження. Публічному сайту потрібен сертифікат від загальновизнаного центру сертифікації — Let's Encrypt видає такі безкоштовно та поновлює автоматично.

💡 Хочете, щоб ми покращили цей інструмент спеціально для вас?

Звичайно! Просто надішліть нам коротке повідомлення з вашою ідеєю. Якщо хочете обговорити детальніше — залиште email, і ми зв’яжемося з вами. Можна залишитися анонімом.

Може сподобатися

⛓️ Виправлення ланцюжка сертифікатів 📝 Генератор CSR 📜 Декодер SSL-сертифікатів 🧰 Діагностика Let's Encrypt 🔗 Звірення ключа та сертифіката 🔄 Конвертер форматів сертифікатів 🔐 Перевірка SSL

Як ви оцінюєте цей інструмент?

Дякуємо за вашу оцінку!
Хочете розповісти більше? Залиште коментар!
Дякуємо! Ваш коментар з’явиться після модерації.
Для кого цей інструмент?
💻 Розробники та ІТ-спеціалісти 🔒 Безпека та приватність
Опубліковано Оновлено Автор: