У меня есть скрипт UCCX, который отправляет REST-вызовы на HTTPS-сервер. Сертификат на HTTPS-сервере часто меняется. Мне интересно, какие у меня есть варианты, кроме ручной загрузки нового сертификата Tomcat-Trust каждый раз, когда он меняется. 1) Можно ли автоматически отправлять новые сертификаты в хранилище Tomcat-Trust через REST API или каким-либо другим способом? 2) Можно ли отключить проверку сертификатов для HTTPS REST-вызова? Я понимаю, что это сводит на нет половину смысла использования HTTPS. Но половина все же лучше, чем ничего. Согласно документации по шагу «Make Rest Call», установка переменной сессии
cc_accept_all_hosts
отменяет проверку имени хоста, но все равно требует, чтобы сертификат находился в хранилище доверенных сертификатов. 3) Есть ли способ сделать так, чтобы UCCX требовал только промежуточные/корневые сертификаты для HTTPS-сервера, а не сам сертификат конечной точки? 4) Есть ли другие идеи, о которых я не подумал?

]]>https://sla247.ru/forum/topic/1080/варианты-сертификатов-для-rest-сервераRSS for NodeFri, 15 May 2026 14:32:16 GMTMon, 16 Feb 2026 18:31:50 GMT60Игорь, Я скачал цепочку через веб-браузер, просто перейдя по URL-адресу API и взяв сертификат из Firefox. Я сделаю захват пакетов и посмотрю, что смогу увидеть.

]]>https://sla247.ru/forum/post/7650https://sla247.ru/forum/post/7650Mon, 16 Feb 2026 18:32:04 GMTTAC ссылается на документацию, в которой говорится, что необходимо загрузить «всю цепочку», что, по моему мнению, с самого начала противоречит части цели PKI. Когда я пытаюсь выполнить вызов REST, доверяя только промежуточным/корневым сертификатам, я получаю следующий ответ: «java.io.IOException: Неверное имя хоста HTTPS: должно быть <имя хоста удалено>». Указанное имя хоста совпадает с URL-адресом сервера, на который я указываю. Сервер REST находится в Azure. URL-адрес сервера, на который я указываю, является CNAME перед многими записями A. Я попытался настроить поведение сеанса так, чтобы пропускать проверку имени хоста. Не совсем уверен, что сделал это правильно. То, как я это сделал сегодня, похоже, не влияет на поведение. Добавление сертификата конечной точки решает проблему — даже без перезапуска кластера, как указывает система. UCCX версии 12.5.1.11003-511

]]>https://sla247.ru/forum/post/7649https://sla247.ru/forum/post/7649Mon, 16 Feb 2026 18:32:03 GMTДжонатан, вы абсолютно точно выполняете аутентификацию OAuth «нативно» в CCX. Это немного похоже на хакерскую работу, когда токен сохраняется внутри CCX, но это возможно, и я делаю это для SFDC. Идеальный способ сделать это — это, безусловно, то, что вы предлагаете.
Что касается сертификатов, то, насколько я понимаю, вам действительно нужен только корневой сертификат, но я всегда загружаю корневые и промежуточные сертификаты. Дэвид Блог
|
Работа

]]>https://sla247.ru/forum/post/7648https://sla247.ru/forum/post/7648Mon, 16 Feb 2026 18:32:02 GMTЦепочка сертификатов, используемая для установления соединения TLS, полностью отделена от токенов OAuth, используемых API. CCX также не имеет встроенной поддержки управления токенами OAuth. Если вы не можете использовать аутентификацию HTTP Basic (т. е. имя пользователя и пароль), вам необходимо написать внешний веб-сервис для управления токенами. Этот веб-сервис может либо вызываться скриптом CCX для получения текущего токена доступа, либо выступать в качестве посредника между CCX и SNOW для API.

]]>https://sla247.ru/forum/post/7647https://sla247.ru/forum/post/7647Mon, 16 Feb 2026 18:32:01 GMT@Roger Kallberg
Я работаю над интеграцией UCCX с Servicesnow, которая использует OAuth 2.0 в качестве метода аутентификации. Сервер Servicenow требует генерации токена перед созданием инцидента в своей системе. Мой вопрос: для этого необходимо загрузить в хранилище доверенных сертификатов UCCX только корневой и промежуточный сертификаты?

]]>https://sla247.ru/forum/post/7646https://sla247.ru/forum/post/7646Mon, 16 Feb 2026 18:32:00 GMTМой опыт совпадает с опытом
@Nithin Eluvathingal
. Мне никогда не приходилось загружать индивидуальный сертификат сервера, только цепочку выдающих ЦС. Какая версия CCX? И вы уверены, что загружены правильные корневые и промежуточные сертификаты ЦС? Может ли TAC подтвердить это утверждение однозначной документацией по продукту? Потому что для меня это звучит как ерунда, чтобы избежать поиска первопричины и дефекта. Так не работает проверка сертификатов в любом хранилище доверия Tomcat любого приложения Cisco collab на VOS (например, CUCM, IM&P, CUC, CCX).

]]>https://sla247.ru/forum/post/7645https://sla247.ru/forum/post/7645Mon, 16 Feb 2026 18:31:59 GMTНе знаю, как у вас получилось! У меня выдает ошибку, пока не загрузится сертификат конечной точки.

]]>https://sla247.ru/forum/post/7644https://sla247.ru/forum/post/7644Mon, 16 Feb 2026 18:31:58 GMTУ меня есть рабочий скрипт на UCCX, который выполняет REST-вызов к облачному SMS-шлюзу для отправки сообщений через HTTPS-соединение. Я не загружал сертификаты сервера, а загрузил только сертификат CA, который его подписал. Обязательно ли загружать сертификаты сервера в UCCX, чтобы соединение работало? Насколько я знаю, нет, перепроверьте с TAC. ![Response Signature]

]]>https://sla247.ru/forum/post/7643https://sla247.ru/forum/post/7643Mon, 16 Feb 2026 18:31:57 GMTПривет, Роджер, К сожалению, нет. Согласно TAC: «UCCX требует, чтобы вся цепочка сертификатов (включая сертификат конечной точки) была загружена в хранилище ключей tomcat-trust, поскольку хранилище ключей Tomcat по умолчанию не содержит корневых сертификатов. Загрузка только промежуточных или корневых сертификатов без сертификата конечной точки недостаточна для проверки доверия в вызовах HTTPS REST».

]]>https://sla247.ru/forum/post/7642https://sla247.ru/forum/post/7642Mon, 16 Feb 2026 18:31:56 GMTНедостаточно ли иметь сертификат(ы) ЦС, подписавший(е) сертификат, используемый получателем вызова REST API? Или используется самоподписанный сертификат? ![Response Signature]

]]>https://sla247.ru/forum/post/7641https://sla247.ru/forum/post/7641Mon, 16 Feb 2026 18:31:55 GMT@Джонатан Кинг
написал:
Добавление сертификата конечной точки действительно решает проблему — даже без перезапуска кластера, как рекомендует система. Пожалуйста, перезапустите CCX Engine, чтобы мы не бегали по кругу. Также убедитесь, что вы загрузили сертификат в издатель и что узел активен для тестирования, чтобы максимально сузить область поиска. (Это не исключает путаницу с тем, как сертификаты могут выйти из синхронизации между Informix и файловой системой). Я согласен, что стоит проверить, соответствует ли цепочка сертификатов в PCAP той, которую вы загрузили. Хорошая идея
[, @Igor-Lukic]
. TAC также должен иметь возможность просматривать подробную информацию о сертификатах в журналах безопасности Tomcat, если я правильно помню. На какой документ ссылается TAC? Если это
«Настройка управления сертификатами решения UCCX»
и конкретно эта фраза, то из контекста довольно ясно, что автор имел в виду все выдающие сертификаты органы — корневые и промежуточные — а не сертификат идентификации сервера, подписанный CA. Однако формулировка не идеальна и допускает подобные недоразумения. Также следует указать «Tomcat-trust» вместо «Tomcat keystore»; это не одно и то же. Вся цепочка сертификатов должна быть загружена в хранилище ключей платформы Tomcat, доступное через страницу администрирования ОС, поскольку хранилище ключей Tomcat по умолчанию не содержит корневых сертификатов. Инженер TAC должен на мгновение остановиться и критически подумать о последствиях того, что он утверждает. Если вы столкнулись с препятствием в виде инженера и его менеджера, обратитесь к своей команде Cisco. Любой, кто утверждает, что это ожидаемое поведение, должен быть выгнан из комнаты со смехом. Срок действия сертификатов уже ограничен 13 месяцами (90 днями при использовании Let's Encrypt) и
к 2029 году сократится до 47 дней
. Если CCX потребует ежемесячного окна для технического обслуживания, это будет невозможно с операционной точки зрения. Даже сейчас это означало бы, что вам придется мириться с перебоями в работе и запросами на экстренные изменения каждый раз, когда CCX подключается к какому-либо серверу (например, к любому SaaS-продукту, который вы не можете контролировать) и обновляет свой серверный сертификат! Бизнес никогда не потерпит этого; IT-отделу будет поручено заменить CCX чем-то другим.

]]>https://sla247.ru/forum/post/7640https://sla247.ru/forum/post/7640Mon, 16 Feb 2026 18:31:54 GMTПривет,
@Jonathan King
, откуда вы взяли цепочку сертификатов? Вы пробовали перехватить сетевой трафик при отправке REST-запроса? Я столкнулся с проблемой с публично подписанными сертификатами, когда автоматически предоставленная цепочка CA содержала неверные сертификаты, которые не входили в цепочку сертификатов, при открытии сервисного сертификата в Windows (например). Это стало очевидным при сравнении цепочки сертификатов, как показано в перехваченном трафике, с предоставленной цепочкой сертификатов. Как указали
@Jonathan Schulenberg
,
@Elliot Dierksen
и
@Roger Kallberg
, вам не следует требовать полную цепочку. С уважением Игорь

]]>https://sla247.ru/forum/post/7639https://sla247.ru/forum/post/7639Mon, 16 Feb 2026 18:31:53 GMTЯ согласен с
@Jonathan Schulenberg
и
@Elliot Dierksen
по этому вопросу. Мы выполняем REST-вызовы из CCX в ServiceNow, и, насколько я помню и вижу в хранилище доверия Tomcat, нам не приходилось загружать никаких серверных сертификатов, у нас есть только набор промежуточных или корневых сертификатов ЦС. Как написал Джонатан, я бы посоветовал обратиться в TAC и попросить их предоставить фактические доказательства того, что вам необходимо иметь серверный сертификат в этом хранилище доверия. ![Response Signature]

]]>https://sla247.ru/forum/post/7638https://sla247.ru/forum/post/7638Mon, 16 Feb 2026 18:31:52 GMTЯ согласен с
@Jonathan Schulenberg
по этому вопросу. Если у вас есть корневой центр сертификации и все необходимые промежуточные сертификаты центра сертификации, загруженные как tomcat-trust, то у меня это сработало. Как отмечает Jonathan, в противном случае это нарушило бы всю суть сертификатов и центров сертификации.

]]>https://sla247.ru/forum/post/7637https://sla247.ru/forum/post/7637Mon, 16 Feb 2026 18:31:51 GMT