Варианты сертификатов для REST-сервера

[Elliot Dierksen]

Я согласен с
@Jonathan Schulenberg
по этому вопросу. Если у вас есть корневой центр сертификации и все необходимые промежуточные сертификаты центра сертификации, загруженные как tomcat-trust, то у меня это сработало. Как отмечает Jonathan, в противном случае это нарушило бы всю суть сертификатов и центров сертификации.

[Roger Kallberg]

Я согласен с
@Jonathan Schulenberg
и
@Elliot Dierksen
по этому вопросу. Мы выполняем REST-вызовы из CCX в ServiceNow, и, насколько я помню и вижу в хранилище доверия Tomcat, нам не приходилось загружать никаких серверных сертификатов, у нас есть только набор промежуточных или корневых сертификатов ЦС. Как написал Джонатан, я бы посоветовал обратиться в TAC и попросить их предоставить фактические доказательства того, что вам необходимо иметь серверный сертификат в этом хранилище доверия. ![Response Signature]

[Igor-Lukic]

Привет,
@Jonathan King
, откуда вы взяли цепочку сертификатов? Вы пробовали перехватить сетевой трафик при отправке REST-запроса? Я столкнулся с проблемой с публично подписанными сертификатами, когда автоматически предоставленная цепочка CA содержала неверные сертификаты, которые не входили в цепочку сертификатов, при открытии сервисного сертификата в Windows (например). Это стало очевидным при сравнении цепочки сертификатов, как показано в перехваченном трафике, с предоставленной цепочкой сертификатов. Как указали
@Jonathan Schulenberg
,
@Elliot Dierksen
и
@Roger Kallberg
, вам не следует требовать полную цепочку. С уважением Игорь

[Jonathan Schulenberg]

@Джонатан Кинг
написал:
Добавление сертификата конечной точки действительно решает проблему — даже без перезапуска кластера, как рекомендует система. Пожалуйста, перезапустите 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 чем-то другим.

[Roger Kallberg]

Недостаточно ли иметь сертификат(ы) ЦС, подписавший(е) сертификат, используемый получателем вызова REST API? Или используется самоподписанный сертификат? ![Response Signature]

[Jonathan King]

Привет, Роджер, К сожалению, нет. Согласно TAC: «UCCX требует, чтобы вся цепочка сертификатов (включая сертификат конечной точки) была загружена в хранилище ключей tomcat-trust, поскольку хранилище ключей Tomcat по умолчанию не содержит корневых сертификатов. Загрузка только промежуточных или корневых сертификатов без сертификата конечной точки недостаточна для проверки доверия в вызовах HTTPS REST».

[Nithin Eluvathingal]

У меня есть рабочий скрипт на UCCX, который выполняет REST-вызов к облачному SMS-шлюзу для отправки сообщений через HTTPS-соединение. Я не загружал сертификаты сервера, а загрузил только сертификат CA, который его подписал. Обязательно ли загружать сертификаты сервера в UCCX, чтобы соединение работало? Насколько я знаю, нет, перепроверьте с TAC. ![Response Signature]

[Jonathan King]

Не знаю, как у вас получилось! У меня выдает ошибку, пока не загрузится сертификат конечной точки.

[Jonathan Schulenberg]

Мой опыт совпадает с опытом
@Nithin Eluvathingal
. Мне никогда не приходилось загружать индивидуальный сертификат сервера, только цепочку выдающих ЦС. Какая версия CCX? И вы уверены, что загружены правильные корневые и промежуточные сертификаты ЦС? Может ли TAC подтвердить это утверждение однозначной документацией по продукту? Потому что для меня это звучит как ерунда, чтобы избежать поиска первопричины и дефекта. Так не работает проверка сертификатов в любом хранилище доверия Tomcat любого приложения Cisco collab на VOS (например, CUCM, IM&P, CUC, CCX).

[marcvazq]

@Roger Kallberg
Я работаю над интеграцией UCCX с Servicesnow, которая использует OAuth 2.0 в качестве метода аутентификации. Сервер Servicenow требует генерации токена перед созданием инцидента в своей системе. Мой вопрос: для этого необходимо загрузить в хранилище доверенных сертификатов UCCX только корневой и промежуточный сертификаты?

[Jonathan Schulenberg]

Цепочка сертификатов, используемая для установления соединения TLS, полностью отделена от токенов OAuth, используемых API. CCX также не имеет встроенной поддержки управления токенами OAuth. Если вы не можете использовать аутентификацию HTTP Basic (т. е. имя пользователя и пароль), вам необходимо написать внешний веб-сервис для управления токенами. Этот веб-сервис может либо вызываться скриптом CCX для получения текущего токена доступа, либо выступать в качестве посредника между CCX и SNOW для API.

[david.macias]

Джонатан, вы абсолютно точно выполняете аутентификацию OAuth «нативно» в CCX. Это немного похоже на хакерскую работу, когда токен сохраняется внутри CCX, но это возможно, и я делаю это для SFDC. Идеальный способ сделать это — это, безусловно, то, что вы предлагаете.
Что касается сертификатов, то, насколько я понимаю, вам действительно нужен только корневой сертификат, но я всегда загружаю корневые и промежуточные сертификаты. Дэвид Блог
|
Работа

[Jonathan King]

TAC ссылается на документацию, в которой говорится, что необходимо загрузить «всю цепочку», что, по моему мнению, с самого начала противоречит части цели PKI. Когда я пытаюсь выполнить вызов REST, доверяя только промежуточным/корневым сертификатам, я получаю следующий ответ: «java.io.IOException: Неверное имя хоста HTTPS: должно быть <имя хоста удалено>». Указанное имя хоста совпадает с URL-адресом сервера, на который я указываю. Сервер REST находится в Azure. URL-адрес сервера, на который я указываю, является CNAME перед многими записями A. Я попытался настроить поведение сеанса так, чтобы пропускать проверку имени хоста. Не совсем уверен, что сделал это правильно. То, как я это сделал сегодня, похоже, не влияет на поведение. Добавление сертификата конечной точки решает проблему — даже без перезапуска кластера, как указывает система. UCCX версии 12.5.1.11003-511

[Jonathan King]

Игорь, Я скачал цепочку через веб-браузер, просто перейдя по URL-адресу API и взяв сертификат из Firefox. Я сделаю захват пакетов и посмотрю, что смогу увидеть.