Мне выдал сертификат человек, который управляет нашим сервером Active Directory, поэтому я могу использовать LDAPS, но не могу заставить его работать. При проверке с помощью openssl:
openssl s_client -connect domain.com:636 -CAfile ~/filename.pem
Я просто получаю Verify return code: 20 (unable to get local issuer certificate) каждый раз.
Мне интересно, не настроен ли сервер неправильно, потому что я пытался получить сертификат прямо с сервера следующим образом (от клиента Ubunutu 16.04):
openssl s_client -host domain.com -port 636 -prexit -showcerts
И даже при этом я получаю то же сообщение об ошибке.
А если я наберу:
openssl s_client -host google.com -port 443 -prexit -showcerts
я получил Verify return code: 0 (ok)
Я пробовал копировать сертификаты в /etc/ssl/certs. Я пробовал использовать -CApath и -CAfile выдавать серверу различные сертификаты.
На самом деле я спрашиваю, означает ли код ошибки 20 в ответ на openssl с -showcerts, что сервер действительно неправильно настроен, или я просто делаю это неправильно, потому что мне не хотелось бы тратить больше времени на клиента, когда он сервер, который плохо себя ведет.
openssl x509 -noout -text -in имя_файла.pem
возвращает (с некоторыми исправлениями):
Сертификат:
Data:
Version: 3 (0x2)
Serial Number:
xxxxxxxxxxxxxxxx
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=My organisation RootCA
Validity
Not Before: May 20 13:11:34 2016 GMT
Not After : May 20 13:21:34 2021 GMT
Subject: DC=org, DC=example, CN=My organisation Issuing CA
А потом куча вещей, которые выглядят нормально. Это корневой сертификат, не так ли? В конце концов, там написано RootCA.
О да, и если я подам этот сертификат,
openssl s_client -connect domain.com:636 -CAfile file.pem
Я получаю другое сообщение об ошибке:
Проверьте код возврата: 2 (невозможно получить сертификат эмитента)
Такое ощущение, что у меня есть один сертификат, а другого нет.
Я получил еще один, используя nmap --ssl-cert, но, похоже, я не могу получить с ним ничего, кроме кода ошибки 20.
Я предполагаю, что вы получили файл, содержащий единственный корневой сертификат CA для проверки сертификата сервера TLS. Убедитесь, что он закодирован в ASCII-кодировке base64 (он же PEM).
Обычно центр сертификации не использует ключ корневого ЦС для прямой подписи открытого ключа сервера TLS. По соображениям безопасности для этого используется промежуточный ЦС, также часто называемый выдающим ЦС.
Теперь клиент TLS должен проверить всю цепочку сертификатов CA и получить доступ к промежуточному сертификату CA и корневому сертификату CA.
В случае хорошо настроенного TLS-сервера вам нужен только сертификат корневого ЦС в локальном файле, потому что сервер отправляет промежуточный сертификат ЦС во время TLS-соединения. Но некоторые серверы TLS плохо настроены.
Вы должны увидеть, что происходит с
openssl s_client -connect ldap.example.com:636 -showcerts
как вы уже сделали.
Если у вас нет сертификата корневого ЦС, спросите человека, который дал вам сертификат промежуточного ЦС.
Или, если у вас есть рабочая станция Windows в этом домене AD, весьма вероятно, что вы найдете сертификат корневого ЦС в хранилище доверенных сертификатов вашей установки Windows.
Это корневой сертификат, не так ли? В конце концов, там написано RootCA.
Issuer: CN=My organisation RootCA
Validity
Not Before: May 20 13:11:34 2016 GMT
Not After : May 20 13:21:34 2021 GMT
Subject: DC=org, DC=example, CN=My organisation Issuing CA
Нет, это не корневой сертификат, он просто подписан корневым сертификатом. Вам нужен сертификат, который выглядит так:
Issuer: CN=My organisation RootCA
Subject: CN=My organisation RootCA
Другими словами, и Issuer, и Subject должны быть вашим RootCA.
Поскольку он, вероятно, был создан на машине Windows, перейдите в диспетчер сертификатов и экспортируйте корневой ЦС (только сертификат, вам не нужен ключ).