Содержание

Цель

Требования

Введение

Настройка

Сертификат HTTPS

Профиль сертификата

Заключение

Вопросы и ответы

Цель

В этом руководстве приведены инструкции по настройке SSL/TLS-сертификатов на контроллере Omada SDN.

Требования

• Omada Controller 6.1
• OpenSSL

Введение

Контроллер Omada использует SSL/TLS-сертификаты для защиты связи таких служб, как HTTPS и RadSec (RADIUS через TLS). В большинстве внутренних или частных развёртываний обычно используется собственный центр сертификации (CA) с OpenSSL, что просто и достаточно для типичных случаев использования. В крупных корпоративных сетях для управления сертификатами могут использоваться централизованные системы PKI.

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

Настройка

Сертификат HTTPS

Программный контроллер Omada по умолчанию использует HTTPS. При доступе к контроллеру по доменному имени или IP-адресу браузер может показывать предупреждение, например «недоверенный сертификат» или «соединение не защищено». Это происходит потому, что Omada использует самоподписанный сертификат, который по умолчанию не является доверенным для браузеров. Чтобы избежать предупреждений браузера о недоверенном сертификате, вы можете импортировать HTTPS-сертификат, подписанный доверенным публичным центром сертификации, или использовать сертификат, выпущенный личным или внутренним центром сертификации.

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

Шаг 1. Создание самоподписанного корневого сертификата удостоверяющего центра (CA)

openssl genrsa -out rootCA.key 2048

Эта команда создает пару ключей длиной 2048 бит для вашего центра сертификации. Ключ используется для подписи сертификатов и должен храниться в безопасности.

openssl req -x509 -new -key rootCA.key -days 3650 -out rootCA.pem

Эта команда генерирует корневой сертификат (rootCA.pem) со сроком действия 10 лет. Он самоподписан с использованием закрытого ключа центра сертификации.

openssl x509 -in rootCA.pem -text

Эту команду можно использовать для просмотра подробного содержимого корневого сертификата.

Шаг 2. Генерация серверного ключа и запроса на подпись сертификата (CSR)

Для подготовки к выпуску сертификата для контроллера Omada сначала создайте серверный ключ и CSR:

openssl genrsa -out omada.key 2048

Эта команда генерирует пару ключей RSA длиной 2048 бит и сохраняет их в файл omada.key. Этот ключ будет использоваться для защиты связи и подписи запроса на сертификат.

openssl req -new -key omada.key -out omada.csr

Эта команда создает запрос на подпись сертификата (CSR) с использованием ранее созданного ключа. CSR содержит информацию о сервере и используется для запроса сертификата у удостоверяющего центра (CA).

openssl req -in omada.csr -text

Эту команду можно использовать для просмотра подробного содержимого CSR.

Шаг 3. Подпись серверного сертификата с использованием вашего собственного центра сертификации

Современные браузеры требуют, чтобы сертификаты содержали поле Subject Alternative Name (SAN). Чтобы включить SAN и другие необходимые расширения, создайте файл с именем server.txt в вашей рабочей директории со следующим содержимым:

# server.txt

[server_cert]

basicConstraints = CA:FALSE

keyUsage = digitalSignature, keyEncipherment

extendedKeyUsage = serverAuth

subjectAltName = @alt_names

[alt_names]

DNS.1 = omada.local

IP.1 = 127.0.0.1

# конец

Примечание: Убедитесь, что значения DNS.1 и IP.1 соответствуют фактическому доменному имени или IP-адресу вашего сервера.

Для получения более подробной информации о формате файла расширений обратитесь к x509v3_config - Документация OpenSSL и openssl-x509 - Документация OpenSSL.

Затем подпишите сертификат с использованием вашего корневого центра сертификации:

openssl x509 -req -in omada.csr -CA rootCA.pem -CAkey rootCA.key -days 365 -sha256 -extfile server.txt -extensions server_cert -out omada.pem

Полученный файл omada.pem — это ваш серверный сертификат, который можно использовать вместе с omada.key для включения HTTPS на контроллере Omada. Вы можете загрузить его в разделе Глобальный вид > Настройки > Системные настройки > Сертификат HTTPS. Убедитесь, что вы импортировали сертификат CA в хранилище доверенных корневых сертификатов вашего браузера. После этого перезапустите контроллер Omada для вступления изменений в силу.

Профиль сертификата и RadSec

RadSec (RADIUS через TLS) улучшает традиционный RADIUS, добавляя шифрование TLS. Стандартный RADIUS работает поверх UDP без защиты, тогда как RadSec защищает трафик с помощью конфиденциальности, целостности и аутентификации на основе сертификатов. В контроллере Omada администраторы настраивают сертификаты, чтобы устройства доступа и RADIUS-серверы могли создавать защищённые TLS-туннели. Для включения RadSec требуется правильное управление сертификатами, чтобы обеспечить доверенное и зашифрованное соединение.

Вы можете включить RadSec в разделе Просмотр узла > Настройка сети > Профили > Профиль RADIUS.

Примечание: При включении RadSec необходимо настроить как сертификат CA, так и клиентский сертификат:

Сертификат CA: Используется для проверки подлинности RADIUS-сервера. Устройство доступа проверяет, что сертификат сервера подписан этим доверенным центром сертификации, перед установкой TLS-туннеля.

Клиентский сертификат: Используется устройством доступа для подтверждения своей подлинности перед RADIUS-сервером. Это обеспечивает взаимную аутентификацию, чтобы обе стороны могли доверять друг другу.

Для упрощения управления сертификатами контроллер Omada предоставляет модуль «Профиль сертификата». Этот модуль используется для хранения и управления сертификатами CA и клиента, необходимыми для RadSec.

Шаг 1. Создание самоподписанного корневого сертификата CA

Если вы уже создали самоподписанный центр сертификации для настройки HTTPS, вы можете использовать тот же CA и здесь. CA будет использоваться для подписи как сертификата RADIUS-сервера, так и клиентского сертификата. Если вы ещё не создали его, обратитесь к разделу «Сертификат HTTPS» для получения подробных инструкций по созданию самоподписанного центра сертификации с помощью OpenSSL.

Шаг 2. Генерация сертификатов для RADIUS-сервера и клиента

После создания самоподписанного центра сертификации (Шаг 1) используйте его для выпуска двух сертификатов: одного для RADIUS-сервера и одного для устройства доступа. Оба должны быть подписаны одним и тем же центром сертификации для установления взаимного доверия.

2.1 Генерация сертификата RADIUS-сервера

openssl genrsa -out server.key -aes256 2048

Эта команда генерирует пару ключей RSA. Ключ RSA зашифрован с помощью AES-256 и будет использоваться RADIUS-сервером.

openssl req -new -key server.key -out server.csr

Эта команда создает файл CSR (server.csr), содержащий информацию об идентификаторе сервера (например, Common Name, Organization и т.д.). CSR будет подписан центром сертификации для получения действительного сертификата.

openssl x509 -req -in server.csr -days 3650 -sha256 -CA rootCA.pem -CAkey rootCA.key -out server.pem

Эта команда подписывает CSR корневым центром сертификации, созданным на Шаге 1. Результатом является сертификат сервера (server.pem) со сроком действия 3650 дней.

openssl x509 -in server.pem -text

Эту команду можно использовать для просмотра подробного содержимого сертификата.

2.2 Генерация клиентского сертификата

Примечание: Процесс такой же, как и при генерации сертификата сервера. Разница в том, что этот клиентский сертификат будет назначен устройству доступа через контроллер. Он позволяет устройству доступа подтвердить свою подлинность перед RADIUS-сервером во время рукопожатия TLS. Вместе с сертификатом CA это обеспечивает взаимную аутентификацию и безопасное соединение RadSec.

openssl genrsa -out client.key -aes256 2048

openssl req -new -key client.key -out client.csr

openssl x509 -req -in client.csr -sha256 -CA rootCA.pem -CAkey rootCA.key -days 365 -out client.pem

Шаг 3. Импорт сертификатов в профиль сертификата

В контроллере Omada перейдите в раздел Просмотр узла > Настройка сети > Профили > Профиль сертификата и добавьте сертификаты, созданные на предыдущих шагах.

Импорт сертификата CA

Импорт клиентского сертификата

Примечание: Пароль в поле «Закрытый ключ клиента» — это парольная фраза, установленная при создании клиентского ключа, используемая для его защиты шифрованием.

Шаг 4. Настройка профиля RADIUS

При настройке профиля RADIUS включите RadSec и укажите сертификат CA, созданный на предыдущих шагах. Этот сертификат CA используется для проверки сертификата RADIUS-сервера во время рукопожатия TLS.

Клиентский сертификат представляется серверу для проверки. Если RADIUS-сервер настроен на аутентификацию клиентов, вы должны указать клиентский сертификат, подписанный центром сертификации, которому доверяет сервер. Этот центр сертификации может быть тем же самым (как в этой статье), который выпустил сертификат сервера, или он может быть другим. Если аутентификация клиента не требуется, это поле можно оставить пустым.

Заключение

Используя OpenSSL, мы создали самоподписанный центр сертификации, успешно выпустили HTTPS-, клиентские и серверные сертификаты и загрузили их в контроллер для аутентификации.

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

Вопросы и ответы

В1: Почему браузер всё ещё показывает сертификат как недоверенный даже после настройки сертификата HTTPS?

О1: Во-первых, убедитесь, что ваш браузер установил сертификат CA. Во-вторых, убедитесь, что ваш HTTPS-сертификат соответствует следующим требованиям:

1. Длина ключа должна быть не менее 2048 бит; рекомендуется 4096 бит.
2. Сертификат должен содержать поле Subject Alternative Name (SAN).
3. Сертификат должен указывать предполагаемое использование в поле Extended Key Usage (EKU).
4. Срок действия сертификата не должен превышать 825 дней.

Наконец, вы можете проверить действительность вашего сертификата с помощью следующей команды:

openssl verify -CAfile <ваш_сертификат_CA.pem> <ваш_серверный_сертификат.pem>

В2: Как определить формат моего сертификата или ключевого файла?

О2: Обычно можно определить формат, посмотрев на содержимое файла (а не только на расширение).

1. Формат PEM

Распространённые расширения: .pem, .crt, .cer, .key

Примечание: Файл распознаётся как PEM, если его содержимое состоит из данных в кодировке Base64, заключённых в соответствующие маркеры BEGIN/END. Расширение файла не имеет значения.

Содержимое читаемо человеком, начинается с таких строк:

2. Формат DER

Распространённые расширения: .der, .cer

Содержимое бинарное, не читается человеком.

Для просмотра:

openssl x509 -in <ваш_сертификат.der> -inform der -text

3. Формат PFX/PKCS#12

Распространённые расширения: .pfx, .p12

Бинарный файл, содержащий сертификат и ключ

Для просмотра:

openssl pkcs12 -in <ваш_сертификат.pfx> -info

4. JKS (Java Keystore)

Распространённое расширение: .jks

Бинарный формат, используемый Java

Для просмотра:

keytool -list -v -keystore <ваш_сертификат.jks>

Примечание: keytool не является частью OpenSSL. Он поставляется с Java Development Kit (JDK), поэтому для его использования необходимо установить JDK.