Процедура воссоздания/продления сертификата CUCM

Введение

В этом документе приведена рекомендуемая пошаговая процедура восстановления сертификатов, используемых в Cisco Unified Communications Manager (CUCM) версии, начиная с 8.x. Для того чтобы избежать нежелательных простоев, нужно также принять в рассмотрение функцию безопасности по умолчанию (ITL) и смешанный режим (CTL). Например, как избежать проблем с регистрацией телефона или ситуаций, когда телефоны не принимают изменения конфигурации или микропрограммное обеспечение.

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

Обзор

В этом документа рассматривается процесс восстановления сертификатов для следующих сервисов:

• (диспетчер вызовов Call Manager)
• CAPF (функция прокси центра сертификации)
• IPSEC
• Tomcat
• TVS (сервис проверки доверия)
• ITLRecovery (только для CUCM 10. X и старше)
• phone-vpn-trust
• phone-sast-trust
• phone-trust
• phone-ctl-trust

А также следующих сертификатов телефонов:

• LSC (локально значимые сертификаты)
• MIC (сертификаты, установленные производителем)

Используемые компоненты

Все выходные данные и снимки экранов, приведенные в этом документе, собраны с использованием CUCM версии 9.1(2)SU2a, однако представленная процедура может использоваться при работе с CUCM, начиная с версии 8.x. Различия, которые относятся к конкретным выпускам, упомянуты в соответствующих разделах.

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

Когда нужно восстанавливать сертификаты

Большинство сертификатов, используемых в CUCM после новой установки, являются самозаверяющими сертификатами, выпущенными (по умолчанию) на пять лет. Обращаем внимание на то, что в настоящее время пятилетний период времени нельзя сделать короче в CUCM. Однако центр сертификации (CA) может выпускать сертификаты, рассчитанные практически на любой срок действия.

Существуют также некоторые надежные сертификаты (такие как CAPF-trust и CallManager-trust), которые были загружены в устройство заранее и имеют более длинный срок действия. Например, сертификат Cisco Manufacturing CA предоставлен в доверенных хранилищах CUCM для определенных функций и имеет срок действия до 2029 года.

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

Далее приведен пример уведомления об окончании срока действия сертификата CUCM01.der, который станет недействительным в понедельник, 19 мая, в 14:46 на сервере CUCM02 в хранилище доверенных сертификатов tomcat-trust:

At Fri Sep 05 02:00:56 CEST 2014 on node 192.168.1.2, the following
    
    
SyslogSeverityMatchFound events generated:

SeverityMatch : Critical

MatchedEvent : Sep 5 02:00:06 CUCM02 local7 2 : 864: CUCM02.localdomain:
Sep 05 2014 00:00:06.433 UTC : %UC_CERT-2-CertValidfor7days:
%[Message=Certificate expiration Notification. Certificate name:CUCM01.der
Unit:tomcat-trust Type:own-cert Expiration:Mon May 19 14:46:]
[AppID=Cisco Certificate Monitor][ClusterID=][NodeID=CUCM02]:
Alarm to indicate that Certificate has Expired or Expires in less than seven days

AppID : Cisco Syslog Agent

ClusterID :

NodeID : CUCM02

TimeStamp : Fri Sep 05 02:00:16 CEST 2014

Если срок действия сертификатов служб (хранилища сертификатов, которые не имеют обозначения -trust) уже истек, их все еще можно восстановить. Помните, что просроченные сертификаты могут негативно повлиять на работу CUCM (это зависит от конфигурации кластера). Факторы рассматриваются в следующих разделах.

Влияние на сервисы, оказываемое хранилищем сертификатов

Для правильной работы системы очень важно, чтобы все сертификаты, используемые во всем кластере CUCM, своевременно обновлялись. Если срок действия сертификата истечет или он окажется недействительным, это может оказать значительное негативное влияние на нормальную работу системы. Далее приведен список возможных проблем, которые могут возникнуть, когда любой из указанных сертификатов оказывается недействительным или срок его действия истекает. Влияние может меняться в зависимости от настройки системы.

CallManager.pem

• TFTP оказывается недоверенным (телефоны не принимают подписанные файлы конфигурации и/или файлы ITL).
• На На Может быть нарушена работа телефонных служб.
• Магистрали протокола SIP или медиаресурсы (мосты конференц-связи, Media Termination Point (MTP), Xcoder и так далее) не будут регистрироваться или работать.
• Сбой запроса AXL.

Tomcat.pem

• Телефоны не могут получать доступ к сервисам HTTPs, размещенным на узле CUCM, таким как Corporate Directory.
• Проблемы с графическим веб-интерфейсом пользователя CUCM, например невозможность доступа к страницам сервиса с других узлов кластера.
•  Проблемы с функцией Extension Mobility или Extension Mobility Cross Clustr.

CAPF.pem

• Телефоны не проходят аутентификацию для Phone VPN, 802.1x или Phone Proxy. 
• Невозможно выпускать сертификаты LSC для телефонов.
• Зашифрованные файлы конфигурации не работают.

IPSec.pem

• Система аварийного восстановления (DRS) или платформа восстановления после отказа (DRF) может не работать надлежащим образом. 
• Туннели IPSec к шлюзу (GW) с другими кластерами CUCM не работают.

TVS (сервис проверки доверия)

• Телефон не может выполнить аутентификацию сервиса HTTPS. Телефон не может выполнить аутентификацию файлов конфигурации (в CUCM это может влиять практически на все).

phone-vpn-trust

• Телефонная сеть VPN не будет работать, потому что невозможно выполнить аутентификацию URL-адреса HTTPS сети VPN.

Примечание. Если этот объект не существует, не волнуйтесь. Такое происходит только в определенных конфигурациях.

phone-sast-trust

• Предыдущие CTL/eToken не смогут обновить или изменить CTL.

Примечание. Если этот объект не существует, не волнуйтесь. Такое происходит только в определенных конфигурациях.

phone-trust и phone-ctl-trust

• Сервисы Visual Voicemail для Unity или Unity Connection не будут работать.

Примечание. Если этот объект не существует, не волнуйтесь. Такое происходит только в определенных конфигурациях.

LSC и MIC

• Телефоны не регистрируются, не проходят аутентификацию в Phone VPN, Phone Proxy или 802.1x. 

Примечание. MIC по умолчанию имеется на большинстве моделей телефонов. LSC подписаны CAPF, по умолчанию срок их действия составляет пять лет. В некоторых программных клиентах, например в CIPC (Cisco IP Communicator) и Jabber, MIC не установлен.

Создание резервной копии DRS

Перед внесением таких значительных изменений рекомендуется создать резервную копию DRS. Резервные копии DRF CUCM содержат копии всех сертификатов, имеющихся в кластере. Описание всех процедур резервного копирования и восстановления приведено в документе Cisco Руководство по системному администрированию при восстановления после отказа для Cisco Unified Communications Manager.

Внимание.  : Не забывайте об ошибке с идентификатором Cisco CSCtn50405, Резервная копия DRF CUCM не содержит сертификаты.

Определение того, находится ли кластер в смешанном режиме

  Для того чтобы определить, в каком режиме работает кластер (CTL/безопасном/смешанном), выбираете Cisco Unified CM Administration > System > Enterprise Parameters > Cluster Security Mode (0 == Non-Secure; 1 == Mixed Mode) (Администрирование Cisco Unified CM > Система > Корпоративные параметры > Режим безопасности кластера (0 == небезопасный;1 == смешанный режим)).

Если кластер работает в смешанном режиме

Если кластер CUCM работает в смешанном режиме, это означает, что после внесения всех изменений в сертификаты необходимо будет обновить файл CTL. Описание того, как это сделать, приведено в руководстве Cisco по безопасности. Однако убедитесь, что у вас есть хотя бы один eToken, имевшийся на момент инициализации смешанного режима, и вы знаете пароль для этого eToken.

Примечание. Обновление CTL не происходит автоматически (как в случае с файлом ITL). Администратору необходимо выполнить его вручную с помощью либо клиента CTL, либо команды CLI.

В CUCM 10. X и более поздних версий перевести кластер в смешанный режим можно двумя способами:

• Команда CLI. Если используется этот метод, то файл CTL подписывается сертификатом CallManager.pem сервера Publisher.

  admin:show ctl
  The checksum value of the CTL file:
  0c05655de63fe2a042cf252d96c6d609(MD5)
  8c92d1a569f7263cf4485812366e66e3b503a2f5(SHA1)
  
  Length of CTL file: 4947
  The CTL File was last modified on Fri Mar 06 19:45:13 CET 2015
  
  [...]
  
          CTL Record #:1
                    ----
  BYTEPOS TAG             LENGTH  VALUE
  ------- ---             ------  -----
  1       RECORDLENGTH    2       1156
  2       DNSNAME         16      cucm-1051-a-pub
  3       SUBJECTNAME     62      CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
                                  ST=Malopolska;C=PL
  4       FUNCTION        2       System Administrator Security Token
  5       ISSUERNAME      62      CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
                                  ST=Malopolska;C=PL
  6       SERIALNUMBER    16      70:CA:F6:4E:09:07:51:B9:DF:22:F4:9F:75:4F:C5:BB
  7       PUBLICKEY       140
  8       SIGNATURE       128
  9       CERTIFICATE     694     E9 D4 33 64 5B C8 8C ED 51 4D 8F E5 EA 5B 6D 21
                                  A5 A3 8C 9C (SHA1 Hash HEX)
  10      IPADDRESS       4
  This etoken was used to sign the CTL file.

• Клиент CTL. Если используется этот метод, то файл CTL подписывается одним из аппаратных eToken.

  admin:show ctl
  The checksum value of the CTL file:
  256a661f4630cd86ef460db5aad4e91c(MD5)
  3d56cc01476000686f007aac6c278ed9059fc124(SHA1)
  
  Length of CTL file: 5728
  The CTL File was last modified on Fri Mar 06 21:48:48 CET 2015
  
  [...]
          CTL Record #:5
                    ----
  BYTEPOS TAG             LENGTH  VALUE
  ------- ---             ------  -----
  1       RECORDLENGTH    2       1186
  2       DNSNAME         1
  3       SUBJECTNAME     56      cn="SAST-ADN008580ef ";ou=IPCBU;o="Cisco Systems
  4       FUNCTION        2       System Administrator Security Token
  5       ISSUERNAME      42      cn=Cisco Manufacturing CA;o=Cisco Systems
  6       SERIALNUMBER    10      83:E9:08:00:00:00:55:45:AF:31
  7       PUBLICKEY       140
  9       CERTIFICATE     902     85 CD 5D AD EA FC 34 B8 3E 2F F2 CB 9C 76 B0 93
                                  3E 8B 3A 4F (SHA1 Hash HEX)
  10      IPADDRESS       4
  This etoken was used to sign the CTL file.

Примечание. Переключаться между методами можно с помощью смешанного режима CUCM с CTL без токенов.  

В зависимости от метода, используемого для защиты кластера, необходимо использовать подходящую процедуру обновления CTL. Либо повторно запустите клиент CTL, либо введите команду utils ctl update CTLfile в интерфейсе командной строки.

Проверка функции Security by Default в кластере

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

Использование функции «Подготовка кластера к возврату к версии до 8.0»

Эта функция очищает ITL на всех серверах, из-за чего телефоны будут доверять любому серверу TFTP. Когда для этого параметра установлено значение True, телефонные службы (например, функция Extension Mobility) НЕ будут работать. Однако пользователи по-прежнему смогут совершать и принимать простые телефонные вызовы.

Примечание. Изменение этого параметра вызывает СБРОС ВСЕХ ТЕЛЕФОНОВ. 

Сразу после установки этой функции все серверы TFTP должны быть перезапущены (для предоставления нового ITL), а все телефоны должны быть сброшены, чтобы заставить их запросить новый пустой ITL. Как только все изменения сертификатов будут внесены, а все необходимые сервисы будут перезапущены, этой функции снова можно будет задать значение False, перезапустить сервис TFTP и сбросить телефон (чтобы он мог получить действующий файл ITL). После этого все функции продолжат работать, как работали ранее.

Восстановление сертификатов в определенном порядке

Эта процедура предоставляет серверу TFTP допустимый/обновленный файл ITL от доверенного сервера TFTP, который доступен.

1. Остановите сервис TFTP на основном сервере TFTP.
2. Внесите изменения в сертификаты основного сервера TFTP (при необходимости).
3. Сбросьте телефоны (для получения нового файла ITL от дополнительного сервера TFTP). В зависимости от того, какие сертификаты восстанавливаются, это может произойти автоматически.
4. Как только телефоны снова загрузятся, запустите сервис TFTP основного сервера TFTP.
5. Внесите изменения в сертификаты на дополнительном сервере TFTP.
6. Сбросьте телефоны (для получения нового файла ITL от основного сервера TFTP).

Внимание.  : НЕ изменяйте сертификаты на обоих серверах TFTP одновременно. В этом случае у телефонов не будет доверенного сервера TFTP, из-за чего местному администратору придется вручную удалять файл ITL со всех телефонов.

Удаление и восстановление сертификатов в CUCM

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

Внимание.  : Не забывайте об ошибке с идентификатором Cisco CSCut58407. Устройства не должны запускаться при удалении CAPF/CallManager/TVS-trust.  

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

  

Внимание.  : Помните об идентификаторе ошибки Cisco CSCto86463. Удаленные сертификаты вновь появляются, невозможно удалить сертификаты из CUCM. Это проблема, при которой удаленные сертификаты продолжают отображаться после удаления. Следуйте этим инструкциям для обхода этого дефекта.

Восстановите сертификаты с помощью интерфейса командной строки

Внимание.  : Восстановление сертификатов вызывает автоматическое обновление файлов ITL в кластере, которое в свою очередь инициирует сброс программных телефонов во всем кластере, чтобы запустить обновление их локальных файлов ITL. В основном это имеет место при восстановлении сертификатов CAPF и CallManager, но может произойти и с другими хранилищами сертификатов в CUCM, например с Tomcat.

Восстановление CAPF

После восстановления сертификат CAPF автоматически загружает себя в хранилища CAPF-trust и CallManager-trust. Кроме того, у сертификата CAPF всегда есть заголовок Subject Name (Имя субъекта). Таким образом, использовавшиеся ранее сертификаты CAPF сохраняются и применяются для аутентификации.

set cert regen CAPF

Примечание. Если срок действия сертификата CAPF истекает, то телефоны, которые используют LSC, не смогут зарегистрироваться в CUCM, потому что CUCM будет отклонять их сертификат. Однако при этом можно генерировать новый LSC для телефона с новым сертификатом CAPF. При перезагрузке телефона он загружает конфигурацию и затем связывается с CAPF для обновления LSC. После обновления LSC телефон будет регистрироваться как обычно. Такая схема будет работать, если новый сертификат CAPF находится в файле ITL, а телефон загрузил сертификат, который подписал его, и доверяет этому сертификату (callmanager.pem).

 Восстановление CallManager

 После восстановления сертификат CallManager автоматически выгружает себя в хранилище CallManager-trust.

set cert regen CallManager

Восстановление IPsec

 После восстановления сертификат IPsec автоматически выгружает себя в хранилище ipsec-trust.

set cert regen ipsec

Восстановление Tomcat

  После восстановления сертификат Tomcat автоматически выгружает себя в хранилище tomcat-trust.

set cert regen tomcat

 Восстановление TVS

set cert regen TVS

Чего нужно ожидать

 При восстановлении сертификатов с помощью интерфейса командной строки система попросит подтвердить это изменение. Введите yes и нажмите Enter.

admin:set cert regen CAPF

WARNING: This operation will overwrite any CA signed certificate previously imported
 for CAPF

Proceed with regeneration (yes|no)? yes

Successfully Regenerated Certificate for CAPF.

You must restart services related to CAPF for the regenerated certificates to become active.

Удаление сертификатов с помощью интерфейса командной строки

Удалите сертификаты CAPF-trust

set cert delete CAPF <name of certificate>.pem

Удалите сертификаты CallManager-trust

set cert delete CallManager <name of certificate>.pem

Удалите сертификаты ipsec-trust

set cert delete ipsec <name of certificate>.pem

Удалите сертификаты Tomcat-trust

set cert delete tomcat <name of certificate>.pem

Удалите сертификаты TVS-trust

set cert delete TVS <name of certificate>.pem

  Восстановление сертификатов с помощью интерфейса командной строки

Восстановление CAPF

После восстановления сертификат CAPF автоматически загружает себя в хранилища CAPF-trust и CallManager-trust. Кроме того, сертификат CAPF всегда имеет уникальный заголовок Subject Name (Имя субъекта). Таким образом, ранее используемые сертификаты CAPF сохраняются и применяются для аутентификации.

OS Admin > Security > Certificate Management > Find > Click CAPF certificate > Regenerate

 Восстановление CallManager

После восстановления сертификат CAPF автоматически загружает себя в хранилище CallManager-trust.

OS Admin > Security > Certificate Management > Find > Click CallManager certificate > Regenerate

Восстановление IPsec

 После восстановления сертификат IPsec автоматически выгружает себя в хранилище ipsec-trust.

OS Admin > Security > Certificate Management > Find > Click ipsec certificate > Regenerate

Восстановление Tomcat

  После восстановления сертификат Tomcat автоматически выгружает себя в хранилище tomcat-trust.

OS Admin > Security > Certificate Management > Find > Click tomcat certificate > Regenerate

 Восстановление TVS

OS Admin > Security > Certificate Management > Find > Click TVS certificate > Regenerate

Удаление сертификатов с помощью графического веб-интерфейса пользователя

OS Admin > Security > Certificate Management > Find > Click X certificate within the
 '-trust' store > Remove/Delete

После восстановления/удаления сертификатов

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

Хранилище	Перезапускаемый сервис	Как
Tomcat	Tomcat	Интерфейс командной строки: utils service restart Cisco Tomcat
(диспетчер вызовов Call Manager)	(диспетчер вызовов Call Manager); Tftp; CTIManager	Графический веб-интерфейс пользователя: Cisco Unified Serviceability > Tools (Сервис) > Control Center - Feature Services (Центр управления — службы компонентов) > (Выберите сервер) > выберите Cisco CallManager > Restart (Перезапуск) Графический веб-интерфейс пользователя:  Cisco Unified Serviceability > Tools (Сервис) > Control Center - Feature Services (Центр управления — сервисы компонентов) > (Выберите сервер) > выберите Cisco Tftp > Restart (Перезапуск) Графический веб-интерфейс пользователя:  Cisco Unified Serviceability > Tools (Сервис) > Control Center - Feature Services (Центр управления — сервисы компонентов) > (Выберите сервер) > выберите Cisco CTIManager > Restart (Перезапуск)
CAPF	CAPF (только на Publisher)	Графический веб-интерфейс пользователя:  Cisco Unified Serviceability > Tools (Сервис) > Control Center - Feature Services (Центр управления — сервисы компонентов) > (Выберите сервер) > выберите Cisco Certificate Authority Proxy Function > Restart (Перезапуск)
TVS	Сервис проверки доверия (на соответствующем сервере)	Графический веб-интерфейс пользователя: Cisco Unified Serviceability > Tools (Сервис) > Control Center - Network Services (Центр управления — сетевые сервисы) > (Выберите сервер) > выберите Cisco Trust Verification Service > Restart (Перезапуск)
iPSEC	Cisco DRF Local (на всех узлах); Cisco DRF Master (на Publisher)	Интерфейс командной строки: utils service restart Cisco DRF Local Интерфейс командной строки: utils service restart Cisco DRF Master

Установка/обновление LSC на телефоне

После восстановления сертификата CAPF необходимо обновить сертификаты LSC для всех телефонов, имеющихся в кластере, заменив их сертификатом LSC, подписанным новым сертификатом CAPF.

1. Выберите CUCM Serviceability> Service Activation. Активируйте Cisco CTL Provider и Cisco Certificate Authority Proxy Function на сервере издателя.
2. В CCMAdmin CUCM выберите Device> Phone. Выберите IP-телефон, на котором необходимо подготовить сертификат LSC.
3. На странице настройки устройства в разделе Certificate Operation (Операции с сертификатом) выберите Install / Upgrade > By Null String.
4. Сохраните конфигурацию телефона в CCMAdmin и выберите Apply Config.

Если на телефоне возникают проблемы с установкой сертификата LSC, выполните на нем следующие действия:

После сброса телефона на самом телефоне выберите Settings > (6) Security Configuration > (4) LSC > **# (эта операция разблокирует графический интерфейс пользователя и позволяет перейти к следующему шагу) > Update (команда обновления появится только после выполнения предыдущего шага) > Submit.

Назначать сертификаты следует только беспроводным телефонам (7921/25). Для аутентификации беспроводных телефонов используются сторонние центры сертификации (CA).

Заключение

Если у вас возникла проблема или вам требуется помощь с выполнением этой процедуры, обратитесь в Центр технической поддержки Cisco (TAC). В этом случае подготовьте свою резервную копию DRF, поскольку она будет использоваться в качестве последнего средства для восстановления сервиса, если специалистам TAC не удастся сделать это другими способами.