Основний домен із активним HTTPS та піддомени з помилками без захищеного з’єднання.
SSL не завжди автоматично поширюється на піддомени

Ситуація знайома багатьом адміністраторам сайтів. Основний домен відкривається нормально: замок у браузері є, HTTPS працює, жодних попереджень. Але варто перейти на піддомен – наприклад blog.example.com або mail.example.com – і браузер раптом показує повідомлення про небезпечне з’єднання. Для користувача це виглядає як помилка сайту. Насправді у більшості випадків сервер працює нормально. Проблема зазвичай ховається в тому, як виписаний або підключений сам сертифікат.

Як браузер перевіряє SSL

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

Для системи безпеки важливо інше: домен, до якого підключається користувач, повинен буквально збігатися з тим, що вказано у сертифікаті. Через це й виникають дивні на перший погляд ситуації. example.com відкривається без проблем, але той самий сайт на піддомені раптом “ламається”.

Найчастіша причина – сертифікат для одного домену

У більшості випадків на сайті стоїть звичайний сертифікат для одного домену. Він може бути виданий, наприклад, тільки для example.com або для www.example.com. Поки користувач заходить саме на цю адресу, все виглядає правильно. Сервер віддає сертифікат, браузер звіряє ім’я – і показує захищене з’єднання. Але коли хтось відкриває blog.example.com, браузер бачить інше доменне ім’я. У сертифікаті його немає. Для браузера це виглядає як підміна сайту, тому він і показує попередження. Тут важливий момент: це не помилка SSL і не збій сервера. Це звичайна перевірка безпеки, яка працює саме так, як повинна.

Піддомен для браузера – це окремий сайт

З точки зору власника сайту піддомен часто виглядає просто як частина одного проєкту. Блог, API, поштовий сервер, панель керування – усе це може жити в одному домені. Але SSL працює трохи інакше. Для перевірки безпеки кожен піддомен – це окрема адреса. shop.example.com, api.example.com або mail.example.com розглядаються браузером так само, як будь-які інші сайти в інтернеті. Якщо вони не прописані у сертифікаті, браузер просто не може підтвердити їхню справжність. І тоді з’являється знайоме повідомлення про небезпечне з’єднання.

Wildcard-сертифікати і типова плутанина

Коли сайт використовує багато піддоменів, зазвичай ставлять wildcard-сертифікат. У ньому використовується запис виду *.example.com. Це означає, що сертифікат працюватиме для всіх піддоменів одного рівня. blog.example.com, shop.example.com, api.example.com – усе це покривається одним сертифікатом.

Але тут є деталь, про яку часто забувають. Такий сертифікат іноді не включає сам основний домен. Тобто піддомени працюють нормально, а example.com може видавати попередження. На практиці таке трапляється частіше, ніж здається. Особливо коли сертифікат випускається автоматично і ніхто не дивиться, які саме домени в ньому записані.

Коли проблема не в сертифікаті, а в конфігурації

Буває і складніший сценарій. Сертифікат правильний, піддомени в ньому є, але браузер все одно показує помилку. Тут варто дивитися на конфігурацію сервера. У реальних проєктах піддомени часто працюють через інші конфігураційні блоки або навіть інші сервіси. Наприклад API, поштовий сервер або окрема панель керування. Якщо для цього блоку не підключений потрібний сертифікат, сервер просто віддає інший. І браузер знову бачить невідповідність доменного імені. З боку користувача це виглядає як поламаний SSL, хоча насправді проблема чисто конфігураційна.

Неповний ланцюжок сертифікатів

Ще одна історія, яка іноді з’являється вже після запуску сайту – це неправильний ланцюжок сертифікації. SSL складається не тільки з основного сертифіката. Є ще проміжні сертифікати центру сертифікації, які підтверджують довіру до нього. Якщо вони підключені не повністю, різні браузери можуть поводитися по-різному. На одному комп’ютері сайт відкриється нормально. На іншому з’явиться попередження. Іноді це проявляється саме на піддоменах, бо вони обслуговуються іншим серверним конфігом.

Чому це важливо для сайту

Попередження браузера про небезпечне з’єднання працюють дуже просто. Користувач бачить червоне повідомлення – і просто закриває вкладку. Особливо болісно це виглядає, коли піддомени використовуються для входу в особистий кабінет, API або поштових сервісів. Частина інтеграцій може взагалі перестати працювати, а деякі браузери просто блокують такі з’єднання. У результаті проблема з SSL, яка здається дрібницею, швидко починає впливати і на довіру користувачів, і на роботу самого сайту.

Чому такі проблеми з’являються

Найчастіше причина банальна. Спочатку запускається один сайт на одному домені. Потім з’являється блог, API, окремий сервіс або панель керування. Піддомени додаються поступово, а сертифікат залишається старим.

У реальних проєктах це звичайна історія. Просто про такі речі краще думати заздалегідь. Бо потім доводиться перевипускати сертифікати, міняти конфігурацію сервера і перевіряти все знову. Іноді вже на працюючому сайті.