Вы настроили SIP-сервер, подключили телефоны, а звонки внезапно перестали работать — с ошибкой «TLS handshake failed» или «certificate not trusted». Вы проверили порты, пароли, регистраторы — всё в порядке. Но сертификат? Его вообще не трогали. Это классическая ситуация. SIP-TLS — не просто «включить и забыть». Это тонкий механизм, где один неверно сгенерированный сертификат или неправильный CN в SSL-сертификате ломает всю связь. Ниже — пошагово, без теории, только то, что реально работает.
- Почему SIP-TLS вообще нужен
- Как правильно выбрать и настроить сертификат
- Как проверить, что сертификат работает
- Какие клиенты работают с SIP-TLS, а какие — нет
- Что делать, если клиент не подключается
- Ситуация 1: У вас 5 телефонов — все Yealink, все на одной сети
- Ситуация 2: У вас 30 сотрудников — все используют Zoiper на iPhone
- Ситуация 3: У вас старый Grandstream GXP2170 — TLS не работает
- Ситуация 4: Вы используете самоподписанный сертификат и не хотите покупать
- Частые ошибки, которые ломают SIP-TLS
- Как лучше сделать — рекомендации от практика
- Что выбрать — сценарии
- Итог: что делать прямо сейчас
Почему 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.compbx.example.comexample.com
Потом устанавливаете его на FreeSWITCH, Asterisk или Kamailio — и всё. Клиенты с доверенными корневыми сертификатами (99% современных устройств) подключаются без ошибок.
Как проверить, что сертификат работает
Проверка — не «запустил и увидел, что звонит». Нужно проверить три вещи:
- Срок действия — сертификаты Let’s Encrypt живут 90 дней. Проверьте:
openssl x509 -in cert.pem -noout -dates. Если до истечения меньше 30 дней — пора обновлять. - Цепочка доверия — убедитесь, что сервер отдаёт не только сертификат, но и промежуточные CA. Проверить можно через
openssl s_client -connect sip.example.com:5061 -showcerts. Если в выводе только один сертификат — вы забыли промежуточный. Это частая ошибка. - Совместимость с клиентами — некоторые телефоны (особенно бюджетные 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», это не значит, что он поддерживает ваш сертификат. Проверяйте не только модель, но и прошивку. Устаревшие прошивки часто ломают работу с современными сертификатами.
Что делать, если клиент не подключается
Сценарии и решения — по ситуации.
Ситуация 1: У вас 5 телефонов — все Yealink, все на одной сети
Вы используете 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:
- Всегда использую Let’s Encrypt (или аналогичный доверенный CA). Никогда не использую самоподписанные в продакшене.
- Все сертификаты генерируются с SAN, включающим все возможные FQDN, которые используются клиентами.
- На сервере всегда настраиваю передачу полной цепочки CA — проверяю через
openssl s_client. - В конфиге сервера отключаю TLS 1.0 и 1.1. Оставляю только TLS 1.2 и 1.3.
- Для старых клиентов (например, Grandstream GXP2170) оставляю отдельный порт с TLS 1.2 + RSA-ключом — и не трогаю его.
- Автоматизирую обновление сертификатов через certbot + cron. Проверяю раз в месяц — и только если что-то сломалось.
- Всегда документирую: какой сертификат, на какой домен, когда истекает, и какие клиенты с ним работают. Это спасает, когда кто-то уходит из компании.
Что выбрать — сценарии
Если вы сейчас находитесь в такой ситуации — вот что делать:
- У вас 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. Вот что делать:
- Откройте логи сервера. Найдите ошибку TLS handshake.
- Проверьте, какой сертификат использует сервер:
openssl s_client -connect ваш_сервер:5061 -showcerts. - Сверьте CN и SAN в сертификате с тем, что пишут клиенты в настройках.
- Убедитесь, что цепочка CA передаётся полностью.
- Если клиенты — iOS/Android — проверьте, установлен ли сертификат в систему.
- Если сертификат самоподписанный — замените его на Let’s Encrypt за 10 минут.
- Если клиент старый — найдите его прошивку, обновите, или настройте отдельный порт с совместимым TLS.
Нет «идеального» сертификата. Есть только правильный для вашей ситуации. Не пытайтесь подогнать всё под один шаблон. Учитывайте клиентов, их возраст, их прошивки, их возможности. И помните: TLS — это не про безопасность «на бумаге». Это про то, чтобы звонки работали без сбоев. Если они не работают — вы сделали что-то не так. Исправьте — и всё заработает.
Информация в этой статье носит ознакомительный характер. Настройка SIP-инфраструктуры требует понимания вашей сети, безопасности и требований соответствия. Перед внедрением в продакшен рекомендуется проконсультироваться с сетевым инженером или специалистом по VoIP-системам.
