Как заставить сервер Open Directory предоставить полную цепочку сертификатов для подключения клиентов?

Эта проблема

Мы создали мастер Open Directory на OSX 10.10 Yosemite + Server.app v4:

$ sudo slapconfig -createldapmasterandadmin admin Administrator 1000

Который генерирует корневой CA, промежуточный CA и SSL-сертификат хоста (все правильно размещено как в системной цепочке для ключей, так и в /etc/certificates каталог). Однако при подключении через SSL slapd предоставляет только сертификат хоста, а не всю цепочку сертификатов:

$ openssl s_client -connect a.b.c:636                        
CONNECTED(00000003)
depth=0 CN = a.b.c, C = GB, emailAddress = a@b.c.
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = a.b.c, C = GB, emailAddress = a@b.c
verify error:num=27:certificate not trusted
verify return:1
depth=0 CN = a.b.c, C = GB, emailAddress = a@b.c
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=a.b.c/C=GB/emailAddress=a@b.c
   i:/CN=IntermediateCA_A.B.C_1/O=b/OU=MACOSX OpenDirectory Intermediate CA/emailAddress=a@b.c
---

Это проблема, конечно, потому что клиенты (которые доверяют только корневому ЦС) не могут проверить сертификат хоста и прервать соединение.

Документированные решения

Согласно Руководству администратора OpenLDAP 2.4, глава 16 "Использование TLS":

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

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

(Во избежание сомнений, тот факт, что slapd затем предоставит цепочку сертификатов для подключения клиентов, которая была недавно подтверждена в списке рассылки openldap- tech - хотя ранее было отмечено, что это приводит к проблемному конфликту, когда для сертификатов клиентов TLS используются разные якоря доверия).

Apple, особенности

Так как сборка Apple использует slapd.d можно было бы ожидать, что эта опция будет настроена через olcTLSCACertificateFile - однако, согласно slapd-config(5) (выделение добавлено):

olcTLSCACertificateFile: <имя файла>

Указывает файл, который содержит сертификаты для всех центров сертификации, которые распознает slapd.

При использовании SecureTransport эта опция недействительна. Вместо этого используйте опцию olcTLSTrustedCerts.

 [ делеция ]

olcTLSTrustedCerts

Перечисляет доверенные сертификаты в системной цепочке для ключей, разделенных '|'. Например: olcTLSTrustedCerts Frobozz, Inc.| Виджеты R Us|www.example.com

Используется SecureTransport вместо olcTLSCACertificateFile и olcTLSCACertificatePath. Игнорируется OpenSSL, GnuTLS и Mozilla NSS.

( SecureTransport - это библиотека SSL от Apple).

Наши попытки...

Удивительно, olcTLSTrustedCerts не был создан в нашем каталоге slapconfig хотя сертификат хоста был назван в (связанный) olcTLSIdentity, Это сказало, slapd в любом случае игнорируя olcTLSIdentity в пользу OPENDIRECTORY_SSL_IDENTITY предпочтение в системной цепочке для ключей:

TLS: предпочтение идентификации OPENDIRECTORY_SSL_IDENTITY переопределило сконфигурированную olcTLSIdentity "abc"

Итак, мы попробовали следующее (как самостоятельно, так и вместе):

  1. Добавление olcTLSTrustedCerts , slapd четко анализирует CN, перечисленные в этом параметре, и находит сертификаты CA в системной цепочке для ключей, так как он регистрирует случаи, когда предоставляется намеренно неправильное значение:

    TLS: SecItemCopyMatching (foo.bar) не выполнен (проверьте настройку olcTLSTrustedCerts): указанный элемент не найден в цепочке для ключей. (-25300)

  2. Удаление OPENDIRECTORY_SSL_IDENTITY предпочтение от системы брелок. slapd больше не жалуется, что olcTLSIdentity был переопределен (и он продолжает поддерживать SSL только до тех пор, пока значение этого параметра конфигурации совпадает с CN сертификата в системной цепочке ключей, в противном случае он жалуется аналогично ошибке, приведенной выше - предполагая, что он использует этот параметр конфигурации, как и ожидалось).

Тем не менее, полная цепочка сертификатов до сих пор не предоставлена ​​для подключения клиентов. Как это можно исправить?

Источник

1 ответ

Решение

Проблема двоякая:

  1. Secure Transport использует цепочку сертификатов в точности так, как это предусмотрено клиентом API. Как документация API, так и комментарии к исходному коду подразумевают (без явного), что это ошибка: в таких обстоятельствах кажется, что Secure Transport должен попытаться построить цепочку сертификатов из системной цепочки для ключей.

  2. Slapd от Apple всегда предоставляет Secure Transport только сертификат идентификации хоста, но не цепочку сертификатов. Смотрите следующие фрагменты, извлеченные из libraries/libldap/tls_st.c:

     ctx->identity_certs = /*
*/ CFArrayCreate(NULL, (const void **) &identRef, 1, &kCFTypeArrayCallBacks);

SSLSetCertificate(ssl, ctx->identity_certs);

Таким образом, в настоящее время Slapd от Apple не может отправить полную цепочку сертификатов.

Источник
Другие вопросы по тегам