Ошибка HTTPS: как мы отправили проблемы с сертификатами в нокаут

Первый раунд: «Не удаётся установить соединение с сайтом»

На скриншоте с телефона были сразу два тревожных сообщения: «Соединение сброшено» и предупреждение браузера о незащищённом соединении. Особенно неприятно видеть это на собственном сайте. Ты знаешь, что там услуги, проекты и кнопки для связи. А посетитель видит тревожный экран и вполне может уйти.

Решила разобраться и заодно проверить остальные свои сайты. Проверка HTTPS показала: основной защищённый адрес HODWEB работал, сертификат был действующим. Но обычный HTTP открывался отдельно, без обязательного перехода на HTTPS. Вариант адреса с www тоже был настроен не полностью.

Исправили перенаправление HTTP на HTTPS. Позже сайт открылся с мобильного интернета и из ВК. Но конкретную причину первоначального сброса соединения на телефоне мы не доказали. Нашли и устранили реальные ошибки конфигурации, а не просто объявили браузер виноватым. Это важное различие: сообщение о сбросе соединения само по себе ещё не доказывает проблему с сертификатом.

Второй раунд: просрочен SSL-сертификат, хотя продление настроено

Казалось бы, можно выдохнуть? Нет, это была разминка. Проверка других доменов обнаружила просроченные сертификаты. У ещё одного сайта срок подходил к концу. В обиходе их называют SSL-сертификатами, хотя современные защищённые соединения используют TLS.

Программа win-acme была установлена, задание в планировщике существовало. Почему же автоматическое продление сертификата не срабатывало? Ответ нашёлся в журнале: процесс ожидал ручного подтверждения владения доменом через DNS.

Раньше я обновляла сертификаты через REG.RU: получала специальную TXT-запись, добавляла её в DNS и подтверждала выполнение. Для ручного выпуска это нормальный способ. Но планировщик не может сам зайти в личный кабинет, внести запись и нажать Enter вместо меня.

Получался короткий диалог: «Сертификат пора обновить». «Хорошо, добавьте запись в DNS». И тишина до следующего запуска. Автоматический запуск программы ещё не означает, что весь процесс автоматический.

Хук слева: настраиваем автоматическое продление сертификатов

Для работающих сайтов решили заменить ручную DNS-проверку на автоматическую HTTP-проверку. Во время выпуска сертификата сервер предоставляет специальный проверочный ответ. Центр сертификации обращается к домену и проверяет его. В выбранной схеме вручную переносить TXT-записи больше не нужно.

Это не означает, что сайт должен постоянно работать по незащищённому HTTP. Посетители переходят на HTTPS, а проверочный механизм используется отдельно. Для этого должны оставаться доступными необходимые сетевые подключения и корректные настройки сервера.

Задача состояла из нескольких частей: получить новый сертификат, назначить его нужному сайту в IIS и сохранить настройки для следующих продлений. Просто скачать сертификат недостаточно: браузер должен получить именно его при подключении.

Хук справа: кириллические домены и ошибки скриптов

Домены на русском языке внутри технических систем могут выглядеть иначе: вместо привычного названия появляется строка, начинающаяся с xn--. Это Punycode, специальная запись доменного имени. При работе с сертификатами программа должна правильно сопоставить оба представления.

Первый вариант исправления не подошёл: win-acme сообщил, что основное имя не входит в список имён сертификата. Следующая попытка упёрлась в ошибку поиска привязок IIS. Скрипты, которые готовил помощник, пришлось исправлять.

Один из файлов Windows PowerShell прочитал в неправильной кодировке. Русские названия превратились в набор непонятных символов, выполнение остановилось ещё до начала работы. Здесь настройки сайтов не изменились: программа просто не смогла прочитать файл.

Исправили кодировку и проверили синтаксис именно в Windows PowerShell, которым запускались команды. Но соперник ещё стоял.

Пропущенный удар: после изменения привязок сайты остановились

Расскажу и об этой части. История «всё исправили одной красивой командой» здесь была бы неправдой. В процессе исправления добавили HTTP-привязки www для кириллических доменов. В нашей конфигурации IIS их отверг, и три сайта оказались остановлены.

Попытка устранить одну проблему создала другую. В этот момент выпуск сертификатов отложили и занялись восстановлением доступности. Проверили состояние сайтов, сохранили текущие настройки и прочитали журнал событий.

Журнал показал конкретную причину: IIS не смог зарегистрировать добавленные адреса. Проблемные привязки удалили. Затем отдельно запустили сайты и проверили, что они снова отвечают. Сначала возвращаем сайт посетителям, потом продолжаем ремонт.

Из этой ситуации не следует, что www несовместим с русскими доменами вообще. Проблема возникла в конкретной конфигурации и при конкретных изменениях. Универсальный вывод здесь другой: изменения нужно проверять, а восстановление доступности должно быть первым приоритетом.

Решающий раунд: настройка HTTPS без лишних изменений

Дальше обновляли сертификаты для основных кириллических адресов без добавления www. Имена передали через штатные параметры win-acme, чтобы программа сама правильно их обработала. Эта попытка завершилась успешно.

На момент проверки 2 октября 2026 года сайты «Сварка-Ялта», «Сварщик-Ялта» и «Помощь адвоката СПб» отвечали по HTTPS с действительными сертификатами до 31 декабря 2026 года. Переход с HTTP на HTTPS был проверен отдельно.

Для этих сайтов сохранены автоматическая HTTP-проверка и установка обновлённых сертификатов в IIS. Остаточную настройку ручной DNS-проверки у TimeCS тоже заменили. Следующее плановое продление ещё впереди: его результат нужно будет контролировать по журналам.

HODWEB, портал ГПА и TimeCS проверены также с www: запросы переходят на основной защищённый адрес. У трёх кириллических сайтов пока используем основные адреса без www. Остановленные и перенесённые на другой хостинг проекты в этот результат не включаю.

Нокаут засчитывается после проверки сайта

Не после строки «скрипт завершён». Команда может закончить работу, а посетитель всё ещё будет видеть ошибку. Даже успешно выпущенный сертификат нужно правильно назначить сайту.

Проверили ответы сервера, срок действия и доверие к сертификатам, перенаправления и сохранённые настройки продления. На восстановленных основных адресах ошибки из-за просроченных сертификатов больше не воспроизводились.

Хук слева, хук справа, работа над собственными ошибками – и эту серию проблем отправили в нокаут. Но HTTPS не означает, что сайт защищён от всех возможных угроз. Здесь мы восстановили корректное защищённое соединение, а не проводили полный аудит безопасности.

Техническая поддержка сайта: что остаётся за красивой страницей

Сайт требует внимания после запуска. Сертификаты заканчиваются, настройки автоматизации могут зависеть от ручного действия, адреса с www и без www способны вести себя по-разному. А исправление без проверки иногда добавляет новую проблему.

Поэтому техническая поддержка сайта – это не только поменять фотографию или добавить кнопку. Иногда это найти причину, по которой посетитель вообще не может до этой кнопки добраться.

Если нужна доработка сайта в Ялте или удалённая помощь с существующим проектом, можно начать с одной конкретной задачи: диагностики ошибки HTTPS, настройки перенаправлений или проверки продления сертификата. Состав работ определяется после знакомства с технологией и текущим состоянием сайта.

Что полезно проверять владельцу сайта

• Открывается ли основной адрес по HTTPS без предупреждений браузера.
• Куда ведут HTTP и вариант адреса с www, если он используется.
• Когда истекает сертификат и есть ли успешные записи о продлении в журнале.
• Не зависит ли автоматическое продление от ручного добавления DNS-записи.
• Сохранены ли настройки перед изменениями и проверена ли работа сайта после них.
• При появлении ошибки: точный адрес, текст предупреждения, время, браузер и тип подключения. Эти сведения помогают начать диагностику без догадок.