• 1. Создание собственного сертификационного центра.
• 1.1 Создание приватного ключа CA.
• 1.2 Создание сертификата CA
• 2. Выдача сертификатов.
• 2.1 Скрипт генерации сертификатов.
• 2.2 Создаем серверный сертификат (для RADIUS).
• 2.3 Создание клиентских сертификатов.
• 3. Настройка FreeRADIUS.
• 3.1 файл /etc/raddb/clients.conf
• 3.2 файл /etc/raddb/radiusd.conf
• 3.3 файл /etc/raddb/proxy.conf
• 3.4 файл /etc/raddb/users
• 3.5 файл /etc/raddb/eap.conf
• 3.6 права доступа к /etc/raddb/
• 3.7 Проверка конфигурации и запуск radiusd в режиме отладки
• Заключение.

В предыдущий раз мы рассмотрели настройку WPA шифрования в беспроводных сетях и аутентификацию клиентов в них с использованием FreeRADIUS. Аутентификация происходила по логину и паролю, база которых хранилась в файле /etc/raddb/users.

В этот раз мы будем настраивать аутентификацию с использованием цифровых сертификатов, то есть, используя протокол EAP-TLS.

Итак, для работы с этой статьей нам потребуется:

• RADIUS-сервер — был использован FreeRadius сервер версии 1.0.5, работающий под операционной системой Gentoo Linux.
• OpenSSL (был использован пакет openssl-0.9.7g)

В этой части мы рассмотрим лишь создание собственного сертификационного центра и выдачу сертификатов клиентам и серверам, а также настройку FreeRADIUS для работы с EAP-TLS.

Пара слов о цифровых сертификатах, а точнее о PKI.

Public Key Infrastructure (PKI) — инфраструктура открытых ключей. PKI обеспечивает создание цифровых сертификатов (по заранее заданным политикам), управление ими, хранение, выдача их субъектам и отзыв (аннулирование). Кроме того, PKI обеспечивает возможность проверки валидности сертификатов. Инфраструктура базируется на криптографии с открытым ключом. А она, в свою очередь, дает возможность, имея на руках пару ключей (открытый и личный), шифровать информацию одним из этих ключей так, чтобы расшифровать ее можно было только другим ключом.

Например, зашифровав информацию личным ключом (который имеется только у владельца и никому не передается), ее можно расшифровать открытым, общедоступным ключом (это называется ассиметричным шифрованием). Тем самым удостоверяется, что информация пришла именно от владельца закрытого ключа и не от кого другого. И наоборот — можно зашифровать информацию открытым ключом владельца и отослать ее получателю. Даже если кто-то по дороге перехватит сообщение, он не сможет его прочитать, так как не владеет личным ключом получателя.

Все бы хорошо, но как удостоверится, что человек, владелец открытого ключа, именно тот, за кого себя выдает? Именно тут на помощь приходят цифровые сертификаты, тянущие за собой всю инфраструктуру PKI. Сертификаты содержат определенную информацию, позволяющую однозначно удостоверить личность владельца (точнее, подтверждение удостоверения личности приходит от третьей стороны)

Каждый субъект PKI (будь то обычный пользователь, веб-сервер, любой другой сервер или сетевое устройство) имеет личный сертификат (или несколько сертификатов), который содержит информацию, по которой его можно однозначно идентифицировать, и открытый ключ владельца.

Над всем этим (в вершине пирамиды) стоит сертификационный центр, Certificate Authority (CA), который подписывает сертификаты субъектов, а также подтверждает валидность выданных сертификатов, то есть удостоверяет личности владельцев. CA доверяют все субъекты PKI, поэтому корневой сертификат (иными словами сертификат CA) должен быть в списке доверия у всех субъектов PKI.

Из всего вышеописанного вытекает еще один, неочевидный на первый взгляд, плюс. При подключении к беспроводной сети можно аутентифицировать не только пользователя, который подключается, но и сам подключающийся клиент может со своей стороны аутентифицировать сервер, к которому он подключается. Достаточно указать клиентскому софту проверять сертификат сервера (то есть сертификат, который выдается RADIUS-сервером в начальной стадии при подключении клиента). Таким образом, можно обезопасить себя от "чужих" точек доступа, маскирующихся под "свои".

Итак. Нам необходимо создать собственный сертификационный сервер, выдать сертификат FreeRADIUS-у и клиентам. Займемся этим.

1. Создание собственного сертификационного центра.

1.1 Создание приватного ключа CA

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

Создаем приватный ключ CA (my own Certificate Authority). Длина RSA ключа 2048 бит, шифрование по алгоритму 3DES. Имя файла с ключом — tmp_ org- ca. key ===================================================== # openssl genrsa -des3 -out tmp_org-ca.key 2048 Generating RSA private key, 2048 bit long modulus ………………….+++ ………..+++ e is 65537 (0x10001) Enter pass phrase for tmp_org.key: Verifying — Enter pass phrase for tmp_org-ca.key: =====================================================

На этапе создания надо ввести пасс-фразу, которой будет закрыт ключ (и подтвердить ее).

Содержимое ключа, если это необходимо, можно просмотреть следующей командой: ===================================================== # openssl rsa -noout -text -in tmp_org-ca.key =====================================================

При этом опять придется ввести ключ.

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

Генерируем самоподписанный (то есть подписанный самим собой) сертификат CA. ===================================================== # openssl req -new -x509 -days 3650 -key tmp_org-ca.key -out tmp_org-ca.crt Enter pass phrase for tmp_org.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [RU]: RU State or Province Name (full name) [Euro]: Euro Locality Name (eg, city) [Moscow]: Moscow Organization Name (eg, company) [company]:Temp Organisation Organizational Unit Name (eg, section) [network IT]: network IT Common Name (eg, YOUR name) []:tmp_org root CA Email Address [admin@company.org]:admin@tmp_org.ru =====================================================

На этапе генерации сертификата необходимо ключевую фразу, которой закрыт ключ CA, а после этого — заполнить необходимые поля (имя компании, емейл и т.д.), самым важным из них является Common Name — это уникальное имя сертификационного центра. В данном случае в качестве Common name было выбрано "tmp_org root CA".

Просмотреть полученный сертификат можно командой ===================================================== # openssl x509 -noout -text -in tmp_org-ca.crt =====================================================

В результате мы увидим: ===================================================== Certificate: Data: Version: 3 (0x2) Serial Number: ea:30:7b:69:a2:13:0c:70 Signature Algorithm: md5WithRSAEncryption Issuer: C=RU, ST=Euro, L=Moscow, O=Temp Organisation, OU=network IT, CN=tmp_org root CA/emailAddress=admin@tmp_org.ru # # # кем выдан (нами же, то есть самоподписанный) # # Validity Not Before: Dec 9 11:34:29 2005 GMT Not After : Dec 7 11:34:29 2015 GMT # # # срок действия сертификата # # Subject: C=RU, ST=Euro, L=Moscow, O=Temp Organisation, OU=network IT, CN=tmp_org root CA/emailAddress=admin@tmp_org.ru # # # содержимое (поля) сертификата # # Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:c0:ff:50:fd:a8:eb:07:9b:17:d1:a9:e2:a5:dc: 59:a7:97:28:9f:bc:a4:01:16:45:37:f5:8d:ca:1e: 12:ca:25:02:8a:cf:ee:ae:35:59:ed:57:89:c7:2b: 17:9f:8b:de:60:db:e5:eb:b3:de:09:30:3b:a9:68: 40:f7:f8:84:f4:6c:b2:24:3d:ed:45:a3:8a:66:99: 40:a9:53:0c:75:e3:df:f3:ef:20:0c:a6:3f:f2:dd: e9:1c:f5:d1:c1:32:4c:44:fd:c1:a2:d9:e6:e0:dc: 04:0c:f8:dd:9e:31:aa:9d:60:b0:84:d2:e0:b7:a5: eb:82:31:4f:71:c4:ee:ab:5c:8e:ef:8c:a1:1a:2a: 62:e9:e9:36:ff:12:b9:c9:ac:0e:4d:ac:08:97:87: d2:30:2f:41:a1:9e:ef:8b:bf:c6:cf:66:70:02:ab: 2d:b0:9c:56:b8:13:e8:92:59:f5:d9:33:d7:33:6a: 7c:cb:9b:92:ee:4b:22:32:73:59:70:3f:b1:f6:1b: 67:1d:28:eb:bb:4b:5e:61:95:43:78:d5:3b:db:e1: 37:f1:ec:0d:db:50:65:22:cb:f4:f9:b8:2a:c6:1f: 2b:e9:f8:64:03:4f:36:dc:72:8e:be:3d:12:8a:ca: 8b:95 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 4C:80:F5:82:4C:A4:52:DF:9E:0C:0D:64:74:68:1E:45:F6:C1:C7:68 X509v3 Authority Key Identifier: keyid:4C:80:F5:82:4C:A4:52:DF:9E:0C:0D:64:74:68:1E:45:F6:C1:C7:68 DirName:/C=RU/ST=Euro/L=Moscow/O=Temp Organisation/OU=network IT/ CN=tmp_org root CA/emailAddress=admin@tmp_org.ru serial:EA:30:7B:69:A2:13:0C:70 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: md5WithRSAEncryption 57:db:0d:2b:27:eb:0a:97:7f:b1:37:b3:d1:d7:14:a6:80:66: 3d:7c:00:4a:45:1f:7c:2b:5e:30:b2:72:74:9f:6d:33:82:f7: f7:de:54:a9:2b:e7:ea:1b:93:bd:cc:74:4f:11:ed:94:0b:b9: b2:1f:b1:86:6e:c6:48:71:48:9b:2b:0a:36:f3:ab:d6:f9:75: c9:0d:1b:e9:2c:85:04:fc:17:9a:94:b9:14:0d:15:d1:1e:8b: bb:9e:91:ca:40:8c:d8:ef:dd:4a:75:d0:b9:62:d4:ee:1b:e5: b5:7e:fa:f1:5d:62:d1:78:b0:34:04:bb:60:37:8a:a8:74:88: f6:94:3b:c8:fb:c0:98:f4:94:e9:d5:53:8e:31:e6:25:56:c3: 84:7c:46:b9:09:5f:e3:43:a8:57:c9:3a:d9:3d:a7:b0:41:db: ea:ca:60:28:0b:a3:f0:0b:e6:d6:c0:5b:15:0c:f8:19:36:26: d3:2a:8d:c9:67:fe:04:6f:e9:bf:f9:55:de:2c:92:04:81:6f: 43:d5:94:25:af:83:b8:01:22:c8:1a:7e:2e:a9:10:b0:e5:35: a7:17:bf:65:a1:31:55:85:ba:10:24:71:03:3b:d6:71:a4:ad: 48:28:46:8f:7e:e6:b3:8c:37:97:4f:36:05:8c:f6:d1:40:a8: c4:58:9b:28 =====================================================

Теперь скопируем сертификат и ключ центра CA в общедоступное место, например, в /etc/ssl/tmp_org: ===================================================== # mkdir /etc/ssl/tmp_org # cp tmp_org-ca.* /etc/ssl/tmp_org/ =====================================================

2. Выдача сертификатов.

2.1 Скрипт генерации сертификатов.

Для начала скачиваем скрипт sign_cert.sh. Он позволяет создавать серверные/пользовательские сертификаты с экспортом их в PKCS#12 формат (для импортирования в Windows ОС).

Правим в нем следующие строчки: #==================================================== ROOTCA="tmp_org" #root CA name # # имя файла с корневым сертификатом (без суффикса '-ca') # O="TempOrg" # # имя организации # C="RU" # # страна # ST="Euro" # # штат # L="Moscow" # # город # OU="network IT" # # подразделение # EMAIL="email@tmp_org.ru" # # емейл # BITS=2048 # # размер генерируемого ключа в битах # CLIENT_DAYS=730 # # срок валидности клиентского сертификата в днях # SERVER_DAYS=1461 # # срок валидности серверного сертификата в днях # #====================================================

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

Обращаю внимание, что для работы radius-а с windows-клиентами, в серверный и клиентский сертификаты нужно внести дополнительные поля (цифры должны быть теми же самыми): #==================================================== # # в сертификат клиента # extendedKeyUsage = 1.3.6.1.5.5.7.3.2 # # в сертификат сервера # extendedKeyUsage = 1.3.6.1.5.5.7.3.1 #====================================================

Скрипт генерации сертификатов эти поля внутрь соответствующих сертификатов добавляет.

2.2 Создаем серверный сертификат (для RADIUS)

Создаем серверный сертификат (параметр cerver_cert), название файла (и сертификата) radius.tmp_org.ru #---------------------------------------------------- # ./sign_cert.sh server_cert radius.tmp_org.ru create certificate key: radius.tmp_org.ru.key Generating RSA private key, 2048 bit long modulus …….+++ …………………………….+++ e is 65537 (0x10001) # # #сначала генерится ключ, тут надо придумать и ввести пароль, #которым этот ключ будет закрыт # # Enter pass phrase for radius.tmp_org.ru.key: Verifying — Enter pass phrase for radius.tmp_org.ru.key: decrypt certificate key: radius.tmp_org.ru.crt Enter pass phrase for radius.tmp_org.ru.key: writing RSA key # # #создаем запрос на сертификат # # create certificate request: radius.tmp_org.ru.csr vega 1 # ./sign_cert.sh radius.tmp_org.ru server_cert You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- # # #тут необходимо указать нужные поля, аналогично корневому сертификату, #значения по умолчанию уже забиты в квадратных скобках #для их использования достаточно нажать ENTER # # 1. Country Name (2 letter code) [RU]: 2. State or Province Name (full name) [Euro]: 3. Locality Name (eg, city) [Moscow]: 4. Organization Name (eg, company) [TempOrg]: 5. Organizational Unit Name (eg, section) [network IT]: 6. Common Name (eg, CA name) [radius.tmp_org.ru]: 7. Email Address (eg, name@FQDN) [email@tmp_org.ru]: # # #подписываем запрос на сертификат # # sign certificate by CA: radius.tmp_org.ru.crt sign ca is: tmp_org-ca CA signing: radius.tmp_org.ru.csr -> radius.tmp_org.ru.crt: Using configuration from ca.config # # #так как подписываем вновь создаваемый сертификат корневым, #необходимо ввести пароль, которым закрыт ключ корневого сертификата #нашего центра CA # # Enter pass phrase for ./../tmp_org-ca.key: Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'RU' stateOrProvinceName :PRINTABLE:'Euro' localityName :PRINTABLE:'Moscow' organizationName :PRINTABLE:'TempOrg' organizationalUnitName:PRINTABLE:'network IT' commonName :T61STRING:'radius.tmp_org.ru' emailAddress :IA5STRING:'email@tmp_org.ru' Certificate is to be certified until Dec 9 12:05:18 2007 GMT (730 days) # # #подписали, добавили файл в базу # # Write out database with 1 new entries Data Base Updated # # #проверяем, все ли в порядке # # CA verifying: radius.tmp_org.ru.crt <-> CA cert radius.tmp_org.ru.crt: OK # # #все ок, завершаем работу # # #----------------------------------------------------

Серверный сертификат создан, посмотрим, какие новые файлы у нас появились. #----------------------------------------------------
# ls -l certificates/
-rw-r--r-- 1 root root 4101 Dec 9 15:05 radius.tmp_org.ru.crt
-rw-r--r-- 1 root root 1751 Dec 9 15:05 radius.tmp_org.ru.key
-rw-r--r-- 1 root root 1679 Dec 9 15:05 radius.tmp_org.ru.key.unsecure
#----------------------------------------------------

Файл radius.tmp_org.ru.key.unsecure является расшифрованным (не закрытым) ключом для серверного сертификата. Если он не нужен, лучше его сразу удалить. К сожалению, очень часто при использовании сертификатов с программами, последние требуют открытые ключи (другие позволяют сохранять пароль в своих конфигурационных файлах, что тоже, конечно, не здорово, но сам ключ содержится в зашифрованном виде).

2.3 Создание клиентских сертификатов.

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

Тип — клиентский сертификат (client_cert), имя — test_user. #---------------------------------------------------- # ./sign_cert.sh client_cert test_user # # #генерируем новый ключ # # create certificate key: test_user.key Generating RSA private key, 2048 bit long modulus ………………………………………………………………………………………. …………+++ …………………………………………………+++ e is 65537 (0x10001) # # #придумываем парольную фразу, которой этот ключ будет закрыт # # Enter pass phrase for test_user.key: Verifying — Enter pass phrase for test_user.key: # # #создаем запрос на клиентский сертификат # # create certificate request: test_user.csr # # #опять вводим парольную фразу клиентского ключа # # Enter pass phrase for test_user.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- # # #заполняем необходимые поля для нового сертификата # # 1. Country Name (2 letter code) [RU]: 2. State or Province Name (full name) [Euro]: 3. Locality Name (eg, city) [Moscow]: 4. Organization Name (eg, company) [TempOrg]: 5. Organizational Unit Name (eg, section) [network IT]: 6. Common Name (eg, CA name) [eightner]: 7. Email Address (eg, name@FQDN) [email@tmp_org.ru]: openssl req -new -key eightner.key -config ca.config -extensions v3_req -out eightner.csr # # #подписываем сертификат клиента корневым (нашего CA) # # sign certificate by CA: test_user.crt (sign ca is: tmp_org-ca) CA signing: test_user.csr -> test_user.crt: Using configuration from ca.config Enter pass phrase for ./../tmp_org-ca.key: DEBUG[load_index]: unique_subject = "no" Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'RU' stateOrProvinceName :PRINTABLE:'Euro' localityName :PRINTABLE:'Moscow' organizationName :PRINTABLE:'TempOrg' organizationalUnitName:PRINTABLE:'network IT' commonName :PRINTABLE:'eightner' emailAddress :IA5STRING:'email@tmp_org.ru' # # #сертификат действителен с настоящего времени по: # # Certificate is to be certified until Dec 9 12:31:24 2007 GMT (730 days) Write out database with 1 new entries Data Base Updated # # #конвертируем клиентский сертификат в PKCS#12 формат #(для того, чтобы импортировать его на Windows-клиенте) # # converting test_user certificate to pkcs12 format # # #опять необходимо ввести пасс-фразу, который закрыт клиентский ключ # # Enter pass phrase for test_user.key: # # #а теперь нужно придумать и ввести пароль, который будет спрошен #при импорте сертификата на Windows-клиентской машине # # Enter Export Password: Verifying — Enter Export Password: # # #проверяем правильность сертификата # # CA verifying: test_user.crt <-> CA cert test_user.crt: OK # # #все ок, завершаем работу # # #----------------------------------------------------

Смотрим, что получилось: #---------------------------------------------------- ls -l certificates/ total 6 -rw-r--r-- 1 root root 4233 Dec 9 15:31 test_user.crt -rw-r--r-- 1 root root 1751 Dec 9 15:31 test_user.key -rw-r--r-- 1 root root 3813 Dec 9 15:31 test_user.p12 -rw-r--r-- 1 root root 4101 Dec 9 15:05 radius.tmp_org.ru.crt -rw-r--r-- 1 root root 1751 Dec 9 15:05 radius.tmp_org.ru.key -rw-r--r-- 1 root root 1679 Dec 9 15:05 radius.tmp_org.ru.key.unsecure #----------------------------------------------------

Собственно, для импорта персонального сертификата в windows, нас интересует файл test_user.p12. Не помешает и test_user.crt (его тоже можно импортировать, но чуть сложнее, чем обычный клик мышкой на файле). Содержимое первого и второго файла — одинаково, просто разные форматы упаковки.

Таким же образом, создаем сертификаты для test_user2, test_user3: #---------------------------------------------------- # ./sign_cert.sh client_cert test_user2 # # <…….> повторяем все предыдущие шаги # # ./sign_cert.sh client_cert test_user3 # # <…….> повторяем все предыдущие шаги # #----------------------------------------------------

3. Настройка FreeRADIUS.

Для начала пакет FreeRadius надо установить в систему. Об этом было рассказано в предыдущей части.

А вот настройка конфигурационных файлов RADIUS-а в некоторых местах отличается от описываемых ранее.

Кроме конфигурационных файлов нужно подготовить еще кое-что.

Создаем директорию, где будут храниться наши сертификаты и другие необходимые файлы: #---------------------------------------------------- # mkdir /etc/raddb/ssl #----------------------------------------------------

Удаляем открытый вариант серверного ключа для RADIUS-а (файл radius.tmp_org.ru.key.unsecure), он нам не нужен, так как FreeRADIUS позволяет хранить парольную фразу внутри конфигурационного файла. #---------------------------------------------------- # rm -f radius.tmp_org.ru.key.unsecure #----------------------------------------------------

Копируем сертификат и закрытый ключ для RADIUS в директорию /etc/raddb/ssl (из директории ./certificates, в которой мы в данный момент должны находиться). #---------------------------------------------------- # cp radius.tmp_org.ru.* /etc/raddb/ssl #----------------------------------------------------

Создаем новый файл Diffie-Hellman-параметров: #---------------------------------------------------- openssl dhparam 512 >/etc/raddb/ssl/dh Generating DH parameters, 512 bit long safe prime, generator 2 This is going to take a long time …………….++*++*++*++*++*++* #----------------------------------------------------

Записываем в /etc/raddb/ssl/random случайную последовательность длиной 1024 байт: #---------------------------------------------------- # dd if=/dev/urandom of=/etc/raddb/ssl/random count=2 2+0 records in 2+0 records out #----------------------------------------------------

После этого переходим непосредственно к настройке конфигурационных файлов FreeRADIUS.

3.1 Файл /etc/raddb/clients.conf

Настройка полностью аналогична ранее описанной.

3.2 Файл /etc/raddb/radiusd.conf

Этот файл не требует никаких настроек относительно стандартных.

Единственное, что надо проверить, чтобы в конфигурационном файле подключался файл настроек eap: #---------------------------------------------------- # Extensible Authentication Protocol # # For all EAP related authentications. # Now in another file, because it is very large. # $INCLUDE ${confdir}/eap.conf #----------------------------------------------------

3.3 Файл /etc/raddb/proxy.conf

Этот файл не требует никаких настроек относительно стандартных.

3.4 Файл /etc/raddb/users

Так как пользователи теперь аутентифицируются по персональным сертификатам, этот файл нам тоже не требуется.

3.5 Файл /etc/raddb/eap.conf

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

Секция eap{ } #---------------------------------------------------- default_eap_type = tls # по-умолчанию, используем протокол EAP-TLS #----------------------------------------------------

Теперь раскомментируем секцию tls {} и приводим ее к такому виду: #---------------------------------------------------- tls { private_key_password = 1234 # пароль, которым закрыт ключ серверного сертификата private_key_file = ${raddbdir}/ssl/radius.tmp_org.ru.key #путь к файлу с ключем certificate_file = ${raddbdir}/ssl/radius.tmp_org.ru.crt #путь к серверному сертификату CA_file = /etc/ssl/tmp_org/tmp_org-ca.crt # путь к корневому сертификату нашего центра CA # (чуть ранее мы его скопировали в директорию /etc/ssl/tmp_org) dh_file = ${raddbdir}/ssl/dh # путь к файлу с DH параметрами random_file = ${raddbdir}/ssl/random # путь к файлу со случайной последовательностью } #----------------------------------------------------

На этом настройка RADIUS-сервера завершена.

3.6 Права доступа к /etc/raddb/

Проверка установления прав доступа детально расписывалась в предыдущей статье. Только, в отличие от нее, нам совершенно не нужно менять права на файл /etc/raddb/users, так как в этом файле теперь ничего не хранится. А вот в файле /etc/raddb/eap.conf у нас теперь содержится пароль, которым закрыт ключ сертификата сервера. Поэтому команду ограничения доступа на чтения для всех нужно применить именно к этому файлу: ===================================================== # /bin/chmod o-r /etc/raddb/eap.conf # /bin/ls -l /etc/raddb/eap.conf -rw-r----- 1 root radiusd 9179 Dec 10 16:07 /etc/raddb/eap.conf =====================================================

3.7 Проверка конфигурации и запуск radiusd в режиме отладки

Эта процедура была описана в предыдущей статье.

Если radiusd стартует, значит, критических ошибок в конфигурации нет, сервер настроен, работает и готов принимать запросы.

Заключение.

Осталось настроить клиентов, так как перенастройка точки доступа не требуется.

О настройке клиентов (импортирование сертификатов, настройка профиля беспроводной сети) — в следующей статье.

Навигация

• Часть первая — теоретически аспекты протокола WPA
• Часть вторая — WPA в режиме EAP-PEAP
• Часть третья — WPA в режиме EAP-TLS, создание сертификатов и настройка FreeRadius
• Часть четвертая — WPA в режиме EAP-TLS, настройка клиентов
• Часть пятая — EAP-TLS аутентификация компьютеров в доменных сетях Windows