Я пытался заставить работать SSL-соединение с сервером LDAPS (Active Directory), но все еще возникают проблемы. Я пробовал использовать это:
openssl s_client -connect the.server.edu:3269
Со следующим результатом:
verify error:num=20:unable to get local issuer certificate
Я подумал: хорошо, сервер - это старый производственный сервер, которому несколько лет. Может быть, ЦС нет. Затем я вытащил сертификат из вывода в файл pem и попробовал:
openssl s_client -CAfile mycert.pem -connect the.server.edu:3269
И это тоже не сработало.
Что мне не хватает? Разве это не должно работать ВСЕГДА?
Вот что я вижу как имя сертификата CA:
depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at //www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
verify error:num=20:unable to get local issuer certificate
verify return:0
Это было имя сертификата, который я импортировал после того, как выполнил -showcerts во второй попытке выше. Я перечислил сертификаты в хранилище ключей, выполнив следующие действия:
$JAVA_HOME/bin/keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts
Я вижу сертификат CA там.
Alias name: versign2006
Creation date: Jan 21, 2011
Entry type: trustedCertEntry
Owner: CN=VeriSign Class 3 International Server CA - G3, OU=Terms of use at www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Serial number: 641be820ce020813f32d4d2d95d67e67
Valid from: Sun Feb 07 19:00:00 EST 2010 until: Fri Feb 07 18:59:59 EST 2020
Certificate fingerprints:
MD5: BA:B0:65:B4:3B:9C:E8:40:30:21:7D:C5:C6:CD:3F:EB
SHA1: B1:8D:9D:19:56:69:BA:0F:78:29:51:75:66:C2:5F:42:2A:27:71:04
Чтобы убедиться, что openssl использует хранилище ключей, которое я использую с сервером, я использую аргумент -CAfile:
openssl s_client -connect the.server.edu:3269 -CAfile $JAVA_HOME/jre/lib/security/cacerts
Зная, что у хранилища ключей Java для CA есть пароль, я попытался использовать параметр -pass pass: password следующим образом:
openssl s_client -connect the.server.edu:3269 -CAfile $JAVA_HOME/jre/lib/security/cacerts -pass pass:changeit
но это тоже не сработало.
Что забавно, так это то, что в файле cacerts есть пароль, и openssl не жалуется, что не может прочитать файл cacerts. Мне это кажется подозрительным. Звонит ли это или что-то еще?
Эта ошибка - это способ openssl сказать: «Я не могу проследить цепочку сертификатов до доверенного корня». Я только что выполнил ту же команду на своих серверах AD и получил полную цепочку сертификатов, но в верхнем сертификате есть именно такая ошибка. Если у вас есть pub-ключ ЦС, подписавшего сертификат, вы можете указать его с помощью -CAfile или -CApath параметры
Я пытался заставить работать SSL-соединение с сервером LDAPS (Active Directory), но все еще возникают проблемы. Я пробовал использовать это:
Если вы используете OpenLDAP, вы можете установить:
TLS_REQCERT=never
в твоем openldap.conf файл, который указывает OpenLDAP не пытаться проверять сертификат. Есть аналогичный вариант, если вы выполняете аутентификацию LDAP с Apache.
Если вы действительно хотите выполнить проверку сертификата, может помочь следующее:
Что мне не хватает? Разве это не должно работать ВСЕГДА?
Я так не думаю. Хотя следующее может показаться окончательным, на самом деле это просто мой лучший гость:
То, что вы пробовали, будет работать только для самозаверяющего сертификата. Поскольку сертификат был фактически выпущен центром сертификации Windows, попытка использовать сертификат сервера в качестве аргумента для -CAfile ничего тебе не дадут.
Получил сертификат CA, проделав то же самое с опцией -showcerts, взял другой сертификат. Это должен быть сертификат CA, верно?
Не обязательно, нет. Нет гарантии, что удаленный сервер представляет сертификат CA в своих выходных данных. Вам нужно сначала посмотреть на издателя сертификата сервера:
openssl x509 -in server.crt -noout -text | grep Issuer
... а затем посмотрите, соответствует ли один из других сертификатов этому издателю.