LINUX.ORG.RU
решено ФорумAdmin

Вопрос по sssd и openssl

 , ,


0

2

Добрый день.

Есть вопрос по поводу сертификатов в домене. Пытаюсь настроить авторизацию через sssd по ldaps из AD, но возникает проблема. Есть несколько контроллеров, каждый со своим сертификатом. Есть один общий СА. Когда подключаюсь через ldaps://dc01.example.com с указанием сертификата СА, всё проходит ок. Но я хотел бы сделать немного более устойчивое соединение (да и среда распределенная), и подключаться к ldaps://example.com, а там уже ближайший DNS отдаст мне адрес ближайшего DC, к которому я буду подключаться. Проблема в том, что openssl рубит соединение, потому что имя сервера, к которому я в итоге подключаюсь (dc01.example.com) в сертификате не соответствует хостнейму, к которому я инициировал подключение (example.com). Правильно ли я понимаю, что чтобы избежать этой ошибки, мне нужно указать DNS=example.com в Subject Alternative Name каждого сертификата dc? Или эта схема работать не будет в любом случае, и ошибки с «подменой хостнейма» тут не избежать?

Спасибо.


Правильно ли я понимаю, что чтобы избежать этой ошибки, мне нужно указать DNS=example.com в Subject Alternative Name каждого сертификата dc?

Если в subject указан example.com, то в Alternative Name можно занести запись *.example.com - все поддомены (например, dc01.example.com) на один уровень она накроет. Только учти, что работает это ровно на один уровень вверх - test.dc01.example.com уже не накроет и надо будет добавлять *.dc01.example.com

Vovka-Korovka ★★★★★
()

Кстати, похоже неправильно понял вопрос - в каждом сертификате сервера, к которому ты в итоге коннектишься, действительно должен быть прописан домен, через который осуществляется доступ - можно запихнуть в Alternative Name.

Vovka-Korovka ★★★★★
()
Ответ на: комментарий от Vovka-Korovka

Так не нужно делать. Не знаю, как там что в AD, но нормальный браузер на сертификат, где в altnames будет '*' покажет предупреждение. По крайней мере если мы говорим о валидных сертификатах. Нужно покупать wildcard сертификат.

anonymous_sama ★★★★★
()
Ответ на: комментарий от Vovka-Korovka

Насчет *.example.com вопрос спорный, поскольку тогда им сможет представляться вообще любой компьютер в сети. Действительно, поставлю имя домена (т.к. DNS отдает ограниченный набор контроллеров домена). Попробую, отпишусь. Спасибо :)

fcctoo
() автор топика
Ответ на: комментарий от anonymous_sama

Так не нужно делать. Не знаю, как там что в AD, но нормальный браузер на сертификат, где в altnames будет '*' покажет предупреждение.

Ты что-то путаешь. Вайлдкарды в Alternative Names обычное дело. Вот пример из гугловского сертификата

X509v3 Subject Alternative Name: 
                DNS:*.google.com, DNS:*.android.com, DNS:*.appengine.google.com, DNS:*.cloud.google.com, DNS:*.google-analytics.com, DNS:*.google.ca, DNS:*.google.cl, DNS:*.google.co.in, DNS:*.google.co.jp, DNS:*.google.co.uk, DNS:*.google.com.ar, DNS:*.google.com.au, DNS:*.google.com.br, DNS:*.google.com.co, DNS:*.google.com.mx, DNS:*.google.com.tr, DNS:*.google.com.vn, DNS:*.google.de, DNS:*.google.es, DNS:*.google.fr, DNS:*.google.hu, DNS:*.google.it, DNS:*.google.nl, DNS:*.google.pl, DNS:*.google.pt, DNS:*.googleadapis.com, DNS:*.googleapis.cn, DNS:*.googlecommerce.com, DNS:*.googlevideo.com, DNS:*.gstatic.cn, DNS:*.gstatic.com, DNS:*.gvt1.com, DNS:*.gvt2.com, DNS:*.metric.gstatic.com, DNS:*.urchin.com, DNS:*.url.google.com, DNS:*.youtube-nocookie.com, DNS:*.youtube.com, DNS:*.youtubeeducation.com, DNS:*.ytimg.com, DNS:android.com, DNS:g.co, DNS:goo.gl, DNS:google-analytics.com, DNS:google.com, DNS:googlecommerce.com, DNS:urchin.com, DNS:youtu.be, DNS:youtube.com, DNS:youtubeeducation.com

Да и что такое, по-твоему wildcard сертификат? Эти wildcard нужно куда впихивать - либо в Subject, либо в Alternative Names.

Vovka-Korovka ★★★★★
()
Ответ на: комментарий от anonymous_sama

Да, но некоторые издатели продают сертификаты с wildcard в SAN. И, емнип, до сих пор не договорились, хорошо это или плохо.

fcctoo
() автор топика
Ответ на: комментарий от fcctoo

Насчет *.example.com вопрос спорный, поскольку тогда им сможет представляться вообще любой компьютер в сети.

Точно также как и example.com. Для этого и придумали SSL.

Vovka-Korovka ★★★★★
()
Ответ на: комментарий от Vovka-Korovka

Гугловский сертификат уже в твоем браузере, плохой пример. Да и что говорить, ты еще попробуй такой CSR подписать, если будешь покупать обычный сертификат. Раньше подписывали, да.

anonymous_sama ★★★★★
()
Ответ на: комментарий от anonymous_sama

Гугловский сертификат уже в твоем браузере, плохой пример.

Ты опять что-то путаешь. Даже если я напрямую добавлю сертификат гугла в себе браузер, это не избавит от необходимости в верификации хоста - это то место, где работает Subject и Alternative Name. Зайди на https://www.youtube.com и посмотри на subject сертификата, а потом подумай как оно работает. И почитай про hostname verification.

Да и что говорить, ты еще попробуй такой CSR подписать, если будешь покупать обычный сертификат.

Подпишут, если денюжку заплатишь. Wildсard сертификаты просто стоят дороже.

Vovka-Korovka ★★★★★
()
Ответ на: комментарий от Vovka-Korovka

Даже если я напрямую добавлю сертификат гугла в себе браузер, это не избавит от необходимости в верификации хоста - это то место, где работает Subject и Alternative Name.

Согласен. Но я бы не говорил по '*' в altnames если бы это придумал. На stackexchange был тред, где человек аргументировано объяснял и описывал, с какими браузерами будут проблемы при «*» в altnames. Сейчас я это найти не могу, но я это хорошо запомнил.

anonymous_sama ★★★★★
()
Ответ на: комментарий от anonymous_sama

На stackexchange был тред, где человек аргументировано объяснял и описывал, с какими браузерами будут проблемы при «*» в altnames

Это проблема этих браузеров. Во всех современных это работает, так как встречается повсеместно - иначе даже https://www.domain.com работать не будет. А, например, для одноклассников (ok.ru) в subject вообще домен не указан, а все домены перечислены в alternative. Но если ссылку найдешь, то скинь - я с интересом гляну.

Vovka-Korovka ★★★★★
()
Последнее исправление: Vovka-Korovka (всего исправлений: 1)
Ответ на: комментарий от anonymous_sama

И еще, есть целое RFC , посвященное этому вопросу

http://www.rfc-editor.org/rfc/rfc6125.txt

Там как раз рекомендуется Subject вообще не использовать

For the secondary audiences, in essence this document encourages certification authorities, application service providers, and application client developers to coalesce on the following practices:

o Move away from including and checking strings that look like domain names in the subject's Common Name.

o Move toward including and checking DNS domain names via the subjectAlternativeName extension designed for that purpose: dNSName.

Vovka-Korovka ★★★★★
()

Если интересует более безопасно то Alternative Name отлично работает. Но Я бы рекомендовал перечислить несколько uri в директиве ldap_uri.

Если же не принципиально то ldap_tls_reqcert = allow в /etc/sssd/sssd.conf вполне поможет.

zunkree
()
Последнее исправление: zunkree (всего исправлений: 1)
Ответ на: комментарий от Vovka-Korovka

Точно также как и example.com

Разве он не действует только на один уровень? т.е. сертификатом с 'DNS=example.com' в SAN смогут валидно представляться и dc01.example.com и pc99.example.com, даже если dns не резолвит example.com в pc99?

fcctoo
() автор топика
Ответ на: комментарий от zunkree

Но Я бы рекомендовал перечислить несколько uri в директиве ldap_uri.

Это вариант, но example.com резолвит около десяти контроллеров, и при обращении к каждому из них первым он отдаст свой ip. Домен распределенный, поэтому при указании списка dc обращаться они будут всегда сначала к первому в этом списке, как бы далеко он ни был. Для отказоустойчивости я всё равно явно укажу несколько dc после example.com.

К сожалению, проверять сертификат принципиально.

fcctoo
() автор топика
Ответ на: комментарий от fcctoo

т.е. сертификатом с 'DNS=example.com' в SAN смогут валидно представляться и dc01.example.com и pc99.example.com, даже если dns не резолвит example.com в pc99?

«DNS=example.com» покрывает только один домен example.com - для любого поддомена уже не работает. Что-бы покрыть один поддомен вверх нужно использовать wildcard - DNS=*.example.com. Причем учти, что *.example.com не покрывает сам домен example.com. Поэтому обычно в Alternative Name прописывают обе записи.

Тут еще нужно учитывать, что существуют разные имплементации верификации хоста и даже в rfc допускаются разброд и шатание. В тот же openssl верификацию хоста добавили совсем недавно - в версии 1.0.2, поэтому приложения (тот же curl) вынуждены были реализовывать свою имплементацию - причем реализовывать могли по разному. Но, даже если взять тот же openssl - то его можно заставить работать по разному. По дефолту он работает, как я описал выше - example.com накрывает только домен, *.example.com - накрывает на один поддомен выше. Но можно настроить так, что *.example.com накроет все возможные поддомены, или можно вообще запретить wildcard.

Vovka-Korovka ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.