SIP-TLS своими руками: настройка сертификатов и совместимость софтфонов

Внедрение шифрования в SIP-телефонию часто воспринимается как «обязательная галочка» для соответствия стандартам безопасности. На практике же это больная мозоль для администраторов. Вы включаете TLS на сервере, а половина парка телефонов просто перестает звонить, выдавая ошибки регистрации. Оставшиеся звонят, но с задержкой или обрывами.

Проблема не в самом протоколе SIP-TLS, а в нюансах реализации: от версии OpenSSL на сервере до капризов конкретных моделей телефонов и софтфонов. В этой статье я разберу, как настроить SIP-TLS так, чтобы это работало стабильно, какие сертификаты реально нужны и почему ваш Yealink или Zoiper может отвергать «правильный» с точки зрения криптографии конфиг.

Зачем вообще нужен SIP-TLS и что он шифрует

Прежде чем лезть в конфиги, важно понимать границы ответственности протокола. Многие ошибочно полагают, что включив TLS, они защитили весь разговор от прослушки. Это не так.

SIP-TLS шифрует только сигнальный трафик. Это команды: «я звоню», «абонент занят», «клавиша 1 нажата». Если вы не шифруете медиапоток (голос) отдельно через SRTP, то сам разговор может идти открытым текстом (RTP), даже если установка соединения прошла по TLS.

Зачем тогда мучиться с сертификатами? Главная цель — защита от перехвата учетных данных (логин/пароль) при регистрации и предотвращение подмены сервера (Man-in-the-Middle). Без TLS злоумышленник в вашей Wi-Fi сети может перехватить хеши паролей или перенаправить вызовы на свой шлюз.

Подготовка сертификатов: где чаще всего ошибаются

Настройка TLS начинается не с Asterisk или FreeSWITCH, а с генерации сертификатов. Здесь кроется 80% проблем совместимости.

Для работы SIP-TLS вам нужен самоподписанный сертификат (для внутренней сети) или сертификат от доверенного центра (Let’s Encrypt, Comodo и т.д.). Для внутренней IP-АТС самоподписанный вариант — самый частый сценарий.

Критические параметры при генерации

При создании CSR (Certificate Signing Request) или самоподписанного certs через OpenSSL, обратите внимание на следующие моменты, которые часто игнорируют:

• Common Name (CN): Должен строго совпадать с адресом, который прописан в телефоне. Если телефон стучится по IP-адресу (например, 192.168.1.10), то CN должен быть этим IP. Если по домену (sip.company.local) — то доменом. Несовпадение приведет к ошибке верификации на клиенте.
• Subject Alternative Name (SAN): Современные клиенты (особенно на iOS и новые версии Android) игнорируют CN и смотрят только в SAN. Если вы генерите сертификат вручную, обязательно добавьте расширение SAN с вашим IP или доменом.
• Алгоритм подписи: Забудьте про MD5 и SHA1. Используйте SHA256. Старые телефоны могут не понять SHA384/512, но SHA256 — золотой стандарт сейчас.
• Ключ: Минимум 2048 бит. 4096 бит надежнее, но некоторые слабые embedded-процессоры в дешевых телефонах могут тормозить при рукопожатии (handshake), увеличивая время до гудка.

После генерации у вас будет файл ключа (.key) и файл сертификата (.crt). Для многих АТС их нужно объединить в один файл .pem (сначала сертификат, потом ключ), но проверяйте документацию вашей конкретной платформы.

Настройка сервера: тонкости реализации

Рассмотрим настройку на примере классического связки (Asterisk/FreeSWITCH), так как принципы универсальны.

Вам нужно создать отдельный транспорт для TLS. Не пытайтесь запустить TLS на том же порту 5060, что и обычный SIP. Стандартный порт для SIP-TLS — 5061.

При настройке транспорта укажите пути к файлам сертификата и ключа. Критически важный момент — параметр verify_client (или аналог).

В идеальном мире вы должны требовать от клиента предъявления своего сертификата (mutual TLS). Но в реальности это адский труд: вам придется генерить и раскатывать персональные сертификаты на каждый телефон в офисе. Поэтому в 95% случаев используется схема Server-side TLS: сервер предъявляет сертификат клиенту, а клиент просто проверяет его достоверность (или отключает проверку).

Проблема цепочки доверия

Если вы используете самоподписанный сертификат, телефон не знает, доверять ли вашему серверу. У вас есть два пути:

1. Загрузить CA-сертификат на телефон. Это правильный путь. Вы экспортируете корневой сертификат (CA), который подписал ваш серверный cert, и загружаете его в хранилище доверенных сертификатов телефона.
2. Отключить проверку на телефоне. В настройках SIP-аккаунта на телефоне ставим галочку «Validate Server Certificate: No» или «Accept Any Certificate». Это работает, но снижает безопасность.

Совместимость клиентов: где ломается система

Вот здесь начинается настоящая рулетка. Протокол SIP-TLS описан в RFC, но каждый вендор трактует его по-своему. Ниже я собрал опыт работы с популярными клиентами и типичные «грабли».

Клиент / Устройство	Особенности поведения	Рекомендация
Yealink (T4/T5 серии)	Требовательны к CN сертификата. Если в телефоне указан IP, а в сертификате домен — регистрация не пройдет. Старые прошивки не поддерживают TLS 1.2.	Обновить прошивку до последней стабильной. В конфиге телефона явно указать tls.verify_server = 1 и загрузить CA-сертификат через веб-интерфейс.
Grandstream (GXP серии)	Часто игнорируют настройки TLS, если не перезагрузить телефон полностью (power cycle). Чувствительны к формату PEM (порядок сертификата и ключа).	Использовать формат PEM, где сначала идет cert, затем key. Если не работает — попробовать сменить порт на нестандартный (не 5061), иногда помогает обойти блокировки фаервола телефона.
Cisco (SPA/CP серии)	Очень строгая валидация. Могут требовать, чтобы сертификат сервера был подписан известным CA. Самоподписанные часто отвергают без явного импорта CA.	Лучше использовать платный сертификат от публичного CA (например, Let’s Encrypt), если телефон имеет доступ в интернет для проверки CRL/OCSP. Либо отключать валидацию в настройках профиля.
Softphones (Zoiper, 3CX, Linphone)	На мобильных ОС (iOS/Android) используют системное хранилище сертификатов. На ПК — свое. Zoiper на iOS может не видеть самоподписанные корни.	На iOS проще всего отключить проверку сертификата в настройках аккаунта Zoiper («Validate Certificate» -> Off). Для корпоративного использования — разворачивать корневой сертификат через MDM-профиль.
Fanvil	Хорошо работают с TLS, но имеют баг с длиной имени хоста в сертификате. Если CN слишком длинный, могут не подключиться.	Использовать IP-адрес в качестве CN или короткий поддомен.

Частые ошибки и способы их решения

Если вы все настроили, а звонков нет, идите по этому чек-листу. Это сэкономит вам часы отладки.

1. Ошибка «Handshake Failed» или «SSL Error»

Самая частая причина — несовпадение версий протоколов. Сервер может пытаться использовать TLS 1.3, а старый телефон понимает только TLS 1.0 или 1.1.
Решение: На сервере в настройках транспорта явно разрешите старые версии протоколов для совместимости (например, ssl_protocols TLSv1 TLSv1.1 TLSv1.2), но только во внутренней сети. Для внешних подключений оставляйте только TLS 1.2+.

2. Бесконечная регистрация

Телефон отправляет REGISTER, сервер отвечает, но телефон сбрасывает соединение.
Причина: Проблема с MTU. Пакеты TLS больше обычных UDP-пакетов из-за заголовков шифрования. Если в сети есть узкие места или специфичные фаерволы, большие пакеты могут теряться.
Решение: Попробуйте уменьшить размер SIP-пакетов или проверить MTU на интерфейсах. Также проверьте, не блокирует ли фаервол порт 5061.

3. «Certificate Expired» на новом сертификате

Вы перевыпустили сертификат, положили его на сервер, перезапустили службу, но телефоны пишут, что сертификат истек.
Причина: Кеширование. Телефоны (особенно Android) могут кешировать SSL-сессии или сами сертификаты.
Решение: На телефоне нужно не просто перерегистрировать аккаунт, а полностью удалить профиль SIP и создать заново. В некоторых случаях помогает смена пароля пользователя, чтобы форсировать новую аутентификацию.

4. Односторонняя слышимость

Сигнал идет по TLS (порт 5061), а медиа (RTP) пытается пойти по UDP на стандартных портах, которые закрыты политикой безопасности.
Решение: Убедитесь, что в настройках телефона включен SRTP (шифрование голоса), если вы хотите полной защиты. Если SRTP не нужен, просто откройте диапазон RTP-портов на фаерволе для IP-адреса АТС.

Сценарии выбора: как сделать правильно в вашей ситуации

Не существует универсальной настройки. Выбор стратегии зависит от того, где находятся телефоны.

Сценарий А: Офисная локальная сеть (LAN)

Телефоны и сервер в одной сети. Интернет есть, но звонки идут внутри.

• Сертификат: Самоподписанный.
• Валидация: Отключена на телефонах (для простоты) ИЛИ загружен CA-сертификат на каждый аппарат (для безопасности).
• Шифрование: TLS 1.2.
• Совет: Не усложняйте. Если это закрытый периметр, главная угроза — не внешний хакер, а «случайный» сосед по Wi-Fi. Включите TLS, но не мучайтесь с публичными центрами сертификации.

Сценарий Б: Удаленные сотрудники (через Интернет)

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

• Сертификат: Строго от доверенного центра (Let’s Encrypt бесплатно подойдет идеально).
• Валидация: Включена. Телефоны должны проверять сертификат.
• Причина: В публичной сети высок риск MITM-атаки. Если телефон не проверит сертификат, он может отдать пароль фейковой АТС.
• Совет: Используйте доменное имя для подключения, а не IP. IP-адреса меняются, а сертификат, выданный на IP, перевыпускать при каждой смене провайдера — боль.

Сценарий В: Смешанный парк (Старые + Новые телефоны)

У вас есть современные Yealink T5 и старые SIP-трубки 10-летней давности.

• Решение: Поднимите два транспорта на АТС. Один на порту 5060 (без шифрования) дляLegacy-устройств в защищенной VLAN. Второй на 5061 (TLS) для всех остальных.
• Важно: Никогда не заставляйте старые устройства работать по TLS через «костыли» с отключением всех проверок безопасности — это часто приводит к нестабильности. Лучше изолировать их в отдельную сеть.

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

Не верьте статусу «Registered» на экране телефона. Это еще не значит, что соединение защищено.

1. Wireshark. Запустите снифер на сервере или на клиенте. Отфильтруйте трафик по порту 5061. Вы должны видеть поток TLSv1.2. Если вы видите текст команд SIP (INVITE, REGISTER) в открытом виде — TLS не работает, вы смотрите не тот порт или трафик.
2. Команда openssl. С компьютера, с которого работает телефон, выполните:

   openssl s_client -connect IP_АТС:5061 -showcerts

   Вы должны увидеть вывод цепочки сертификатов и сообщение Verify return code: 0 (ok), если у вас установлен корневой сертификат. Если видите ошибки верификации — телефон тоже их увидит.

3. Логи АТС. Включите отладочный уровень логирования (debug) для SIP. При регистрации по TLS в логах должно быть упоминание успешного рукопожатия (handshake complete).

Итоговые рекомендации

Внедрение SIP-TLS — это баланс между безопасностью и удобством поддержки.

Если вы настраиваете систему для себя или небольшого офиса:
1. Используйте самоподписанный сертификат с SHA256.
2. Пропишите в CN IP-адрес сервера.
3. На телефонах отключите галочку «Validate Certificate», чтобы не возиться с раскаткой CA.
4. Обязательно обновите прошивки телефонов до версий, поддерживающих TLS 1.2.

Если вы провайдер или настраиваете систему с доступом из интернета:
1. Используйте бесплатный сертификат Let’s Encrypt.
2. Настройте автообновление сертификата (скриптом certbot), так как они живут 90 дней.
3. Требуйте от клиентов использования доменного имени.

Помните: шифрование сигнального канала не спасет от плохих паролей. Даже с TLS используйте сложные пароли на SIP-аккаунтах и меняйте их при увольнении сотрудников. TLS — это лишь один из слоев защиты, а не панацея.

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