Проблема

Мы создали Открыть ведущее устройство Directory на Йосемити OSX 10.10 + 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
---

Это - проблема, конечно, потому что клиентам (кто доверяет только корневому CA) не удается проверить сертификат хоста и прервать соединение.

Зарегистрированные решения

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

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

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

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

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

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

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

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

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

[ deletia ]

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 "a.b.c"

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

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

   TLS: SecItemCopyMatching (foo.bar) неудавшийся (проверяют olcTLSTrustedCerts, устанавливающий): указанный объект не мог быть найден в связке ключей. (-25300)

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

Все же полная цепочка сертификата все еще не предоставляется соединяющимся клиентам. Как это может быть зафиксировано?