Windows 2012R2, кажется, автоматически загружает и устанавливает промежуточные корневые сертификаты
Идеальное решение: Исправьте свой бюрократический каталог LDAP (включите схему POSIX).
Альтернативные решения:
- Используйте одну копию/конфигурацию
pam_ldapдля подлинных данных и другого для данных аккаунта - Пользовательская компиляция версия
pam_ldapсделать то, что Вы хотите (волосатый) - Используйте LDIF для импорта имен пользователей/паролей в OpenLDAP (информационно-синхронизирующие головные боли).
Файл ".pfx" представляет собой архив PKCS # 12 : формат файла архива для хранение множества объектов криптографии в одном файле. Это обычно используется для [snip] связывания сертификата X.509 и всех членов цепочка доверия.
Вы импортировали промежуточный сертификат вместе с сертификатом SSL.
Я тоже видел, как это происходило в прошлом, и мы столкнулись с некоторыми проблемами, заставившими меня посмотреть на это. Моя система Windows 7 (SP1, Enterprise) делает то же самое. И копаясь в Wireshark и Process Monitor Sysinternals, можно увидеть следующее:
В одном из моих хранилищ сертификатов есть сертификат, подписанный COMODO, для которого сертификат в цепочке (b9b4c7a ...) недоступен ни в одном из моих хранилищ сертификатов. Но у сертификата есть свойство «Доступ к информации о полномочиях», которое содержит URL http://crt.comodoca.com/COMODOHigh-AssuranceSecureServerCA.crt .
Открытие этого сертификата (через mmc .exe "Сертификаты") для отображения стандартного диалогового окна "Сертификат" Windows, запускает загрузку указанного выше URL-адреса, и полученный сертификат b9b4c7a ... помещается в хранилище промежуточных центров сертификации для текущий пользователь .
И он также кэшируется в c: \ users \ с записью в папке метаданных и Content .
Если я сейчас повторю то же действие (после удаления сертификата из хранилища промежуточных центров сертификации текущего пользователя), он будет восстановлен снова, но на этот раз он не загружается из COMODO, а копируется из CryptnewUrlCache . [12 120] Мне не удалось найти никакой документации по этой функции от Microsoft. Однако они, похоже, следуют RFC 5280, раздел 4.2.2.1, «Доступ к информации о полномочиях» , в котором говорится:
указанное описание эмитентов ЦС предназначено для поддержки сертификата пользователей при выборе пути сертификации, который заканчивается в точка, которой доверяет пользователь сертификата.
Все зависит от формата сертификата, полученного вами от вашего центра сертификации, GlobalSign, Comodo, Symantec (ранее VeriSign). Если вы получили сертификат в формате PKCS # 7, он будет включать корень и промежуточные звенья. Если вы получили сертификат в x.509, он обычно не включает корень и промежуточные звенья, поэтому вам нужно будет получить эти файлы с вашего сайта Cert Authority. Я установил сертификаты в Windows IIS 6,7 и 8, и, насколько мне известно, рекомендуемый формат - PKCS # 7. Я не использовал openssl. Корневая и промежуточная версии устанавливаются автоматически, когда вы проходите через мастер.
Вы можете просмотреть полученный файл сертификата, изменив его на файл .txt. Обычно вы увидите === Begin Certificate === и ==== End Certificate ===. Если вы видите 3 или 4 из них, то корень и / или промежуточные звенья объединены в этот файл сертификата. Если вы видите только один, то вам нужно будет получить root и промежуточное звено с сайта вашего центра сертификации.