Как настроить SIP-TLS: сертификаты, проверка клиентов и что ломается на практике

Вы настроили SIP-сервер, подключили телефоны, а звонки внезапно перестали работать — с ошибкой «TLS handshake failed» или «certificate not trusted». Вы проверили порты, пароли, регистраторы — всё в порядке. Но сертификат? Его вообще не трогали. Это классическая ситуация. SIP-TLS — не просто «включить и забыть». Это тонкий механизм, где один неверно сгенерированный сертификат или неправильный CN в SSL-сертификате ломает всю связь. Ниже — пошагово, без теории, только то, что реально работает.

Почему SIP-TLS вообще нужен

SIP-трафик по умолчанию идёт в открытом виде — как телефонный разговор, который слышит каждый, кто подключён к вашей сети. Это неприемлемо для бизнеса, банков, медицины, любого, кто заботится о конфиденциальности. TLS шифрует соединение между клиентом (телефоном) и сервером (PBX). Без него вы не пройдёте аудиты, не получите сертификаты соответствия, и ваша связь может быть перехвачена.

Но TLS — не панацея. Он не защищает от взлома паролей, не шифрует медиапоток (RTP), и не спасёт, если вы используете самоподписанный сертификат на клиенте, который не доверяет CA. Вот тут и начинаются проблемы.

Как правильно выбрать и настроить сертификат

Сертификат для SIP-TLS — не тот же, что для веб-сайта. Есть три ключевых требования:

  • Сертификат должен быть выдан для FQDN сервера — не IP, не домен без префикса, а именно полное доменное имя, которое клиенты используют для подключения. Например: sip.company.ru. Если клиенты подключаются по sip.company.ru:5061, сертификат должен быть на sip.company.ru.
  • Сертификат должен включать SAN (Subject Alternative Name) — если у вас несколько серверов, или клиенты подключаются и по домену, и по поддомену, все они должны быть в SAN. Без этого некоторые клиенты (особенно iOS и Android) откажутся соединяться.
  • Не используйте самоподписанные сертификаты в продакшене — они работают, но только если вы вручную импортируете их на каждый телефон. Это не масштабируемо. Даже если у вас 10 устройств — вы потеряете день на настройку. Для 100 — это невозможно.

Практический пример: вы купили сертификат от Let’s Encrypt. Генерируете CSR на сервере с именем sip.example.com. В SAN добавляете:

  • sip.example.com
  • pbx.example.com
  • example.com

Потом устанавливаете его на FreeSWITCH, Asterisk или Kamailio — и всё. Клиенты с доверенными корневыми сертификатами (99% современных устройств) подключаются без ошибок.

Как проверить, что сертификат работает

Проверка — не «запустил и увидел, что звонит». Нужно проверить три вещи:

  1. Срок действия — сертификаты Let’s Encrypt живут 90 дней. Проверьте: openssl x509 -in cert.pem -noout -dates. Если до истечения меньше 30 дней — пора обновлять.
  2. Цепочка доверия — убедитесь, что сервер отдаёт не только сертификат, но и промежуточные CA. Проверить можно через openssl s_client -connect sip.example.com:5061 -showcerts. Если в выводе только один сертификат — вы забыли промежуточный. Это частая ошибка.
  3. Совместимость с клиентами — некоторые телефоны (особенно бюджетные SIP-телефоны) не поддерживают современные алгоритмы. Проверьте, какие шифры предлагает ваш сервер: openssl s_client -connect sip.example.com:5061 -cipher 'HIGH:!aNULL:!MD5'. Если клиент не понимает TLS 1.2+ — он не подключится.

Если у вас есть доступ к логам сервера — смотрите на ошибки вида:

TLS handshake failed: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown

Это значит: клиент не доверяет сертификату. Причина — либо он самоподписанный, либо не в цепочке доверия, либо CN не совпадает с тем, что клиент пытается подключить.

Какие клиенты работают с SIP-TLS, а какие — нет

Не все SIP-телефоны одинаково хорошо поддерживают TLS. Ниже — реальная картина по популярным моделям (на 2024 год).

Модель Поддержка TLS Требования к сертификату Частые ошибки
Yealink T4x (T42S, T46S) Да, отлично Требует полную цепочку CA. SAN обязателен. Не подключается, если сертификат выдан на IP, а не домен.
Grandstream GXP2170 Да, но только TLS 1.2 Не поддерживает ECC-сертификаты. Только RSA. Отказывается подключаться, если сертификат на ECDSA.
Polycom VVX 350/500 Да, с поддержкой OCSP Требует, чтобы CN совпадал с именем сервера в настройках. Падает при использовании wildcard-сертификатов (не всегда).
Snom 821 Да, но только до TLS 1.1 Не поддерживает SHA-256? Нет, поддерживает. Но не работает с новыми CA после 2022 года, если не обновлена прошивка. Отказывается после обновления CA-цепочки — нужно обновить прошивку.
Softphone Zoiper (Android/iOS) Да, но только если сертификат в системном хранилище На iOS — сертификат должен быть установлен в «Настройки → Общие → Профили». Пользователь не установил сертификат вручную — и звонки не работают.
Budget SIP-телефоны (Aastra, X-Lite, дешёвые китайские) Частично или нет Многие не поддерживают TLS вообще — только UDP/TCP без шифрования. Сертификат не нужен — клиент его просто игнорирует, но вы думаете, что он работает.

Важно: даже если телефон «поддерживает TLS», это не значит, что он поддерживает ваш сертификат. Проверяйте не только модель, но и прошивку. Устаревшие прошивки часто ломают работу с современными сертификатами.

Что делать, если клиент не подключается

Сценарии и решения — по ситуации.

Вы используете Let’s Encrypt. Сертификат на sip.company.ru. Клиенты не подключаются. Проверяете логи — ошибка «certificate unknown».

Решение: Убедитесь, что на сервере в конфиге SIP-TLS указаны оба файла: сертификат и цепочка CA. В FreeSWITCH это tls-cert-file и tls-ca-file. В Asterisk — tlscertfile и tlscapath. Если вы положили только сертификат — цепочка не передаётся. Клиент не может проверить, кому он доверяет.

Ситуация 2: У вас 30 сотрудников — все используют Zoiper на iPhone

Сертификат корректный, сервер настроен, но телефоны не подключаются. На Android — всё работает.

Решение: На iPhone сертификат должен быть установлен в систему. Откройте сертификат на компьютере, отправьте его по email на iPhone, откройте в Safari — и установите. После этого в «Настройки → Общие → О профиле» появится ваш сертификат. Без этого — iOS его не доверяет. Даже если он от Let’s Encrypt.

Ситуация 3: У вас старый Grandstream GXP2170 — TLS не работает

Вы обновили сертификат на ECDSA — теперь телефон не подключается.

Решение: Grandstream GXP2170 (прошивка до 1.0.4.11) не поддерживает ECC. Перейдите на RSA-ключ 2048 бит. Это не идеально с точки зрения безопасности, но работает. Обновите прошивку — если версия 1.0.4.11+ — можно вернуться к ECDSA.

Ситуация 4: Вы используете самоподписанный сертификат и не хотите покупать

Это допустимо только в тестовой среде или если вы контролируете все клиенты. Но даже тогда — есть риски.

Решение: Сгенерируйте сертификат с правильным CN и SAN, подпишите его через вашу внутреннюю CA (если есть). Импортируйте корневой сертификат вашей CA на все устройства. Это лучше, чем самоподписанный — потому что цепочка доверия понятна. Если CA нет — не пытайтесь. Это приведёт к хаосу.

Частые ошибки, которые ломают SIP-TLS

  • Использование IP-адреса в сертификате — клиенты не доверяют IP в CN. Только домены.
  • Нет SAN — особенно критично для iOS и Android.
  • Сертификат не включает цепочку CA — сервер отдаёт только свой сертификат, а не всю цепочку. Клиент не может проверить подлинность.
  • Неправильный порт — TLS работает на 5061, а клиент пытается подключиться на 5060. Проверьте настройки клиента.
  • Устаревший TLS-протокол — если сервер требует TLS 1.3, а клиент поддерживает только 1.0 — соединение не установится.
  • Сертификат истёк — да, это происходит. Даже у крупных компаний. Автоматизация обновления — обязательна.
  • Сертификат выдан на другой домен — например, вы купили сертификат на voip.company.com, а клиенты подключаются к sip.company.com. Не совпадает — отказ.

Как лучше сделать — рекомендации от практика

Вот что я делаю на каждом проекте, где есть SIP-TLS:

  1. Всегда использую Let’s Encrypt (или аналогичный доверенный CA). Никогда не использую самоподписанные в продакшене.
  2. Все сертификаты генерируются с SAN, включающим все возможные FQDN, которые используются клиентами.
  3. На сервере всегда настраиваю передачу полной цепочки CA — проверяю через openssl s_client.
  4. В конфиге сервера отключаю TLS 1.0 и 1.1. Оставляю только TLS 1.2 и 1.3.
  5. Для старых клиентов (например, Grandstream GXP2170) оставляю отдельный порт с TLS 1.2 + RSA-ключом — и не трогаю его.
  6. Автоматизирую обновление сертификатов через certbot + cron. Проверяю раз в месяц — и только если что-то сломалось.
  7. Всегда документирую: какой сертификат, на какой домен, когда истекает, и какие клиенты с ним работают. Это спасает, когда кто-то уходит из компании.

Что выбрать — сценарии

Если вы сейчас находитесь в такой ситуации — вот что делать:

  • У вас 1–5 телефонов, все новые, и вы не хотите тратить деньги — используйте Let’s Encrypt. Настраиваете через certbot. Всё работает.
  • У вас 20+ телефонов, и часть — старые (Snom, Grandstream) — купите коммерческий сертификат (например, DigiCert или Sectigo) с поддержкой RSA 2048 и широкой совместимостью. Он дороже, но меньше головной боли.
  • У вас корпоративная инфраструктура с внутренним CA (Active Directory) — используйте внутренний сертификат. Установите корневой сертификат на все устройства через GPO (Windows) или MDM (iOS/Android). Это безопаснее, чем внешний CA.
  • Вы тестируете, и не хотите платить — используйте самоподписанный сертификат, но только для теста. Импортируйте его вручную на один-два устройства. Не пытайтесь развернуть на 50.
  • У вас облачный PBX (например, 3CX, RingCentral) — не трогайте сертификаты. Они управляются автоматически. Ваша задача — только убедиться, что клиенты используют TLS и не игнорируют предупреждения.

Итог: что делать прямо сейчас

Если вы читаете это — значит, у вас проблемы с SIP-TLS. Вот что делать:

  1. Откройте логи сервера. Найдите ошибку TLS handshake.
  2. Проверьте, какой сертификат использует сервер: openssl s_client -connect ваш_сервер:5061 -showcerts.
  3. Сверьте CN и SAN в сертификате с тем, что пишут клиенты в настройках.
  4. Убедитесь, что цепочка CA передаётся полностью.
  5. Если клиенты — iOS/Android — проверьте, установлен ли сертификат в систему.
  6. Если сертификат самоподписанный — замените его на Let’s Encrypt за 10 минут.
  7. Если клиент старый — найдите его прошивку, обновите, или настройте отдельный порт с совместимым TLS.

Нет «идеального» сертификата. Есть только правильный для вашей ситуации. Не пытайтесь подогнать всё под один шаблон. Учитывайте клиентов, их возраст, их прошивки, их возможности. И помните: TLS — это не про безопасность «на бумаге». Это про то, чтобы звонки работали без сбоев. Если они не работают — вы сделали что-то не так. Исправьте — и всё заработает.

Информация в этой статье носит ознакомительный характер. Настройка SIP-инфраструктуры требует понимания вашей сети, безопасности и требований соответствия. Перед внедрением в продакшен рекомендуется проконсультироваться с сетевым инженером или специалистом по VoIP-системам.

Virtual SIM — eSIM и виртуальные номера по всему миру