Создание запроса на сертификат

Что происходит на практике

1. Client Hello – клиент начинает общение с сервером отсылая информацию о предпочитаемой версии протокола TLS, набора поддерживаемых шифров (Cipher Spec), и случайного простого числа (client random), необходимого в дальнейшем для генерации общего ключа симметричного шифрования.

   Что такое Cipher Spec? В процессе установки соединения, клиент и сервер должны договориться о: какой алгоритм использовать для обмена ключами (например, RSA – Риверт-Шамир-Адлеман, DH – Диффи-Хеллмана, ECDH – Диффи-Хеллмана на эллиптических кривых, и др.), какой алгоритм использовать для шифрования данных (AES – Advanced Encryption Standard, 3DES – Tripple Data Encryption Algorithm, и др.), какую криптографическую хэш-функцию использовать для генерации Message Authentication Code (SHA-256, SHA-384, SHA-512 – Secure Hash Algorithm с соответствующей длиной строки в битах с хэшем, и др.).

   Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.

2. Server Hello – сервер отвечает выбранной версией протокола и выбранным из предложенного набора шифром, которые будут непосредственно использоваться, своим случайным простым числом (server random) и идентификатором сессии.

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

3. Certificate – сервер отправляет свой сертификат, а клиент производит проверку подписи удостоверяющего центра, проверку доверия к удостоверяющему центру, проверку указанного домена сайта с фактическим, срока действия, проверяет не был ли сертификат отозван.

   Что представляет из себя сертификат? Сертификат – это открытый ключ и другая информация о его владельце, а также Электронная Цифровая Подпись (ЭЦП) доверенного центра.

   Как работает ЭЦП? При создании ЭЦП хэш данных, которые подписываются, шифруется закрытым ключом, в отличие от обычного ассиметричного шифрования, где зашифровка выполняется открытым ключом. Таким образом, если вам удалось расшифровать открытым ключом хэш, и он оказался идентичен хэшу из данных, – вы можете быть уверены что: подпись была сделана именно владельцем приватного ключа, открытый ключ которого вы используете; данные, которые были подписаны, не изменились с момента подписания.

   Но как удостовериться, что открытый ключ принадлежит не злоумышленнику? Существуют корневые удостоверяющие центры (Root Certificate Authority или просто CA – Certificate Authority), которым доверяют все участники обмена информацией. Если в цепочке подписания сертификата сервера есть подпись корневого CA (мы можем проверить ее с помощью открытого ключа CA), то мы можем ему доверять. При этом сертификаты (открытые ключи) корневых CA распространяются посредством включения их в операционную систему или браузер поставщиками. Также стоит отметить, что сертификат может быть подписан сертификатом, который подписан в свою очередь другим сертификатом – это цепочка подписания.

   Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).

4. Server Key Exchange – этот этап происходит не всегда, только если необходимы дополнительные данные для создания симметричного ключа при выбранном алгоритме. Например, при обмене ключами RSA этот шаг пропускается и для обмена общим ключ передается от клиента серверу зашифрованным открытым ключом сервера из его сертификата. Однако в этой статье рассмотрим более надежный алгоритм Диффи-Хеллмана. Сервер отправляет числа p (большое простое число) и g (может быть маленьким), а также рассчитанное число Y_s=g^{случайно выбранное сервером число}mod p, где mod – это операция нахождения остатка от деления. В свою очередь клиент также рассчитывает Y_c=g^{случайно выбранное клиентом число}mod p. После этого сервер считает Y_c^{случайно выбранное сервером число}mod p, а клиент Y_s^{случайно выбранное клиентом число}mod p, в результате чего у клиента и сервера получается одинаковое число. Разберем на примере:

5. Server Hello Done – сервер сообщает, что начальный этап установки соединения завершен

6. Client Key Exchange – как было уже сказано выше, когда сервер передал числа p, g, Y_s в Server Key Echange, клиент передает свое число Y_c в Client Key Exchange. Вычисленное в конце общее одинаковое число используется для создания pre-master secret – предварительного разделяемого ключа. На основании client random, server random и pre-master secret псевдослучайная функция выдает симметричный ключ и ключ вычисления MAC. Таким образом клиент и сервер имеют все необходимое для начала обмена полезной информацией.

7. Change Cipher Spec – клиент говорит серверу, что он готов перейти на защищенное соединение.

8. Finished – клиент зашифровывает симметричным ключом первое сообщение с MAC.

9. Change Cipher Spec – сервер проверяет сообщение Finished от клиента и отправляет в ответ свою готовность к защищенному соединению.

10. Finished – аналогично клиенту, сервер отправляет тестовое зашифрованное сообщение

11. После этого соединение считается установленным, и происходит передача полезной информации

12. close_notify – служебное сообщение, которое одна сторона отправляет другой, как уведомление о том, что считаетсоединение разорванным и не будет принимать больше сообщения. Другая сторона в ответ обязана послать аналогичное сообщение close_notify.

Вариант 1: создать csr

Первое, что нужно сделать, – это создать 2048-битную пару ключей RSA локально. Эта пара будет содержать как ваш закрытый, так и открытый ключ. Вы можете использовать инструмент Java key или другой инструмент, но мы будем работать с OpenSSL.

Чтобы создать открытый и закрытый ключ с запросом на подпись сертификата (CSR), выполните следующую команду OpenSSL:

openssl req –out certificatesigningrequest.csr -new -newkey rsa:2048 -nodes -keyout privatekey.key

Что эта команда означает:

• openssl – активирует программное обеспечение OpenSSL
• req – указывает, что мы хотим CSR
• –out – указывает имя файла, в котором будет сохранен ваш CSR. У нас в примере это certificatesigningrequest.csr
• –new –newkey – создать новый ключ
• rsa:2048 – cгенерировать 2048-битный математический ключ RSA
• –nodes – нет DES, то есть не шифровать закрытый ключ в PKCS#12 файл
• –keyout – указывает домен, для которого вы генерируете ключ

Далее ваша система должна запустить текстовую анкету для заполнения, которую мы описывали в таблице выше:

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

После завершения работы программы вы сможете найти файл CSR в вашем рабочем каталоге. Запрос на подпись сертификата, сгенерированный с помощью OpenSSL, всегда будет иметь формат файла .csr. Чтобы найти в папке все файлы этого формата используйте команду

ls *.csr

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

Также вы можете открыть файл .csr в текстовом редакторе, например nano, чтобы просмотреть сгенерированный буквенно-цифровой код.

sudo nano your_domain.csr

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

openssl req -in server.csr -noout -text

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

Выпускаем собственные сертификаты

Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем “password” длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:

openssl genrsa -aes256 -passout pass:password -out CA-private-key.key 4096

Нет какого-то принятого стандарта расширений для файлов, связанных с сертификатами. Мы будем использовать:

Далее создадим новый запрос на подпись сертификата CA-certificate-signing-request.csr, передавая информацию о субъекте “CN=Certificate authority” (если не указывать ключ -subj вас попросят указать: Сountry (C), Locality (L), Organisation (O), Organisation Unit (OU), Common Name (CN), Email, Challenge password – все поля, кроме CN опциональны), приватный ключ и пароль от него:

openssl req -new -key CA-private-key.key -passin pass:password -subj "/CN=Certificate authority/" -out CA-certificate-signing-request.csr t $3

Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.

openssl x509 -req -in CA-certificate-signing-request.csr -signkey CA-private-key.key -passin pass:password -days 1 -out CA-self-signed-certificate.pempemE

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

openssl genrsa -aes256 -passout pass:password -out Server-private-key.key 4096
openssl req -new -key Server-private-key.key -passin pass:password -subj "/CN=localhost/" -out Server-certificate-signing-request.csrt $3

openssl genrsa -aes256 -passout pass:password -out Client-private-key.key 4096
openssl req -new -key Client-private-key.key -passin pass:password -subj "/CN=Client/" -out Client-certificate-signing-request.csr

Подпишем запросы нашим сертификатом CA. Ключ CAcreateserial отвечает за создание файла (в данном случае CA-self-signed-certificate.srl) , в котором будет храниться серийный номер для следующего подписываемого этим сертификатом запроса. Серийный номер для текущего же сертификата сгенерируется случайно.

openssl x509 -req -in Server-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -CAcreateserial -days 1 -out Server-certificate.pemt $4
openssl x509 -req -in Client-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -days 1 -out Client-certificate.pem

После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем “password”:

openssl pkcs12 -export -in Server-certificate.pem -inkey Server-private-key.key -passin pass:password -passout pass:password -out Server-keystore.p12      

Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:

keytool -import -file CA-self-signed-certificate.pem -keystore Server-truststore.p12 -storetype PKCS12 -storepass password -noprompt    

Для удобства, все описанные выше действия упакованы в bash script.

Закрытый ключ

Закрытый ключ кодируется и создается в формате PEM на основе Base-64, который не читается человеком. Вы можете открыть его в любом текстовом редакторе, но все, что вы увидите, это несколько десятков строк, которые кажутся случайными символами, заключенными в открывающие и закрывающие заголовки. Ниже приведен пример закрытого ключа:

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQCVqGpH2S7F0CbEmQBgmbiDiOOGxhVwlG yY/6OBQoPKcx4Jv2h
vLz7r54ngjaIqnqRNP7ljKjFLp5zhnAu9GsdwXbgLPtrmMSB MVFHTJvKjQ eY9p
dWA3NbQusM9uf8dArm 3VrZxNHQbVGXOIAPNHTO08cZHMSqIDQ6OvLma7wIDAQAB
AoGAbxKPzsNh826JV2A253svdnAibeSWBPgl7kBIrR8QWDCtkH9fvqpVmHa 6pO5
5bShQyQSCkxa9f2jnBorKK4 0K412TBM/SG6Zjw DsZd6VuoZ7P027msTWQrMBxg
Hjgs7FSFtj76HQ0OZxFeZ8BkIYq0w 7VQYAPBWEPSqCRQAECQQDv09M4PyRVWSQM
S8Rmf/jBWmRnY1gPPEOZDOiSWJqIBZUBznvOPOOQSH6B vee/q5edQA2OIaDgNmn
AurEtUaRAkEAn7/65w Tewr89mOM0RKMVpFpwNfGYAj3kT1mFEYDq iNWdcSE6xE
2H0w3YEbDsSayxc36efFnmr//4ljt4iJfwJAa1pOeicJhIracAaaa6dtGl/0AbOe
f3NibugwUxIGWkzlXmGnWbI3yyYoOta0cR9fvjhxV9QFomfTBcdwf40FgQJAH3MG
DBMO77w8DK2QfWBvbGN4NFTGYwWg52D1Bay68E759OPYVTMm4o/S3Oib0Q53gt/x
TAUq7IMYHtCHZwxkNQJBAORwE 6qVIv/ZSP2tHLYf8DGOhEBJtQcVjE7PfUjAbH5
lr  9qUfv0S13gXj5weio5dzgEXwWdX2YSL/asz5DhU=
-----END RSA PRIVATE KEY-----

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

Запрос сертификата iis –

Обработка ответа сервиса подписи

При успешном создании запроса на сертификат Сервис Подписи в ответе вернёт структуру DSSCertRequest.

Дальнейшее поведение пользователя зависит от значения поля Status в структуре DSSCertRequest и типа УЦ, на котором создавался запрос на сертификат.

ACCEPTED – запрос на сертификат принят и обработан УЦ. В данном случае в поле CertificateID будет записан идентификатор выпущенного сертификата.

REGISTRATION – запрос на сертификат принят в КриптоПро УЦ 2.0 и находится на этапе регистрации пользователя УЦ.

В зависимости от настроек подключения DSS к КриптоПро УЦ 2.0, необходимо:

• ожидать одобрения запроса на сертификат Администратором УЦ;
• одобрить запрос Оператором DSS.

PENDING – запрос на сертификат находится в обработке.

Если запрос отправлен на КриптоПро УЦ 2.0, то в зависимости от настроек подключения DSS к КриптоПро УЦ 2.0 необходимо:

• ожидать одобрения запроса на сертификат Администратором УЦ;
• одобрить запрос Оператором DSS.

Если запрос создавался через “Сторонний Удостоверяющий Центр”, необходимо:

Запрос на сертификат (PKCS#10) в формате Base64 содержится в поле Base64Request структуры DSSCertRequest.

REJECTED – запрос отклонён. Дальнейшая обработка запроса невозможна. Для выяснения причин отклонения запроса необходимо обратиться к
Администратору УЦ.

Онлайн сервис подачи документов для получения сертификатов

Создание csr-запроса и закрытого ключа

1. В консоли MMC разверните узел Сертификаты (локальный компьютер), а затем Личные.
2. Щелкните Сертификаты правой кнопкой мыши, а затем перейдите в следующее меню: Все задачи > Дополнительные операции > Создать настраиваемый запрос.
3. Нажмите «Далее».
4. Щелкните Политика регистрации Active Directory.
5. В поле Шаблон выберите Веб-сервер.
6. Убедитесь, что в поле Формат запроса выбрано значение PKCS #10, а затем нажмите кнопку Далее.
7. Щелкните кнопку со стрелкой вниз рядом с полем Сведения и выберите Свойства.
8. В меню Тип выберите следующие значения, введите соответствующее значение и нажмите кнопку Добавить:
   

   Тип	Значение
   Общее название	Название вашего предприятия или организации
   Организация	Название вашего предприятия или организации
   Населенный пункт	Адрес вашего предприятия или организации
   Область	Область или регион размещения вашего предприятия или организации
   Страна	Страна размещения вашего предприятия или организации

9. Перейдите на вкладку Общие и введите понятное имя для вашего сертификата.
10. Перейдите на вкладку Закрытый ключ, щелкните Тип ключа и выберите Сделать закрытый ключ экспортируемым.
11. Нажмите кнопку OK, а затем кнопку Далее.
12. Нажмите кнопку Обзор, чтобы выбрать расположение для сохранения файла, введите имя файла и нажмите кнопку Готово.

Запрос на подпись сертификата сохраняется в этом файле на локальном компьютере.

Кроме того, при этом создается закрытый ключ, который потребуется вам позднее для создания PFX-файла для подписания кода или драйвера.

Создание запроса на сертификат с подтверждением при помощи вторичной аутентификации

При создании запроса на сертификат с подтверждением при помощи вторичной аутентификации требуется выполнить
следующую последовательность действий (шагов):

При этом в массиве параметров транзакции метода /transactions
должны быть отображены следующие поля запроса на сертификат:

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

• Уровень 0 — использование только серверного сертификата на WLC
• Уровень 1 — использование серверного сертификата на WLC и корневого сертификата CA
• Уровень 2 — использование серверного сертификата на WLC, одного сертификата промежуточного CA и корневого сертификата CA
• Уровень 3 — использование серверного сертификата на WLC, двух сертификатов промежуточных CA и корневого сертификата CA

WLC не поддерживает связанные сертификаты размером больше 10 КБ на WLC. Однако это ограничение было убрано в WLC, начиная с версии 7.0.230.0.

Примечание: Цепочечные сертификаты поддерживаются и на самом деле требуемый для web-аутентификации и веба – администратора

Примечание. Подстановочные сертификаты полностью поддерживаются для локального EAP, управления или веб-аутентификации

В качестве сертификатов для веб-аутентификации можно использовать любые из следующих сертификатов:

• Связанный
• Несвязанный
• Формируемые автоматически

Примечание: В Версии 7.6 WLC и позже, только цепочечные сертификаты поддерживаются (и поэтому требуемый)

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

В этом документе рассказывается о том, как правильно установить связанный сертификат SSL на WLC.

Устранение неполадок

То То Чаще всего проблемы возникают при установке сертификата на WLC.  Для того чтобы выполнить поиск и устранить неполадку, откройте командную строку на WLC и введите debug transfer all enable и debug pm pki enable, после чего выполните процедуру загрузки сертификата. 

In some cases, the logs will only say that the certificate installation failed:
*TransferTask: Sep 09 08:37:17.415: RESULT_STRING: TFTP receive complete... Installing
Certificate.
*TransferTask: Sep 09 08:37:17.415: RESULT_CODE:13
TFTP receive complete... Installing Certificate.
*TransferTask: Sep 09 08:37:21.418: Adding cert (1935 bytes) with certificate key password.
*TransferTask: Sep 09 08:37:21.421: RESULT_STRING: Error installing certificate.

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

Вот пример данных отладки при наличии неправильного промежуточного CA:

*TransferTask: Jan 04 19:08:13.338: Add WebAuth Cert: Adding certificate & private key using password check123
*TransferTask: Jan 04 19:08:13.338: Add ID Cert: Adding certificate & private key using password check123
*TransferTask: Jan 04 19:08:13.338: Add Cert to ID Table: Adding certificate (name: bsnSslWebauthCert) to ID table using password check123
*TransferTask: Jan 04 19:08:13.338: Add Cert to ID Table: Decoding PEM-encoded Certificate (verify: YES)
*TransferTask: Jan 04 19:08:13.338: Decode & Verify PEM Cert: Cert/Key Length was 0, so taking string length instead
*TransferTask: Jan 04 19:08:13.338: Decode & Verify PEM Cert: Cert/Key Length 7148 & VERIFY
*TransferTask: Jan 04 19:08:13.342: Decode & Verify PEM Cert: X509 Cert Verification return code: 0
*TransferTask: Jan 04 19:08:13.342: Decode & Verify PEM Cert: X509 Cert Verification result text: unable to get local issuer certificate
*TransferTask: Jan 04 19:08:13.342: Decode & Verify PEM Cert: Error in X509 Cert Verification at 0 depth: unable to get local issuer certificate
*TransferTask: Jan 04 19:08:13.343: Add Cert to ID Table: Error decoding (verify: YES) PEM certificate
*TransferTask: Jan 04 19:08:13.343: Add ID Cert: Error decoding / adding cert to ID cert table (verifyChain: TRUE)
*TransferTask: Jan 04 19:08:13.343: Add WebAuth Cert: Error adding ID cert

Шаг 3. графический интерфейс пользователя. загрузка стороннего сертификата на wlc с помощью графического интерфейса пользователя

Выполните следующие действия, чтобы загрузить связанный сертификат на контроллер беспроводной локальной сети Cisco с помощью графического интерфейса пользователя:

1. Скопируйте сертификат устройства final.pem в каталог по умолчанию на своем сервере TFTP.
2. Выберите Security > Web Auth > Cert (Безопасность > Веб-аутентификация > Сертификат), чтобы открыть страницу Web Authentication Certificate (Сертификат для веб-аутентификации).
3. Установите флажок Download SSL Certificate (Загрузить сертификат SSL), чтобы открыть параметры Download SSL Certificate From TFTP Server (Загрузка сертификата SSL с сервера TFTP).
4. В поле IP Address (IP-адрес) введите IP-адрес сервера TFTP.

   

5. В поле File Path (Путь к файлу) введите путь к каталогу с сертификатом.
6. В поле File Name (Имя файла) введите имя сертификата.
7. В поле Certificate Password (Пароль сертификата) введите пароль, который использовался для защиты сертификата.
8. Нажмите Apply.
9. После того как загрузка будет завершена, выберите Commands> Reboot> Reboot (Команды > Перезагрузка > Перезагрузить).
10. При появлении запроса на сохранение изменений выберите Save and Reboot (Сохранить и перезагрузить).
11. Нажмите OK, чтобы подтвердить решение перезагрузить контроллер.

Шаг 3. интерфейс командной строки. загрузка стороннего сертификата на wlc с помощью интерфейса командной строки

Выполните следующие действия, чтобы загрузить связанный сертификат на контроллер беспроводной локальной сети Cisco с помощью интерфейса командной строки:

1. Переместите файл final.pem в каталог по умолчанию на своем сервере TFTP.
2. В интерфейсе командной строки выполните следующие команды для изменения настроек загрузки:

       >transfer download mode tftp
   >transfer download datatype webauthcert
   >transfer download serverip <TFTP server IP address>
   >transfer download path <absolute TFTP server path to the update file>
   >transfer download filename final.pem

3. Введите пароль для файла .pem, чтобы операционная система могла расшифровать ключ SSL и сертификат.

   >transfer download certpassword password

   Примечание. Параметру certpassword должно быть задано такое же значение, как параметру -passout . Это пароль, который был задан на шаге 4 (или 5), приведенном в разделе Формирование CSR.В данном примере параметру certpassword должно быть задано значение check123. Если изначально был выбран вариант Б (то есть формирование CSR с помощью WLC), можно оставить поле certpassword пустым.

4. Выполните команду transfer download start, чтобы просмотреть обновленные настройки.Затем при появлении приглашения введите y, чтобы подтвердить текущие настройки загрузки и запустить загрузку сертификата и ключа. Например:

   (Cisco Controller) >transfer download start
   Mode............................................. TFTP
   Data Type........................................ Site Cert
   TFTP Server IP................................... 10.77.244.196
   TFTP Packet Timeout.............................. 6
   TFTP Max Retries................................. 10
   TFTP Path........................................./
   TFTP Filename.................................... final.pem
   This might take some time.
   Are you sure you want to start? (y/N) y
   TFTP EAP Dev cert transfer starting.
   Certificate installed.
   Reboot the switch to use new certificate.

5. Перезагрузите WLC, чтобы изменения вступили в силу.