LINUX.ORG.RU
ФорумAdmin

Мини зоопарк SSL: как правильно сделать?

 , ,


1

2

Коллеги, имеется следующая сеть:

  • Десяток внутренних сайтов - https (из них один критичен в плане downtime).
  • Пару сайтов, https - смотрят на улицу (downtime в пару секунд ночью - без проблем).
  • smtps/imaps - смотрит внутрь.
  • smtps/imaps - смотрит на улицу.
  • xmpps - живёт внутри.

Надоело продлять руками сертификаты для всего этого дела...

Как можно поступить?

(Вариант 1) wildcard:

  • поговаривают, что не очень приветствуется, т.к. не очень безопасен, ибо *.domain.com. И в частности, не все почтовые клиенты будут рады такому сертификату. Да и не понятно, как браузеры к нему отнесутся...
  • мне сделают под https. А у меня ещё xmpps... Как тут быть, тогда?
  • не очень бюджетно

(Вариант 2) свой CA, без поддержки OCSP (для внутренних доменов):

  • просто, быстро, без проблем с продлением
  • спокойно можно выпустить сертификат и для xmpps, smtps/imaps
  • smtps/imaps - почтовые клиенты из вне, будут ругаться, что нету сертификата УЦ (в моём случае - терпимо). Если конечно, мобильные почтовые клиенты, не начнут отрыгивать такие сертификаты в будущем...
  • есть какой-нибудь webui для openssl?
  • не очень безопасно, ибо нету revoke list + OCSP
  • бесплатно

Для внешних https сервисов (Let's encrypt):

  • просто, быстро, без проблем с продлением
  • бесплатно

Может, имеются, ещё, какие-либо варианты?

★★★★★

Последнее исправление: DALDON (всего исправлений: 2)

Let's encrypt наше всё. Но если у тебя нет IP-ек чтобы каждый домен третьего уровня вешать на них - тогда п.1 (потому что он универсален, клиенты все понимают, но дорого)

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

wildcard'ы они не поддерживают, а по поводу SNI вопрос открыт, я видел только обсуждения.

zgen ★★★★★
()

Могу заверить - Let's encrypt-овый, сгенерённый официальным клиентом без плясок, сходу встал на XMPP-сервер Prosody (надо только всю цепочку сертов подсунуть), XMPP Observatory признаёт валидность.

Вариант «свой CA» имеет одно идеологическое преимущество (независимость от CA LetsEncrypt), и одно практическое неудобство (на каждый девайс вручную импортировать).

Вариант wildcard, как и вообще любой вариант других CA, я считаю бессмысленным рассматривать вообще. Либо дорого (дороже чем бесплатно), либо геморно (StartSSL), либо то и другое (не проверял на своей шкуре, но догадываюсь).

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

Проблема смотри в чём, я уже внимательно читал про этот клиент. Так вот, в чём проблема, представь себе, что у меня есть десяток внутренних сайтов на https, ну там для разработки, тестирования, внутренние сервисы, wiki, и т.д. - так вот, let's encrypt, чтобы подтвердить моё владение доменом, заставляет меня же или иметь ddns, или выкладывать некие файлики на web сервер внешний, по тому домену, на который я хочу получить сертификат. - ВЕРНО? Я блин, не до конца уверен. Но вроде это так... - А раз, так, то ну его нафиг этот let's encrypt - мне надо будет тогда регать во внешнем DNS свои внутренние сервисы, делать какие-то сайты заглушки, только ради получения сертификата... Короче, ужас, ужас. - Прав я или нет?

К тому же, let's encrypt - не умеет xmpp делать. Это я считаю, за гранью... Ну оно пока бета, но всё же...

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от Andrey_Utkin

Читал, не одно обсуждение про xmpp, там говорят, что есть специальные поля в сертификате, которые не поддерживает LetsEncrypt. Авторы говорят - что xmpp, им не важен. Сперва надо сделать https, всем и каждому. А xmpp - может быть, через очень много времени. Не ужели, они передумали..?!

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

Выглядит здорово! Но если нету кластера из jabber серверов, то выходит, раз в три месяца надо будет перезапускать сервер, для смены сертификата. У меня ejabberd. Интересно, а pidgin, кушает серты летсэнкрипта? Не пробовал?

Спасибо!

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 2)
Ответ на: комментарий от redixin

Блин, значит я прав... Ну не резонно мне, внутренний домен wiki, выбрасывать на улицу. Пусть даже и с сайтом заглушкой. Больно сложно, и мучительно.

DALDON ★★★★★
() автор топика

Сколько не работал с wildcard - проблем никогда небыло (HTTP/IMAP/POP3).

Свой CA тоже можно завести, только его нужно будет всем клиентам в базу заносить.

А вот Let's encrypt я немного не понимаю, и за то чтоб CA забанили :) Смысл в SSL сертификате если его может получить любой желающий за 5 минут без валидации личности ...

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

Эм... Так, 99 процентов сертификатов, в Интернете, без проверки личности выдаются. Сертификаты, они же разные бывают. Let's encrypt - это уровень DV. Есть over100k контор, которые тебе продадут такой же DV, только за деньги. Т.е. без проверки личности.

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

Я занимался версией под веб. Вобщем, ничего сложного. Может допилю когда-нибудь :)

xca может быть распределенным, если напишешь баш-скрипт, который кидает твою БД на нужный сервер.

P.S. На sf.net есть какая-то веб-морда оооочень навороченная. На Java.

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

Ок. Но в целом, я хочу понять концепт, и понять, какие может ещё есть варианты, которые, я не вижу.

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

Насчет OCSP, тут наткнулся (будет интересно, если не читал еще): https://www.imperialviolet.org/2014/04/19/revchecking.html

Я бы на твоем месте остановился на xca, а потом уже думал что дальше делать. Вопрос автоматизации (раскидывания по сервакам) у тебя будет в любом случае открыт. А решается он несложно, когда есть общее хранилище откуда ты файлики будешь выцеплять.

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

Спасибо! Весьма интересно про hard-fail, soft-fail. Отличная статья. В общем, CRL - более удобен. Хотя, и тоже не панацея.

Посмотрю ещё на xca, но очень печалит, то, что оно не web. Кидать базу на сервер - уже наелся я... - Используем keepass, раз в несколько месяцев, случаются split-brain, когда пуш делает несколько человек...

DALDON ★★★★★
() автор топика

Использую XCA для обслуживания примерно такого же зоопарка.
Там поднят свой CA и выпущено по отдельному сертификату для каждого сервиса в целях безопасности.
Бесплатных альтернатив не вижу.
В конторе домен резолвится в пределах корпоративной сети, наружу прокинуть нереально по организационным причинам, менять тоже нереально.

ArcFi
()
Ответ на: комментарий от gh0stwizard

Да вот я думаю, а что если... Если вот так:

Внутри:

  • Поднимаю EJBCA (и даю доступ кому надо).
  • Всем Windows через group policy, кидаю rootCA.
  • Всем Linux, через ansible кидаю rootCA.
  • Делаю сертификаты для https,smtp,imap,xmpp

Снаружи:

  • На обратном прокси серевре, поднимаю let's encrypt, и оно для моих внешних сервисов,мне само начинает заботиться о https.

Почта:

  • Внутри и снаружи представляю локальный сертификат. Внешние клиенты будут просто добавлять себе в исключение сертификат, или ставить наш rootCA.

Проблема, в том, что в EJBCA, я очень мало чего понимаю. Понял, что там есть некие профили, для генерации сертификатов и средства аудита, отзыва. Что касаемо RA - функций, вообще не понимаю, о чём это даже...

Стоит попробовать такой путь?

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

XCA - очень прост, и как раз для меня! Видел простые инструкции как за три минуты, всё сделать. Но вот, как организовать доступ к нему нескольким человекам - вот это проблема... И пока, не очень представляю, как её можно решить.

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

Честно, я не ковырял EJBCA. Потому что мои задачи более мелких масштабов.

Попробуй. По идее, там есть все что нужно. Ну, и вариантов-то у тебя не так много :) Потом расскажешь что и как.

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

У меня RW-доступ к базе с одного компа, однако к его рабочему столу имеется удалённый доступ.
Кроме того есть ещё несколько хостов, которые синкают базу и работают в режиме RO.

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

А нафиг режим RO?

В общем, пока XCA, выглядит более адекватным решением. Можно сделать доступ по vnc на сервер с правами RW

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

Да в общем, то хорошо что мне рассказали про XCA. Думаю, быть может организовать VNC, до узла с XCA, и не колотить мозг, просто. В случае чего, насколько я понял, с XCA на EJBCA - можно уехать.

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

А нафиг режим RO?

Для мониторинга актуальности, для экспорта в другие подсистемы.
Сейчас оно у меня обслуживает не только свой CA, но и хранит сертификаты и запросы сторонних.

ArcFi
()
Ответ на: комментарий от DALDON

Тот же вопрос. Хотелось бы увидеть конкретные сайты общеизвестных организаций с таким сертификатом.

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

Если я правильно понял вопрос: отвечу.

Общеизвестные организации, я думаю, пользуют, OV/EV, конечно. Так-как, они осуществляют хранение ПД и/или финансовые операции.

Но есть же туча мелких компаний, которые имеют свои сайты. Например, мой городской провайдер Интернет - сейчас посмотрел, у них обычный, DV, сертификат.

Любимый ЛОР, тоже юзает DV

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 2)
Ответ на: комментарий от DALDON

Но у ЛОРа он выпущен RapidSSL, никаких вопросов. А в случае с сабжем, что там будет написано-то?

Deleted
()
Ответ на: комментарий от DALDON

Почта:

  • Внутри и снаружи представляю локальный сертификат. Внешние клиенты будут просто добавлять себе в исключение сертификат, или ставить наш rootCA.


Под почтой подразумеваешь вебморду или IMAP? Если да, то добавление вручную прокатит. Если ты про SMTP, то все сторонние сервера тебя пошлют лесом и (в зависимости от прямоты рук админа их настраивавшего и желаний левой пятки инженеров ИБ) будут или делать fallback на соединение без шифрования или вообще будут твою почту отправлять прямо в /dev/null

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

Да нету разницы кем оно выпущено. Есть уровень DV. Всё. Другое дело, что пока let's encrypt, ещё не все приложения могут доверять. Но основые браузеры - проблем не будут иметь так что, реально, разницы нету где выпускаться. Ну и, конечно, если let's encrypt ляжет больше чем на 90 дней, то пиши пропало. А так - без разницы.

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

Подразумеваю почтовых клиентов, конечно (smtps/imaps). На 25 порт, SSL, не вешал пока. И не планирую особо.

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

На 25 порт, SSL, не вешал пока. И не планирую особо.

Тады ОК. Но, в принципе, ничто же не мешает повесить так же - let's encrypt-овский сертификат на домен и те же серты использовать для StarTLS на 25-ом. Тогда и внешним клиентам не придётся вручную добавлять сертификат. Хуже точно не будет. При ошибке - фоллбэк на обычное соединение и дальше крутить педали как всегда.

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

Другое дело, что пока let's encrypt, ещё не все приложения могут доверять.

Специально для совместимости с легаси intermediary certificate у Let's Encrypt, кстати, подписан другим древним CA (IdenTrust), который уж точно должен быть более-менее везде.

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