Типи SSL-сертифікатів: який обрати для свого сайту

SSL-сертифікат — не універсальна річ «є або немає». Існує кілька типів, які відрізняються глибиною перевірки заявника, кількістю доменів під захистом і рівнем довіри, який вони демонструють відвідувачу сайту. У попередній статті про SSL ми розібрали, як шифрування працює технічно і навіщо воно взагалі потрібне. У цій статті — практичне питання, з яким рано чи пізно стикається кожен власник сайту: який саме тип сертифіката купити, щоб не переплатити за зайву перевірку і водночас не залишитись без потрібного рівня довіри там, де це справді важливо.

Три рівні перевірки: DV, OV, EV

Головна відмінність між типами SSL — не в силі шифрування (вона однакова для всіх типів і залежить від технічного протоколу, а не від рівня перевірки), а в тому, наскільки глибоко центр сертифікації перевіряє, хто саме подає заявку на сертифікат. Саме ця перевірка визначає, яку інформацію браузер і сам сертифікат «гарантують» відвідувачу сайту.

Domain Validation (DV) — базова перевірка домену

DV-сертифікат підтверджує лише одне: що заявник справді контролює домен, для якого запитується сертифікат. Перевірка автоматизована й займає від кількох хвилин до кількох годин. Центр сертифікації надсилає код підтвердження одним із трьох способів: на email за адресою на кшталт admin@domain.com чи webmaster@domain.com, через спеціальний DNS TXT-запис, доданий у налаштування домену, або через тимчасовий файл, розміщений у кореневій директорії сайту.

Це найпопулярніший тип сертифіката у світі — за оцінками CA/Browser Forum, DV-сертифікати складають понад 90% усіх виданих SSL-сертифікатів, тому що вони безкоштовні (Let’s Encrypt) або дуже дешеві, і видаються миттєво без людської участі в процесі перевірки.

Що бачить відвідувач: звичайний замок у адресному рядку браузера поруч з адресою сайту. Жодної додаткової інформації про юридичного власника сайту в самому сертифікаті немає — і це нормально для переважної більшості сайтів у інтернеті.

Organization Validation (OV) — перевірка організації

OV додає до автоматичної перевірки домену ручну перевірку: центр сертифікації звіряє назву компанії, юридичну адресу та сам факт існування організації через державні реєстри (в Україні для цього використовується ЄДРПОУ, за кордоном — відповідні національні реєстри компаній). Процес не автоматизований, тому видача займає від 1 до 3 робочих днів, а не хвилини, як у випадку з DV.

Що бачить відвідувач: у деталях сертифіката (не в самому адресному рядку — сучасні браузери прибрали видиму індикацію OV прямо з інтерфейсу ще кілька років тому) з’являється офіційна назва юридичної особи, яка володіє доменом. Дізнатись про це можна, натиснувши на іконку замка й переглянувши деталі сертифіката. Це має значення для B2B-сайтів і магазинів, де покупець теоретично може захотіти перевірити, з якою саме компанією він має справу, перш ніж вводити платіжні дані.

Extended Validation (EV) — розширена перевірка

Найглибший рівень перевірки: центр сертифікації перевіряє юридичний статус компанії, фізичну адресу, номер телефону (з обов’язковим дзвінком представнику компанії для підтвердження), право конкретної особи, що подає заявку, представляти організацію, а також відсутність компанії у списках відомих шахрайських доменів і санкційних списках. Видача займає від кількох днів до двох тижнів і коштує суттєво дорожче за DV чи OV.

Важливий нюанс станом на 2026 рік: раніше EV показував у браузері зелену адресну панель з назвою компанії просто у рядку адреси — це була головна причина його популярності серед банків і фінансових установ. Google Chrome прибрав цю візуальну індикацію ще у 2019 році, посилаючись на дослідження, які показали, що звичайні користувачі практично не звертають уваги на зелену панель і не використовують її для розпізнавання фішингових сайтів. Інші основні браузери — Firefox, Safari, Edge — поступово зробили те саме. Сьогодні EV-сертифікат технічно не виглядає інакше в адресному рядку браузера, ніж DV — уся різниця тепер лише в метаданих сертифіката, які пересічний відвідувач сайту ніколи не перевіряє вручну.

Це принципово важливо знати перед покупкою: платити за EV сьогодні варто радше заради внутрішнього комплаєнсу (наприклад, прямих вимог регулятора у фінансовому чи страховому секторі) чи корпоративної репутації, а не заради видимого браузерного індикатора, якого фактично більше не існує.

Хто видає сертифікати: центри сертифікації (CA)

Незалежно від типу — DV, OV чи EV — сертифікат завжди видає центр сертифікації (Certificate Authority, CA), організація, якій браузери й операційні системи довіряють за замовчуванням через попередньо встановлений список кореневих сертифікатів. Якщо CA не входить до цього довіреного списку, будь-який виданий ним сертифікат браузер трактуватиме як недовірений, незалежно від того, наскільки ретельно CA перевіряв заявника.

Let’s Encrypt

Некомерційний центр сертифікації, який видає виключно безкоштовні DV-сертифікати в автоматичному режимі. Саме Let’s Encrypt зробив HTTPS стандартом за замовчуванням для всього інтернету — до його запуску отримати SSL коштувало десятки доларів на рік навіть для найпростішого DV-рівня. Більшість сучасних хостинг-провайдерів, включно з Hostinger, інтегрують видачу сертифікатів Let’s Encrypt прямо в панель керування в один клік.

Комерційні CA: DigiCert, Sectigo, GlobalSign

Ці центри сертифікації видають повний спектр типів — DV, OV, EV, wildcard, multi-domain — за платними тарифами, часто з додатковими гарантіями (страхування на випадок фінансових втрат клієнта через компрометацію сертифіката) та розширеною технічною підтримкою. Більшість власників сайтів купують сертифікати цих CA не напряму, а через реселерів.

Реселери: Namecheap, GoDaddy та інші

Реселер — це компанія, яка перепродає сертифікати від великих CA (найчастіше Sectigo чи DigiCert) за нижчою ціною, ніж пряма покупка у самого CA, часто з додатковим зручним інтерфейсом керування. Namecheap — один із найпопулярніших реселерів SSL-сертифікатів завдяки прозорому ціноутворенню і партнерській програмі з комісією до 35% за продані сертифікати.

Wildcard, Multi-domain та Single-domain

Окрема, незалежна вісь вибору сертифіката — не глибина перевірки, а кількість доменів і піддоменів, які покриває один сертифікат.

Single-domain SSL

Захищає рівно один домен: наприклад, тільки example.com. Піддомени на кшталт blog.example.com чи shop.example.com сертифікат не покриває — для кожного окремого піддомену потрібен окремий сертифікат, якщо він не входить у той самий сертифікат як SAN-запис. Це найдешевший варіант, який підходить для сайту-візитки чи блогу без розгалуженої структури піддоменів.

Wildcard SSL

Покриває основний домен і необмежену кількість піддоменів першого рівня одним сертифікатом: example.com, blog.example.com, shop.example.com, mail.example.com — усе під символом *.example.com. Важливий технічний нюанс: wildcard покриває піддомени лише одного рівня вкладеності. Якщо потрібен захист ще й для sub.blog.example.com (тобто піддомену піддомену), звичайний wildcard-сертифікат його не покриє — знадобиться окремий, дорожчий продукт під назвою Multi-level Wildcard, який пропонують не всі центри сертифікації.

Wildcard коштує дорожче за single-domain сертифікат, але суттєво дешевше, ніж купувати окремий сертифікат на кожен піддомен окремо, якщо їх у проєкту три і більше.

Multi-domain SSL (SAN / UCC)

SAN (Subject Alternative Name), також відомий під назвою UCC (Unified Communications Certificate), покриває кілька повністю різних доменів одним сертифікатом: наприклад, example.com, example.net і example-shop.com одночасно, попри те, що ці домени можуть не мати нічого спільного між собою. Зазвичай ліміт становить від 100 до 250 доменів в одному сертифікаті залежно від конкретного CA. Це рішення насамперед для digital-агенцій, які керують сайтами кількох клієнтів, чи власників кількох незалежних проєктів, а не для одного сайту з розгалуженою структурою піддоменів.

Self-signed проти сертифікатів від CA

Self-signed сертифікат — той, що сайт чи сервер видає сам собі, без жодної участі зовнішнього центру сертифікації. Технічно він так само шифрує з’єднання, як і платний DV-сертифікат від визнаного CA — сам алгоритм шифрування ідентичний. Але є критична різниця: браузер не довіряє self-signed сертифікату, оскільки не може перевірити його в жодному довіреному ланцюжку кореневих сертифікатів, попередньо вбудованих в операційну систему чи сам браузер.

Результат — відвідувач бачить попередження на весь екран на кшталт «З’єднання не є приватним» або «Ваше з’єднання не захищене» замість звичного замочка в адресному рядку. Для публічного сайту, куди приходять реальні відвідувачі чи покупці, self-signed сертифікат — це фактично відмова від довіри користувачів; переважна більшість людей одразу закриє вкладку, побачивши таке застережне повідомлення, навіть не розібравшись, що саме воно означає.

Коли self-signed сертифікат доречний: внутрішні dev/staging-середовища для розробників, тестові сервери, локальна розробка на комп’ютері до публікації сайту, внутрішні API для комунікації між власними серверами компанії — усюди, де немає публічних відвідувачів і застережне повідомлення браузера нікого не бентежить, бо його бачать тільки технічні фахівці, які й так знають, що це тестове середовище.

Термін дії та автоматичне поновлення

Ще один параметр, який часто випускають з уваги при виборі сертифіката, — термін його дії та процес поновлення. Тут теж є суттєва різниця між безкоштовними та платними варіантами.

Сертифікати Let’s Encrypt діють лише 90 днів — це свідоме рішення організації, спрямоване на те, щоб заохотити автоматизацію процесу поновлення й мінімізувати шкоду у випадку компрометації приватного ключа. На практиці більшість хостинг-провайдерів і панелей керування (cPanel, hPanel) автоматично перевипускають такий сертифікат за кілька днів до завершення терміну дії, тому власнику сайту зазвичай взагалі не потрібно щось робити вручну.

Платні сертифікати від комерційних CA традиційно видавались на 1–2 роки, але тут відбуваються зміни: індустрійна коаліція CA/Browser Forum, до якої входять усі великі браузери й центри сертифікації, поступово скорочує максимальний дозволений термін дії будь-якого публічного SSL-сертифіката. Мета та сама, що й у Let’s Encrypt зі старту — швидша ротація сертифікатів зменшує вікно ризику у випадку витоку приватного ключа чи помилки самого CA. Практичний висновок для власника сайту: варто обирати хостинг і CA, які підтримують автоматичне поновлення сертифіката, а не покладатись на ручне відстеження дати закінчення дії — прострочений сертифікат означає миттєву появу застережень браузера для всіх відвідувачів.

Порівняльна таблиця всіх типів

Який тип для якого сайту

Кому підходить, а кому ні

Типові помилки при встановленні SSL

Навіть коли тип сертифіката обрано правильно, встановлення часто супроводжується технічними помилками, які варто знати заздалегідь.

Мішаний контент (mixed content). Якщо сторінка завантажується через HTTPS, але окремі елементи на ній (зображення, скрипти, стилі) досі підвантажуються за старими посиланнями через HTTP, браузер покаже попередження про небезпечний контент або взагалі заблокує такі елементи. Найчастіша причина — старі посилання на медіафайли в базі даних CMS, які залишились із часів, коли сайт ще не мав SSL.

Неповний ланцюжок сертифікатів (incomplete chain). Крім самого сертифіката домену, потрібно встановити й проміжний сертифікат (intermediate certificate), який зв’язує ваш сертифікат із кореневим сертифікатом CA. Пропуск цього кроку часто призводить до того, що сайт коректно відкривається в одних браузерах чи на комп’ютерах, але показує помилку на інших пристроях чи в мобільних застосунках, які по-різному кешують проміжні сертифікати.

Невідповідність домену в сертифікаті. Сертифікат, виданий для example.com, не покриє автоматично www.example.com, якщо це не було явно вказано під час генерації CSR-запиту як SAN-запис. Результат — попередження про невідповідність імені сайту для однієї з двох версій адреси.

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

Незакрите примусове перенаправлення на HTTPS. Навіть з коректно встановленим сертифікатом сайт може лишатись доступним і через звичайний HTTP, якщо не налаштоване примусове перенаправлення (redirect) з http:// на https://. Це не показує помилку відвідувачу напряму, але залишає незахищену версію сайту доступною і може негативно вплинути на SEO через дублювання контенту на двох версіях адреси.

Покрокова інструкція покупки та встановлення

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