16. Использование TLS

Клиенты и серверы OpenLDAP способны использовать технологию Transport Layer Security (TLS) для обеспечения защиты целостности и конфиденциальности данных, а также для поддержки аутентификации LDAP с использованием механизма EXTERNAL SASL. TLS определён в RFC4346.

Примечание: О том, как генерировать сертификаты, смотрите http://www.openldap.org/faq/data/cache/185.html

16.1. Сертификаты TLS

Для представления идентификационных сущностей клиента и сервера TLS использует сертификаты X.509. Всем серверам необходимо иметь корректные действующие сертификаты, тогда как клиентские сертификаты не являются обязательными. Клиентам необходимо иметь действующий сертификат в случае прохождения аутентификации с помощью SASL EXTERNAL. Дополнительную информацию о том, как создавать сертификаты и управлять ими, смотрите в документации по OpenSSL, GnuTLS или MozNSS, в зависимости от того, какую реализацию библиотек TLS Вы используете.

16.1.1. Сертификаты сервера

DN сертификата сервера должен использовать атрибут CN для именования сервера, и в этом CN должно содержаться полное доменное имя сервера. Дополнительные псевдонимы и шаблоны имени могут присутствовать в расширении сертификата subjectAltName. Подробности об именах в сертификате сервера можно найти в RFC4513.

16.1.2. Сертификаты клиента

DN сертификата клиента можно напрямую использовать в качестве аутентификационного DN. Поскольку X.509 - часть стандарта X.500, а LDAP также основан на X.500, оба они используют одинаковый формат DN; и в общем случае DN в сертификатах X.509 пользователей должны быть идентичны DN из записей LDAP. Однако, иногда данные DN могут не быть совершенно одинаковыми, в этом случае к ним может применяться функция отображения, описанная в подразделе Отображение аутентификационных идентификационных сущностей.

16.2. Настройка TLS

После получения необходимых сертификатов, и на клиенте и на сервере нужно произвести некоторое количество настроек, чтобы включить TLS и задействовать эти сертификаты. Как минимум, на клиентах должно быть настроено имя файла, содержащего все сертификаты Центров сертификации (или Удостоверяющих центров, Certificate Authority, CA), которым они будут доверять. На сервере должен быть настроен список сертификатов CA, а также его собственный сертификат сервера и закрытый ключ.

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

16.2.1. Конфигурация сервера

Директивы конфигурации slapd для настройки TLS располагаются в секции глобальных директив slapd.conf(5).

16.2.1.1. TLSCACertificateFile <имя файла>

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

16.2.1.2. TLSCACertificatePath <путь>

Данная директива указывает путь к директории, содержащей индивидуальные сертификаты CA в отдельных файлах. Кроме того, данная директория должна специальным образом управляться с помощью утилиты OpenSSL c_rehash. При использовании этой функции библиотека OpenSSL будет пытаться искать файлы сертификатов, основываясь на хэше их имени и серийного номера. Утилита c_rehash используется для создания символических ссылок с хэшированными именами, указывающих на актуальные файлы сертификатов. Таким образом, эта опция может быть использована только с файловыми системами, поддерживающими символические ссылки. В общем случае, вместо этого проще использовать директиву TLSCACertificateFile.

При использовании Mozilla NSS, данная директива указывает путь к директории, содержащей сертификат NSS и файлы базы данных ключей. Для добавления сертификата CA может быть использована команда certutil:

        certutil -d <путь> -A -n "имя сертификата CA" -t CT,, -a -i /path/to/cacertfile.pem

-t CT,,

16.2.1.3. TLSCertificateFile <имя файла>

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

При использовании Mozilla NSS, в случае применения базы данных сертификатов/ключей (задаваемой с помощью TLSCACertificatePath), данная директива указывает имя сертификата, который нужно использовать:

       TLSCertificateFile Server-Cert

При использовании маркера (token), отличного от встроенного, сначала укажите имя маркера и двоеточие:

       TLSCertificateFile my hardware device:Server-Cert

certutil -L

       certutil -d /path/to/certdbdir -L

16.2.1.4. TLSCertificateKeyFile <имя файла>

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

При использовании Mozilla NSS данная директива указывает имя файла, содержащего пароль для ключа сертификата, заданного в TLSCertificateFile. Команда modutil может быть использована для отключения парольной защиты базы данных сертификатов/ключей. Например, если в TLSCACertificatePath в качестве расположения базы данных сертификатов/ключей задана /etc/openldap/certdb, используйте такую команду modutil, чтобы поменять пароль на пустую строку:

        modutil -dbdir /etc/openldap/certdb -changepw 'NSS Certificate DB'

16.2.1.5. TLSCipherSuite <cipher-suite-spec>

Данная директива настраивает то, какие шифры будут приниматься и порядок их предпочтения. <cipher-suite-spec> - спецификации шифров для OpenSSL. С помощью команды

        openssl ciphers -v ALL

можно посмотреть подробный список доступных спецификаций шифров.

Кроме отдельных названий шифров, можно применять спецификаторы HIGH, MEDIUM, LOW, EXPORT и EXPORT40, наряду с TLSv1, SSLv3 и SSLv2.

Чтобы посмотреть список шифров в GnuTLS, выполните:

        gnutls-cli -l

При использовании Mozilla NSS применяется набор спецификаций шифров OpenSSL, который переводится во внутренний формат Mozilla NSS. Простого пути посмотреть список шифров из командной строки не существует. Официальный список находится в исходном коде Mozilla NSS в файле sslinfo.c в структуре

       static const SSLCipherSuiteInfo suiteInfo[]

16.2.1.6. TLSRandFile <имя файла>

Данная директива указывает файл, из которого можно получить случайную последовательность бит, когда /dev/urandom недоступен. Если система предоставляет /dev/urandom, то данная директива не нужна, в противном случае необходимо сконфигурировать источник случайных данных. Некоторые системы (например, Linux) предоставляют /dev/urandom по умолчанию, на других (например, Solaris) для этого требуется инсталляция патча, а третьи могут вообще его не поддерживать. В последнем случае нужно установить EGD или PRNGD и задать данную директиву для указания имени сокета EGD/PRNGD. Переменная окружения RANDFILE также может использоваться для указания имени этого файла. Кроме того, при отсутствии этих вариантов, может быть использован файл .rnd в домашней директории пользователя slapd, если таковой существует. Чтобы использовать файл .rnd, просто создайте его и скопируйте туда несколько сотен байт произвольных данных. Этот файл используется только для предоставления начальной последовательности для генератора псевдо-случайных чисел и ему не нужно очень много данных, чтобы работать.

При использовании GnuTLS и Mozilla NSS эта директива игнорируется.

16.2.1.7. TLSDHParamFile <имя файла>

Данная директива указывает файл, содержащий параметры для обмена ключами по алгоритму Диффи-Хеллмана (Diffie-Hellman ephemeral key exchange). Это требуется при использовании основанных на DHE шифров, с том числе всех шифров, основанных на DSA (то есть TLSCertificateKeyFile указывает на ключ DSA), а также шифров RSA, когда в сертификате не указан вариант использования ключа "шифрование ключа" ("key encipherment"). Параметры могут быть сгенерированы с помощью следующей команды:

        openssl dhparam [-dsaparam] -out <filename> <numbits>
			или
        certtool --generate-dh-params --bits <numbits> --outfile <filename>

При использовании Mozilla NSS эта директива игнорируется.

16.2.1.8. TLSVerifyClient { never | allow | try | demand }

Эта директива определяет, какие проверки будут выполняться над клиентскими сертификатами во входящих сессиях TLS, если вообще будут выполняться какие-либо. По умолчанию эта директива установлена в never, в этом случае сервер никогда не запрашивает сертификат у клиента. При установке в allow сервер будет запрашивать сертификат у клиента; если запрашиваемый сертификат не будет предоставлен, сессия будет нормально обработана. Если сертификат предоставлен, но сервер не может его проверить, сертификат будет проигнорирован, и сессия будет обработана нормально, как и в случае, если сертификат не был предоставлен. При установке в try сертификат будет запрошен, и если он не будет предоставлен, сессия будет нормально обработана. Если сертификат предоставлен и не может быть проверен, сессия немедленно завершается. При установке в demand сертификат будет запрошен и действительный сертификат должен быть предоставлен, в противном случае сессия немедленно завершается.

Примечание: Сервер должен запрашивать сертификат клиента при использовании механизма аутентификации EXTERNAL SASL с сессией TLS. Таким образом, перед тем, как пытаться использовать аутентификацию SASL EXTERNAL, должны быть настроены отличные от значения по умолчанию установки TLSVerifyClient. Кроме того, аутентификация с помощью механизма EXTERNAL SASL будет предоставляться лишь тем клиентам, от которых получены действительные клиентские сертификаты.

16.2.2. Конфигурация клиента

Директивы конфигурации клиента в основном соответвуют директивам конфигурации сервера. Названия этих директив различаются и они указываются в ldap.conf(5) вместо slapd.conf(5), но их функциональность практически не отличается. Кроме того, хотя большинство этих параметров могут быть настроены на уровне системы в целом, все они могут быть переопределены отдельными пользователями в своих файлах .ldaprc.

Операция LDAP Start TLS используется в LDAP для инициации переговоров TLS. Все инструменты командной строки OpenLDAP поддерживают флаги -Z и -ZZ, указывающие, что требуется выполнить операцию Start TLS. Последний флаг указывает, что инструмент должен завершить работу, если сессия TLS не может быть установлена, в то время как первый флаг позволяет продолжить выполнение команды.

В среде LDAPv2 TLS, как правило, стартовал при использовании схемы LDAP Secure URI (ldaps://) вместо нормальной схемы LDAP URI (ldap://). Инструменты командной строки OpenLDAP позволяют использовать обе схемы с флагом -H и в опции URI файла ldap.conf(5).

16.2.2.1. TLS_CACERT <имя файла>

Это эквивалент серверной директивы TLSCACertificateFile. Как отмечалось в подразделе Настройка TLS, клиенту обычно требуется знать о большем количестве CA, нежели серверу, но в остальном применимы аналогичные соображения.

16.2.2.2. TLS_CACERTDIR <путь>

Это эквивалент серверной директивы TLSCACertificatePath. Указанная директория также должна управляться с помощью утилиты OpenSSL c_rehash. При использовании Mozilla NSS директория, указанная в параметре <путь>, может содержать базу данных сертификатов/ключей.

16.2.2.3. TLS_CERT <имя файла>

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

При использовании Mozilla NSS, в случае применения базы данных сертификатов/ключей (указанной в TLS_CACERTDIR), данная директива определяет имя сертификата, который нужно использовать:

       TLS_CERT Certificate for Sam Carter

При использовании маркера (token), отличного от встроенного, сначала укажите имя маркера и двоеточие:

       TLS_CERT my hardware device:Certificate for Sam Carter

certutil -L

       certutil -d /path/to/certdbdir -L

16.2.2.4. TLS_KEY <имя файла>

Эта директива указывает файл, содержащий закрытый ключ, соответствующий сертификату, который хранится в файле TLS_CERT. Здесь применимы те же соображения, что и для серверной директивы TLSCertificateKeyFile. Данная директива также определяется отдельно для каждого пользователя.

16.2.2.5. TLS_RANDFILE <filename>

Данная директива аналогична серверной директиве TLSRandFile.

16.2.2.6. TLS_REQCERT { never | allow | try | demand }

Данная директива эквивалентна серверной директиве TLSVerifyClient. Однако, значение по умолчанию для клиентов - demand, и обычно нет оснований, чтобы изменять эту настройку.