Як встановити SSL сертифікат на домен

Сертифікат SSL (Secure Sockets Layer / TLS) — це криптографічний обліковий запис, виданий довіреним центром сертифікації (CA), який підтверджує ідентичність вашого сервера та встановлює зашифрований канал між сервером і браузером клієнта. При правильному встановленні він переводить ваш сайт з http:// на https://, активує замок у браузері та запобігає перехопленню переданих даних атаками типу «людина посередині».

Для SEO Google розглядає HTTPS як підтверджений сигнал ранжування з 2014 року. Для користувачів відсутній або неправильно налаштований сертифікат викликає попередження безпеки в браузері, що знищує показники конверсії. Незалежно від того, чи керуєте ви однією цільовою сторінкою чи багатодоменною інфраструктурою, правильне налаштування SSL — і підтримання його в належному стані — є обов’язковим.

Передумови перед початком роботи

Перш ніж торкатися будь-якого конфігураційного файлу, переконайтеся, що у вас є наступне:

• Зареєстроване доменне ім’я, що вказує на IP-адресу вашого сервера з повністю поширеним DNS. Ви можете зареєструвати або перенести домен через Реєстрацію доменів.
• Пакет SSL-сертифіката від CA. Зазвичай він включає:

certificate.crt — ваш основний підписаний сертифікат
private.key — приватний ключ, згенерований разом із вашим CSR
ca_bundle.crt — проміжний ланцюжок CA (іноді називається файлом ланцюжка)
Доступ до сервера або панелі керування — облікові дані cPanel/Plesk або SSH root/sudo доступ до сервера.
Програмне забезпечення веб-сервера — Apache або Nginx, запущений і налаштований для вашого домену.
Відкритий порт 443 — переконайтеся, що ваш брандмауер дозволяє вхідний TCP на порту 443 перед встановленням будь-чого.

Якщо ви використовуєте середовище VPS Хостингу, у вас буде повний root-доступ і ви зможете використовувати будь-який із трьох методів нижче. Користувачі спільного хостингу, як правило, обмежені методом cPanel.
Вибір правильного типу SSL-сертифіката
Не всі сертифікати є рівнозначними. Вибір неправильного типу марнує гроші або залишає прогалини в покритті.



Тип сертифіката
Рівень перевірки
Час видачі
Замок у браузері
Найкраще для








—
—
—
—
—








DV (Domain Validated)
Лише контроль домену
Хвилини
Так
Блоги, середовища розробки, невеликі сайти








OV (Organization Validated)
Домен + ідентичність організації
1–3 дні
Так
Бізнес-сайти, SaaS-платформи








EV (Extended Validation)
Повна перевірка юридичної особи
3–7 днів
Так (назва організації в деяких браузерах)
Електронна комерція, банківська справа, портали з високим рівнем довіри








Wildcard (`*.domain.com`)
DV або OV
Хвилини–дні
Так
Розгортання з кількома субдоменами








Multi-Domain (SAN)
DV, OV або EV
Варіюється
Так
Кілька різних доменів на одному сертифікаті








Let’s Encrypt (безкоштовний DV)
Лише контроль домену
Секунди
Так
Будь-який публічно доступний домен





Для виробничої електронної комерції або будь-якого сайту, що обробляє дані платіжних карток, настійно рекомендуються сертифікати OV або EV від комерційного CA. Сертифікати Let’s Encrypt DV є повністю довіреними та відмінно підходять для більшості випадків використання, але вони не включають перевірку ідентичності організації.
Ви можете придбати комерційні сертифікати безпосередньо через SSL-сертифікати, якщо вам потрібне покриття OV, EV або Wildcard з виділеною підтримкою.
Метод 1: Встановлення SSL-сертифіката через cPanel
Графічний інтерфейс cPanel є найшвидшим шляхом для користувачів на керованих або планах спільного веб-хостингу. Якщо ви надаєте перевагу середовищу VPS під керуванням cPanel, VPS з cPanel надає вам той самий інтерфейс з повним контролем над сервером.
Крок 1: Увійдіть до cPanel
Перейдіть до URL-адреси входу в cPanel:
https://yourdomain.com:2083
Автентифікуйтеся за допомогою облікових даних хостингу.
Крок 2: Перейдіть до менеджера SSL/TLS
У розділі Безпека панелі керування cPanel натисніть SSL/TLS. Потім виберіть Manage SSL Sites під заголовком «Install and Manage SSL for your site (HTTPS)».
Крок 3: Виберіть цільовий домен
Використовуйте випадаючий список Domain, щоб вибрати домен, який ви хочете захистити. Якщо домен не відображається, переконайтеся, що він доданий як додатковий або основний домен у cPanel.
Крок 4: Вставте компоненти сертифіката
Відкрийте кожен файл сертифіката у звичайному текстовому редакторі (не Word) і вставте вміст у відповідні поля:

Certificate (CRT): Вміст certificate.crt

Крок 5: Встановіть і перевірте

Натисніть Install Certificate. cPanel перевіряє пару ключ-сертифікат перед підтвердженням. Якщо є невідповідність між приватним ключем і публічним ключем сертифіката, cPanel відхилить встановлення з явною помилкою — не ігноруйте її.

Після встановлення відвідайте https://yourdomain.com і переконайтеся, що замок відображається. Також перевірте https://www.yourdomain.com, якщо субдомен www використовується.

Поширена пастка cPanel: AutoSSL (вбудована інтеграція Let’s Encrypt у cPanel) може перезаписати вручну встановлений сертифікат під час наступного циклу оновлення. Якщо ви встановили комерційний сертифікат, вимкніть AutoSSL для цього домену в розділі cPanel > SSL/TLS Status, щоб запобігти ненавмисній заміні.

Метод 2: Автоматичне встановлення за допомогою Let’s Encrypt і Certbot

Certbot є еталонним ACME-клієнтом для Let’s Encrypt. Він обробляє генерацію CSR, перевірку домену, отримання сертифіката, налаштування веб-сервера та оновлення — все автоматично. Це правильний підхід для будь-якого Linux-сервера, яким ви керуєте безпосередньо.

Крок 1: Підключіться до вашого сервера через SSH

ssh username@your-server-ip

Крок 2: Встановіть Certbot

Debian / Ubuntu (Apache):

sudo apt update && sudo apt install -y certbot python3-certbot-apache

Debian / Ubuntu (Nginx):

sudo apt update && sudo apt install -y certbot python3-certbot-nginx

RHEL / AlmaLinux / Rocky Linux (Apache):

sudo dnf install -y epel-release
sudo dnf install -y certbot python3-certbot-apache

RHEL / AlmaLinux / Rocky Linux (Nginx):

sudo dnf install -y epel-release
sudo dnf install -y certbot python3-certbot-nginx

Крок 3: Отримайте та встановіть сертифікат

Для Apache:

sudo certbot --apache -d yourdomain.com -d www.yourdomain.com

Для Nginx:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot за замовчуванням виконує HTTP-01 challenge: він розміщує тимчасовий файл у кореневій директорії вашого веб-сервера та просить сервери Let’s Encrypt отримати його через порт 80. Це означає, що порт 80 має бути відкритий, а ваш DNS має правильно розпізнаватися перед запуском команди.

При появі запиту виберіть опцію перенаправити весь HTTP-трафік на HTTPS. Це записує постійне перенаправлення 301 у конфігурацію вашого сервера, що є правильною поведінкою для SEO та безпеки.

Крок 4: Перевірте автоматичне оновлення

Сертифікати Let’s Encrypt закінчуються через 90 днів. Certbot встановлює таймер systemd (або завдання cron на старих системах), який намагається оновити сертифікат двічі на день, коли до закінчення терміну дії залишається 30 днів. Перевірте логіку оновлення без фактичного оновлення:

sudo certbot renew --dry-run

Успішний пробний запуск підтверджує, що конвеєр оновлення працює. Перевірте статус таймера за допомогою:

systemctl status certbot.timer

Крайній випадок — DNS-01 challenge для wildcard-сертифікатів: HTTP-01 challenge не може перевірити wildcard-домени (*.yourdomain.com). Для wildcard використовуйте DNS-01 challenge, який вимагає від вас створення TXT-запису _acme-challenge у вашій DNS-зоні:

sudo certbot certonly --manual --preferred-challenges dns -d "*.yourdomain.com" -d yourdomain.com

Дотримуйтесь підказок для додавання TXT-запису, зачекайте на поширення DNS, потім натисніть Enter для завершення перевірки.

Метод 3: Ручне встановлення SSL через SSH (Apache та Nginx)

Ручне встановлення дає вам точний контроль над розміщенням сертифікатів, наборами шифрів і конфігурацією віртуальних хостів. Це кращий підхід для виробничих серверів, де вам потрібно застосовувати конкретні політики TLS.

Крок 1: Завантажте файли сертифіката на сервер

Використовуйте scp для передачі файлів з вашої локальної машини:

scp certificate.crt private.key ca_bundle.crt username@your-server-ip:/tmp/

Потім перемістіть їх до безпечної директорії, недоступної через веб:

sudo mkdir -p /etc/ssl/yourdomain
sudo mv /tmp/certificate.crt /etc/ssl/yourdomain/
sudo mv /tmp/private.key /etc/ssl/yourdomain/
sudo mv /tmp/ca_bundle.crt /etc/ssl/yourdomain/
sudo chmod 600 /etc/ssl/yourdomain/private.key
sudo chmod 644 /etc/ssl/yourdomain/certificate.crt /etc/ssl/yourdomain/ca_bundle.crt

Критична примітка щодо безпеки: Приватний ключ ніколи не повинен бути доступний для читання всім. Дозвіл chmod 600 обмежує доступ лише для користувача root. На системах, де Apache або Nginx працює як не-root користувач (наприклад, www-data), служба все одно читає ключ під час запуску, поки працює як root перед зниженням привілеїв — тому 600 у власності root є правильним.

Крок 2a: Налаштуйте Apache

Відредагуйте конфігурацію віртуального хоста для вашого домену:

sudo nano /etc/apache2/sites-available/yourdomain.com.conf

Додайте або змініть блок SSL віртуального хоста:

<VirtualHost *:80>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    Redirect permanent / https://yourdomain.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com

    SSLEngine on
    SSLCertificateFile      /etc/ssl/yourdomain/certificate.crt
    SSLCertificateKeyFile   /etc/ssl/yourdomain/private.key
    SSLCertificateChainFile /etc/ssl/yourdomain/ca_bundle.crt

    # Modern TLS hardening
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder     off
    SSLSessionTickets       off

    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

    DocumentRoot /var/www/yourdomain
</VirtualHost>

Увімкніть модуль SSL і сайт, потім перезапустіть Apache:

sudo a2enmod ssl headers
sudo a2ensite yourdomain.com.conf
sudo apache2ctl configtest
sudo systemctl restart apache2

Завжди запускайте apache2ctl configtest перед перезапуском. Синтаксична помилка у файлі конфігурації призведе до зупинки всього веб-сервера.

Крок 2b: Налаштуйте Nginx

Відредагуйте серверний блок вашого домену:

sudo nano /etc/nginx/sites-available/yourdomain.com

Додайте наступну конфігурацію:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://yourdomain.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name yourdomain.com www.yourdomain.com;

    ssl_certificate      /etc/ssl/yourdomain/certificate.crt;
    ssl_certificate_key  /etc/ssl/yourdomain/private.key;
    ssl_trusted_certificate /etc/ssl/yourdomain/ca_bundle.crt;

    # Modern TLS hardening
    ssl_protocols        TLSv1.2 TLSv1.3;
    ssl_ciphers          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  1d;
    ssl_session_tickets  off;

    # OCSP Stapling
    ssl_stapling         on;
    ssl_stapling_verify  on;
    resolver             8.8.8.8 8.8.4.4 valid=300s;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    root /var/www/yourdomain;
    index index.html index.php;
}

Увімкніть сайт і перевірте:

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

Пояснення OCSP Stapling: Без stapling браузер повинен звертатися до OCSP-відповідача CA під час кожного TLS-рукостискання, щоб перевірити, чи не відкликано сертифікат. Це додає затримку та розкриває дані перегляду CA. З ssl_stapling on Nginx кешує відповідь OCSP і надає її безпосередньо клієнту, усуваючи зайвий запит.

Посилення TLS: що пропускає оригінальна конфігурація

Сертифікат, встановлений із налаштуваннями за замовчуванням, є безпечним, але не захищеним. Наступна таблиця підсумовує додаткові директиви, які відрізняють прохідну оцінку SSL Labs від A+:

Перевірка та тестування встановлення SSL

Встановлення не є завершеним, поки ви не перевірили результат із зовнішньої точки зору.

Перевірка в браузері

Відвідайте https://yourdomain.com. Значок замка підтверджує дійсний, довірений сертифікат. Натисніть на замок і перевірте деталі сертифіката: переконайтеся, що Common Name або Subject Alternative Name відповідає вашому домену, і перевірте дату закінчення терміну дії.

Тест сервера SSL Labs

Перейдіть до SSL Labs і введіть свій домен. Звіт оцінює вашу конфігурацію TLS від F до A+ і позначає конкретні проблеми: слабкі набори шифрів, відсутні ланцюжкові сертифікати, відсутність HSTS і підтримку протоколів. Рейтинг A+ вимагає HSTS з довгим max-age і відсутності підтримки TLS 1.0 або 1.1.

Перевірка через командний рядок за допомогою OpenSSL

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Це виводить повний ланцюжок сертифікатів, узгоджений набір шифрів і версію TLS. Шукайте Verify return code: 0 (ok) в кінці виводу. Будь-який ненульовий код повернення вказує на проблему з ланцюжком або довірою.

Щоб перевірити дату закінчення терміну дії сертифіката безпосередньо:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Перевірка на змішаний вміст

Після увімкнення HTTPS змішаний вміст є найпоширенішою залишковою проблемою. Вона виникає, коли сторінка HTTPS завантажує ресурси (зображення, скрипти, таблиці стилів, iframe) через HTTP. Змішаний вміст повністю блокує активні ресурси (скрипти, iframe) у сучасних браузерах і генерує попередження в консолі для пасивних ресурсів (зображень).

Виправте змішаний вміст шляхом:

1. Оновлення всіх жорстко закодованих URL http:// у вашій CMS або HTML на https:// або відносні до протоколу //.
2. Додавання заголовка Content Security Policy з upgrade-insecure-requests як тимчасового загального рішення:

add_header Content-Security-Policy "upgrade-insecure-requests" always;

1. Використання DevTools браузера (F12 > Console) для визначення конкретних проблемних ресурсів.

Оновлення сертифіката та управління життєвим циклом

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

Якщо ви керуєте кількома доменами або додатком із високим трафіком на Виділеному сервері, розгляньте можливість впровадження централізованого рішення для управління сертифікатами, такого як cert-manager (Kubernetes), Vault PKI або wildcard-сертифікат для зменшення накладних витрат на оновлення для субдоменів.

Матриця рішень: який метод встановлення використовувати

Технічний контрольний список ключових висновків

• Переконайтеся, що порт 443 відкритий у вашому брандмауері перед встановленням будь-якого сертифіката.
• Завжди перевіряйте, що приватний ключ відповідає сертифікату перед встановленням: openssl x509 -noout -modulus -in certificate.crt | md5sum і openssl rsa -noout -modulus -in private.key | md5sum повинні давати однакові хеші.
• Включіть повний проміжний ланцюжок (ca_bundle.crt) — його відсутність спричиняє збої довіри на мобільних браузерах, навіть коли настільний Chrome показує замок.
• Встановіть chmod 600 для файлу приватного ключа; ніколи не розміщуйте його в директорії, доступній через веб.
• Вимкніть TLS 1.0 і TLS 1.1 у конфігурації вашого веб-сервера — ці протоколи застаріли та вразливі.
• Увімкніть HSTS з includeSubDomains лише після підтвердження, що всі субдомени також обслуговують HTTPS.
• Запустіть certbot renew --dry-run після початкового налаштування Certbot, щоб підтвердити роботу конвеєра оновлення.
• Тестуйте за допомогою SSL Labs після кожного встановлення або зміни конфігурації.
• Перевіряйте наявність змішаного вмісту одразу після переходу на HTTPS — він непомітно порушує функціональність.
• Для wildcard-сертифікатів Let’s Encrypt використовуйте DNS-01 challenge, а не HTTP-01.

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

У чому різниця між SSL-сертифікатом і TLS-сертифікатом?

SSL (Secure Sockets Layer) — це застарілий протокол, який був визнаний застарілим у 1999 році. Його наступник, TLS (Transport Layer Security), — це те, що фактично використовують усі сучасні HTTPS-з’єднання. Термін «SSL-сертифікат» зберігається як галузевий скорочений вираз, але кожен виданий сьогодні сертифікат працює через TLS 1.2 або TLS 1.3.

Чому мій SSL-сертифікат відображається як довірений у Chrome, але не на пристроях Android?

Це майже завжди пов’язано з відсутнім проміжним ланцюжком сертифікатів. Настільний Chrome має агресивний механізм отримання сертифікатів (AIA fetching), який може відновити ланцюжок навіть за його відсутності на сервері. Системне сховище Android цього не робить. Завжди включайте файл ланцюжка ca_bundle.crt у конфігурацію вашого сервера.

Чи можна встановити SSL-сертифікат на домен, для якого ще немає веб-сайту?

Так, але лише якщо DNS A-запис домену вказує на IP-адресу сервера. CA повинен мати можливість зв’язатися з сервером для завершення перевірки домену. Якщо DNS ще не поширився, challenge завершиться невдачею.

Як оновити комерційний SSL-сертифікат без простою?

Згенеруйте новий CSR на сервері, надішліть його до вашого CA, отримайте новий пакет сертифікатів, замініть файли сертифікатів на сервері та перезавантажте веб-сервер (systemctl reload apache2 або systemctl reload nginx). Перезавантаження застосовує новий сертифікат без розриву існуючих з’єднань, на відміну від повного перезапуску.

Чи автоматично перенаправляє встановлення SSL-сертифіката HTTP на HTTPS?

Ні. Встановлення сертифіката лише вмикає HTTPS. Перенаправлення з HTTP на HTTPS необхідно налаштувати окремо у вашому віртуальному хості або серверному блоці. Плагіни --apache і --nginx Certbot пропонують налаштувати це перенаправлення автоматично під час встановлення. Для ручних встановлень додайте явну директиву Redirect permanent (Apache) або return 301 (Nginx) у серверному блоці порту 80.