Make.com: автоматическая генерация SSL-сертификатов за 5 минут

Почему SSL в 2026 всё ещё ломает нервы

Сертификаты Let’s Encrypt живут 90 дней — это значит, что “всё работает” по умолчанию превращается в “всё упало” примерно раз в квартал, если не поставить автопродление. И да, в феврале 2026 это по-прежнему самая частая причина внезапного “у нас сайт красный”.

Что такое SSL-сертификат и почему “просто забыть” не получится

SSL-сертификат — это цифровой документ, который подтверждает домен и включает шифрование HTTPS между браузером и сайтом. Когда он истекает, браузер честно предупреждает пользователя, а тот честно уходит. Для маркетинга это боль, для доверия — минус репутация, для SEO — риск просадки (особенно если у вас трафик из поиска).

Я видела ситуации, где сертификат “протух” на пару часов, а в CRM потом недосчитались лидов за день. Мелочь? Ну да, пока это не ваш единственный рекламный лендинг.

Почему ручное продление — это “газель на МКАДе”, только в IT

Ручное продление обычно выглядит одинаково: кто-то вспоминает, что срок подходит, потом начинается Let’s Encrypt/Certbot, доступы к DNS, доступы к серверу, “а где лежит ключ”, “а кто помнит пароль”. И вот вы уже ковыряетесь в проде в 23:40, потому что “нельзя, чтобы падало”.

По моему опыту PROMAREN в аудитах процессов, 2-4 часа в месяц на такие “мелкие техдолги” — это не редкость. А wildcard-сертификаты (*.domain.ru) иногда раздувают историю до 8-10 часов в пике, особенно если DNS подтверждается долго.

Контекст РФ: .ru, DNS и скорость подтверждений

В РФ добавляется бытовой слой: домены .ru часто обслуживаются у регистраторов, где TXT-записи нужно добавить быстро и аккуратно, иначе подтверждение не проходит. Плюс у разных провайдеров разная “пропагация”, и сценарий может упасть не потому что вы ошиблись, а потому что DNS ещё не разошёлся.

Тут я поняла простую вещь: если процесс зависит от терпения человека, он рано или поздно сломается. Поэтому дальше — про автоматизацию на Make.com, без героизма и без YAML.

Как выглядит сценарий в Make.com (без DevOps-героизма)

Сценарий на Make.com для SSL обычно укладывается в 5-7 модулей: триггер, цепочка ACME-запросов, обновление DNS TXT, выпуск сертификата и деплой. Это означает, что один раз настраиваете — потом просто получаете уведомление, что всё ок.

Скелет процесса: триггер — ACME — DNS — деплой

Я люблю объяснять так, чтобы было видно “трубопровод”. В Make.com у вас есть Scheduler (по расписанию раз в 80-85 дней, чтобы не упираться в 90), дальше несколько HTTP-запросов к ACME-серверу Let’s Encrypt, затем отдельный шаг на DNS-01 challenge через API вашего DNS-провайдера, и финально — доставка файлов сертификата на сервер.

Если хочется свериться с официальными деталями, ACME и логика подтверждений описаны в документации Let’s Encrypt (это не магия, просто протокол): Let’s Encrypt Documentation. А про Make.com и его HTTP-модули удобно смотреть в справке: Make.com Help Center.

Где реально экономятся часы (а не “в теории”)

Раньше я считала, что автоматизация SSL — это “приятно, но не обязательно”. После 8 проектов в 2025-2026 поменяла мнение: самое ценное тут не скорость выпуска сертификата, а отсутствие человеческого участия в моменте. Один раз настроили — и больше не держите это в голове.

Если у малого бизнеса 5 сайтов, и каждый раз обновление занимало хотя бы 4 часа в квартал “с проверками и деплоем”, то это около 80 часов в год. И это не красивые цифры, а обычная математика календаря.

Мой “минимальный набор” модулей, который чаще всего взлетает

Я не буду превращать это в инструкцию “нажми сюда”, но общий набор повторяется. Обычно я собираю сценарий вокруг HTTP-модуля (запросы к ACME), Delay/повторных проверок для DNS и финального уведомления в Telegram. Для хранения файлов иногда хватает Google Drive, иногда удобнее сразу грузить на сервер.

Если вам нужна база по автоматизациям без лишнего шума, я складываю похожие разборы в подборку статей про автоматизацию через n8n и Make.com. Там же держу заметки, что “сломалось на третьей попытке и почему”.

Дальше самое интересное — DNS-01 и ожидание TXT. Именно там большинство сценариев делает вид, что работает, а потом тихо падает.

DNS-01, .ru и ожидание TXT: где чаще всего спотыкаются

3 из 5 сценариев продления SSL ломаются на DNS-01 не из-за ACME, а из-за времени: TXT-запись ещё не распространилась, а вы уже отправили подтверждение. Это означает, что нужно проектировать ожидание и повторные проверки как нормальную часть процесса.

Почему wildcard почти всегда тянет DNS-01

Wildcard-сертификат для *.domain.ru обычно проще подтверждать через DNS-01, потому что HTTP-01 не всегда подходит (особенно если доменов много, а точки входа разные). ACME выдаёт challenge, вы кладёте TXT _acme-challenge, ждёте, подтверждаете — и только потом получаете сертификат.

В Make.com это делается через API DNS-провайдера. У Reg.ru, Nic.ru и других есть свои методы, но смысл один: создать TXT-запись и потом корректно её убрать/обновить. И вот тут начинается “подождите 60 секунд… или 600”.

Четыре ошибки, которые я вижу чаще остальных

В 2026 я почти перестала удивляться типовым поломкам — они повторяются, как сезонная простуда. Я держу у себя маленький список, чтобы быстро диагностировать, почему сценарий не выпустил сертификат с первого раза (а клиент уже нервничает).

• Перепутали staging и production у Let’s Encrypt и упёрлись в rate limit (потом удивление: “почему бан?”).
• Не заложили время на DNS-пропагацию: сценарий подтверждает домен раньше, чем TXT реально виден.
• Сгенерировали слабый ключ (меньше RSA 2048) или криво собрали CSR — браузеры не прощают.
• Оставили DNS API-ключи “как есть” в сценарии — и это уже не техдолг, а риск.

Забавно, но чаще всего лечится не “сложным кодом”, а обычным ожиданием и повторной проверкой: Delay на 300 секунд и несколько попыток GET-проверки записи. Да, выглядит скучно. Зато работает.

Короткий кейс: три лендинга и забытый сертификат

Был у меня кейс в 2025: фрилансер с тремя лендингами под VK Ads. Ручное обновление занимало около 3 часов в квартал, и сайт падал раз в пару месяцев — просто потому что “не успел”. После сценария в Make.com с DNS через API у него осталось примерно 420 операций в год и одно воспоминание — как раньше было неудобно.

Если сценарий не умеет ждать DNS, он не автоматизирует SSL — он просто быстро повторяет вашу ручную ошибку.

И раз уж мы заговорили о рисках — логично перейти к безопасности. Потому что сертификат — это не только “зелёный замочек”, но и ключи, доступы, журналы.

Безопасность: ключи, доступы и 152-ФЗ без фанатизма

Автоматизация SSL безопасна ровно настолько, насколько вы дисциплинированы с ключами DNS и доступами к серверу. Это означает: можно собрать красивый сценарий за 5 минут, а потом всё испортить одним “скиньте токен в чатик”.

Где обычно лежит риск (и почему он не в Let’s Encrypt)

Let’s Encrypt как сервис — понятный и давно обкатанный. А вот ваши DNS API-ключи и SSH-доступы — это уже “ваша кухня”. Самый частый провал: ключи хранятся в сценарии открыто, доступ к Make.com у нескольких людей, MFA выключен, а уведомления о входах никто не читает.

Я здесь зануда (профдеформация после аудита), но без согласованных доступов процесс становится риском, а не помощником. Особенно если у вас домены клиентские или на одном аккаунте регистратор держит всё агентство.

Как хранить секреты в Make.com, чтобы не краснеть

Я обычно прошу команду сделать минимум: секреты только в переменных/хранилищах Make, доступы разграничить, MFA включить, а права на сценарии — не “всем админа”. Если деплой идёт по SSH, то только по ключам и с минимальными правами на нужные каталоги. И да, все персональные данные остаются в контуре компании, даже если это “просто лендинг”.

Про требования к обработке данных в РФ можно свериться с текстом 152-ФЗ: consultant.ru: 152-ФЗ. SSL сам по себе не делает вас compliant, но он убирает глупые уязвимости “на поверхности”.

Немного про white-data подход и “честные” логи

В PROMAREN я называю это white-data: вы заранее понимаете, какие данные куда уходят, и можете это объяснить без легенд. Для SSL-автоматизации это означает простую вещь: в логах сценария не должны светиться ключи и приватные части сертификата, а уведомления должны быть информативными, но не болтливыми.

Я хотела сделать “идеально”, но это было наивно обычно достаточно сделать “не опасно” и “воспроизводимо”. И вот теперь можно честно посчитать эффект.

Сколько времени и денег это реально экономит

Если у вас 5 доменов и ручное продление занимало по 3-4 часа в квартал на каждый, автоматизация на Make.com возвращает десятки часов в год. Это означает, что окупаемость чаще всего измеряется не “рублями за модуль”, а отсутствием простоя и человеческих ошибок.

Математика без украшений: время, простои, операционные лимиты

Make.com даёт бесплатный лимит операций, и для пары доменов его часто хватает. Но важнее другое: сценарий работает по расписанию, и вы не держите “проверка ssl сертификата” как регулярную мысль в голове. У меня в проектах 2025-2026 самый заметный эффект был даже не во времени инженера, а в том, что маркетинг переставал жить в режиме “а сайт точно жив?”.

Да, кто-то спросит: “а если у нас Kubernetes?” Тогда cert-manager будет более естественным выбором, особенно в облаках. Для ориентира: проект cert-manager живёт в экосистеме CNCF и хорошо документирован: cert-manager documentation. Но в SMB чаще нужен не кластер, а спокойствие.

Когда Make.com лучше acme.sh и наоборот

Я не считаю Make.com единственным правильным путём. acme.sh на VPS — отличный вариант, если у вас уже есть администрирование и shell не пугает. cert-manager в Kubernetes — мощно, но требует DevOps-руки. Make.com выигрывает там, где нужно быстро и без “встраивания в инфраструктуру”, плюс удобно делать уведомления в Telegram и маршрутизацию ошибок.

Чтобы не спорить “на вере”, я иногда свожу сравнение в маленькую таблицу — так проще принять решение, особенно в начале 2026, когда доменов стало больше из-за множества микролендингов.

Что я бы сделала, если доменов стало 20 (и все разные)

Когда доменов много, самая большая проблема — не выпуск сертификата, а управление исключениями: у одного провайдера нет API, у другого TXT обновляется 15 минут, у третьего два аккаунта и разные права. Здесь работает простая тактика: стандартизировать, где можно, а где нельзя — делать “полуавтомат” с ручным вводом TXT и автодеплоем дальше.

Если хочется смотреть на подобные решения глазами процесса, у меня на сайте PROMAREN есть заметки про прозрачные метрики и автоматизацию без лишнего героизма. А в канале PROMAREN я иногда показываю, как выглядят сценарии и почему они падают (и да, иногда это просто пропущенная запятая в JSON, бывает).

Дальше оставлю ответы на вопросы, которые обычно прилетают в личку, когда люди в первый раз настраивают https make com сценарии под SSL.

Три мысли, которые остаются после настройки

Первое: SSL сертификат — это не “техзадача на квартал”, а регулярный процесс, который лучше вынести из головы. Второе: Make.com хорош, когда важна скорость внедрения и уведомления, а не идеальная инфраструктура. Третье: безопасность решается не инструментом, а дисциплиной с ключами и доступами.

Что ещё важно знать

Make.com бесплатно подходит для продления SSL?

Да, бесплатного лимита Make.com часто хватает, если доменов немного и вы продлеваете сертификаты раз в 80-85 дней. На один домен уходит несколько десятков операций в сценарии, поэтому 4-5 доменов обычно помещаются без проблем. Но если вы добавляете мониторинг, ретраи DNS и деплой на несколько серверов, лимит можно съесть быстрее. Я обычно сначала считаю операции на тестовом прогоне.

Работает ли это с доменами .ru и регистраторами вроде Reg.ru?

Да, работает, если у DNS-провайдера есть API для управления TXT-записями. Для .ru чаще всего используют DNS-01 challenge, и здесь важны две вещи: корректный вызов API и достаточное время на распространение записи. В реальности TXT может появиться не за 60 секунд, а за 5-15 минут, поэтому в сценарии нужны ожидание и повторные проверки. Тогда всё стабилизируется.

Что делать, если у DNS-провайдера нет API и TXT нужно руками?

Можно сделать полуавтоматический режим: сценарий формирует challenge, отправляет его вам в Telegram или на почту, а вы вручную добавляете TXT в панели. После этого сценарий продолжает работу и делает выпуск сертификата и деплой. Это уже не “полный автопилот”, но всё равно снимает половину рутины и снижает риск забыть про продление. Для агентств с разными клиентскими доменами это часто нормальный компромисс.

Насколько безопасно хранить ключи и доступы в Make.com?

Это безопасно ровно настолько, насколько вы настроили доступы: MFA, роли, хранение секретов в переменных и минимальные права на SSH. Не храните приватные ключи и токены в открытом виде в сценариях и не пересылайте их в чатах. Также стоит ограничить доступ к аккаунту и регулярно проверять, кто имеет права на редактирование сценариев. Если всё это сделано, риск обычно ниже, чем “ключи в заметках у сотрудника”.

Какие альтернативы Make.com для автоматической генерации SSL в 2026?

Есть два популярных варианта: acme.sh на VPS и cert-manager в Kubernetes. acme.sh хорош, если вы уверенно работаете с shell и хотите держать всё локально, без no-code платформ. cert-manager подходит, когда у вас кластер и вы хотите централизованное управление сертификатами на уровне платформы. Make.com выигрывает, когда важна скорость внедрения, много доменов и нужны уведомления и маршрутизация ошибок без DevOps-команды.