Мой Сертификат не работает над всеми машинами
Я установил Centos7 на своем новом сервере бренда. Я использую LDAP в качестве аутентификации. Я развернул свой сертификат на всем сервере, и LDAPS работает с RHEL5, Debian или СОЛЯРИСОМ
На Centos7 я 've получил проблему с sssd, Который я не знал перед этой установкой. LDAP работает, и я могу сделать su - $user хорошо. Когда я обновил в LDAPS, я Потерял эту аутентификацию. На моем сервере LDAP у меня есть эта ошибка:
[30/oct./2014:16:32:05 +0100] DISCONNECT conn=735741 reason="Protocol Error" msg="The client sent a request to Directory Server which did not decode well as LDAP message : javax.net.ssl.SSLException: Received fatal alert: bad_certificate"
Почему тот же сертификат работает над другим сервером а не над этим
Спасибо за ответ.
Спасибо BillThor,
Но система кажется, делают это для меня как, символьная ссылка с возвратом хеша была создана. По тому, как я изменил эту строку в ldap.conf
TLS_CACERT /etc/openldap/cacerts/xxxxxx.0
Я протестировал его с ldapsearch -x -d3 у команды и меня есть это сообщения об ошибках:
attempting to connect:
connect success
TLS: loaded CA certificate file /etc/openldap/cacerts/xxxxxx.0.
tls_write: want=157, written=157
.../...
certificate is not valid - error -8016:The certificate was signed using a signature algorithm that is disabled because it is not secure
TLS: error: connect - force handshake failure: errno 0 - moznss error -8157
TLS: can't connect: TLS error -8157:Certificate extension not found..
ldap_err2string
Это странно, потому что весь мой сервер принимает этот CA, но не новый под CENTOS7 Какая-либо идея, куда прибывает из?
Люди, Спасибо за все.
Я нашел эти ссылки :
https://bugzilla.redhat.com/show_bug.cgi?id=895513
и эту :
http://www.unixmen.com/rhel-centos-6-4-ldap-md5-certificate-error-caused-by-nss-3-14-update/
У меня есть одна проблема для тестирования этого решения, как поставить эту следующую строку в GRUB2
systemd.setenv=NSS_HASH_ALG_SUPPORT=+MD5
Итак, у меня 'есть ответ здесь : добавить systemd setenv в grub2
Спасибо.
Помимо развертывания сертификата, вам может потребоваться создать символическую ссылку для сертификата. Для этого предусмотрена утилита c_rehash . Вы также можете использовать команду openssl x509 -noout -hash -in vsignss.pem , чтобы получить значение хеш-функции для сертификата. Символьные ссылки имеют суффикс .0 .
Кроме того, вы можете добавить сертификат в конфигурацию LDAP. Это может быть /etc/ldap/ldap.conf . В старых версиях также были настройки в pam_ldap.conf .
РЕДАКТИРОВАТЬ: ошибка подтверждения может быть результатом отключения SSLv3 или иного ограничения доступных алгоритмов. Недавно я отключил SLLv3 из-за уязвимости Poodle . В конце я включил команды, которые использовал для проверки соединений. В вашем случае попробуйте такие команды:
openssl s_client -connect localhost:ldap
openssl s_client -quiet -connect localhost:ldap -ssl3
openssl s_client -quiet -connect localhost:ldap -tls1
openssl s_client -quiet -connect localhost:ldap -tls1_2
Вы не указали, как вы установили файл сертификата CA. При использовании RH или производных вы можете просто использовать информацию из man update-ca-trust, tldr; версия:
- скопируйте файл сертификата CA в / etc / pki / ca-trust / source / anchors /
- запустите update-ca-trust enable && update-ca-trust
- прибыль!
update -ca-trust поставляется с пакетом ca-сертификатов, который находится в базовом репозитории.
Это должно позаботиться почти обо всем. По моему опыту, только php является особенным и требует особого внимания, указав в /etc/openldap/ldap.conf (для всей системы) или $ HOME / .ldaprc (только для одного пользователя):
TLS_CACERT / etc / pki / ca- trust / extract / pem / tls-ca-bundle.pem
Кстати, этим путем TLS_CACERT управляет инструмент update-ca-trust.
Я думаю, что этот бит, вероятно, является ключевым:
certificate is not valid - error -8016:The certificate was signed using a signature algorithm that is disabled because it is not secure
Я предполагаю, что сервер, который отказывается от сертификата, может быть настроен не принимать подписи на основе SHA-1. Я не криптограф, но из других проблем с SSL, которые привлекли мое внимание в последнее время, я не думаю о других, которые мне кажутся подходящими.
Вы должны отнестись к моему предположению о деталях с долей скептицизма, но должны иметь в виду возможность того, что причина, по которой этот сервер отказывается от вашего сертификата, вполне обоснована, и что серверы, которые принимают сертификат, должны проверьте их конфигурацию.
РЕДАКТИРОВАТЬ: Здесь больше описания проблемы и обходного пути для ldapsearch: https://bugzilla.redhat.com/show_bug.cgi?id=895513 .
Похоже, проблема может быть в MD5, а не в SHA-1, как я догадывался. Похоже, что начиная с ldapsearch 3.14:
Certificate signatures that make use of the MD5 hash algorithm will now
be rejected by default. Support for MD5 may be manually enabled (but is
discouraged) by setting the environment variable of
"NSS_HASH_ALG_SUPPORT=+MD5"
or by using the NSS_SetAlgorithmPolicy function. Note that SSL cipher
suites with "MD5" in their names are NOT disabled by this change; those
cipher suites use HMAC-MD5, not plain MD5, and are still considered safe.
Учитывая, что ваша ошибка находится на сервере, вы, вероятно, могли бы решить проблему только в этой системе.
Если проблема связана с MD5, я бы рекомендовал вам тщательно подумать, прежде чем используя этот подход. Атака на сертификаты MD5 очень практична, и если вы не избавляетесь от сертификатов MD5, вам следует спросить, зачем вы вообще используете ЦС.
http://www.win.tue.nl/hashclash/rogue-ca/
Если речь идет о более новой проблеме с SHA-1, атака сложнее, и ее практическая ценность зависит от длины ключа подписи СА.