Skip to content
  • Категории
  • Последние
  • Метки
  • Популярные
  • Пользователи
  • Группы
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • По умолчанию (Нет скина)
  • Нет скина
Collapse

Networks Engineering

  1. Главная
  2. Совместная работа (Collaboration)
  3. Контакт-центр (Contact Center)
  4. Варианты сертификатов для REST-сервера

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

Запланировано Прикреплена Закрыта Перенесена Контакт-центр (Contact Center)
15 Сообщения 0 Posters 0 Просмотры
  • Сначала старые
  • Сначала новые
  • По количеству голосов
Ответить
  • Ответить, создав новую тему
Авторизуйтесь, чтобы ответить
Эта тема была удалена. Только пользователи с правом управления темами могут её видеть.
  • R Не в сети
    R Не в сети
    Roger Kallberg
    написал в отредактировано
    #6

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

    1 ответ Последний ответ
    0
    • J Не в сети
      J Не в сети
      Jonathan King
      написал в отредактировано
      #7

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

      1 ответ Последний ответ
      0
      • N Не в сети
        N Не в сети
        Nithin Eluvathingal
        написал в отредактировано
        #8

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

        1 ответ Последний ответ
        0
        • J Не в сети
          J Не в сети
          Jonathan King
          написал в отредактировано
          #9

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

          1 ответ Последний ответ
          0
          • J Не в сети
            J Не в сети
            Jonathan Schulenberg
            написал в отредактировано
            #10

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

            1 ответ Последний ответ
            0
            • M Не в сети
              M Не в сети
              marcvazq
              написал в отредактировано
              #11

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

              1 ответ Последний ответ
              0
              • J Не в сети
                J Не в сети
                Jonathan Schulenberg
                написал в отредактировано
                #12

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

                1 ответ Последний ответ
                0
                • D Не в сети
                  D Не в сети
                  david.macias
                  написал в отредактировано
                  #13

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

                  1 ответ Последний ответ
                  0
                  • J Не в сети
                    J Не в сети
                    Jonathan King
                    написал в отредактировано
                    #14

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

                    1 ответ Последний ответ
                    0
                    • J Не в сети
                      J Не в сети
                      Jonathan King
                      написал в отредактировано
                      #15

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

                      1 ответ Последний ответ
                      0

                      Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.

                      Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.

                      С вашими комментариями этот пост может стать ещё лучше 💗

                      Зарегистрироваться Войти
                      Ответить
                      • Ответить, создав новую тему
                      Авторизуйтесь, чтобы ответить
                      • Сначала старые
                      • Сначала новые
                      • По количеству голосов


                      • Войти

                      • Нет учётной записи? Зарегистрироваться

                      • Login or register to search.
                      • Первое сообщение
                        Последнее сообщение
                      0
                      • Категории
                      • Последние
                      • Метки
                      • Популярные
                      • Пользователи
                      • Группы