Jump to content
Калькуляторы

Применимость самоподписанных сертификатов

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

Есть у меня сервер исключительно для технологических нужд — платежный шлюз для работы с различными платежными системами. Общедоступность в нем не предусматривается, для каждой системы есть своя точка входа (веб-скрипт) со своими ACL.

Работает по HTTPS с использованием самоподписанного сертификата (если точнее, то сертификата, выпущенного собственным приватным CA).

С этим сертификатом даже у таких записных бюрократов, как в Яндексе или Сбербанке вопросов не возникало.

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

И оказалось, что новый сервис проверяет цепочку доверия сертификатов и самоподписанные сертификаты естественно отклоняет.

Убедить их не удалось, аргументы что это закрытый сервис, HTTPS нужен только для шифрования, а аутентичность подтверждается заключенным договором, приняты не были. Предложили купить нормальный публичный сертификат, что не устроило уже меня — во-первых он стоит денег, во-вторых к текущему сертификату уже привязаны несколько сервисов (в том числе Сбербанк, в котором каждый чих согласовывается неделями).

Вот и хотелось бы знать, что об этом думают другие.

Сейчас от callback пришлось отказаться, вместо этого используется периодический опрос.

Share this post


Link to post
Share on other sites
18 минут назад, alibek сказал:

Вот и хотелось бы знать, что об этом думают другие.

Мое мнение - если есть какое-то непубличное (т.е. только по предварительной договоренности) взаимодействие, и инициатор соединения хочет удостоверится, что цепляется к тому, кому надо - то этот самый инициатор поднимает свой приватный СА, добавляет его в свой список доверенных и подписывает им сертификаты контрагентов. Другая сторона делает наоборот. И обе при установке соединения требуют авторизации по клиентскому сертификату.

 

 

 

Share this post


Link to post
Share on other sites
17 minutes ago, alibek said:

во-первых он стоит денег

есть бесплатный https://letsencrypt.org/ посадите его на любой новый поддомен и настройте на него каллбэк

Share this post


Link to post
Share on other sites
9 минут назад, kpv сказал:

есть бесплатный https://letsencrypt.org/

Я про него знаю, но по-моему это намного хуже.

Во-первых, это как сервисная почта на mail.ru.

Во-вторых, у этих сертификатов есть ряд ограничений, которые меня не устраивают.

 

16 минут назад, Sergey Gilfanov сказал:

добавляет его в свой список доверенных и подписывает им сертификаты контрагентов.

Вот с этим у нового сервиса проблема.

По какой-то причине он не может это сделать.

Share this post


Link to post
Share on other sites

@alibek вот проблему раздули. делаете новый домен/поддомен, покупаете за 15-30$/2 года нормальный сертификат и просите сбер поменять колбэк

 

проблема в 15-30$ за 2 года?

Share this post


Link to post
Share on other sites
1 минуту назад, alibek сказал:

Вот с этим у нового сервиса проблема.

По какой-то причине он не может это сделать.

По описанию - не так. По описанию он не хочет доверять вашему внутреннему CA. В данном случае нужно, чтобы сертификат точки входа callback вызовов был подписан их CA.

Share this post


Link to post
Share on other sites
5 минут назад, s.lobanov сказал:

покупаете за 15-30$/2 года нормальный сертификат

А что значит «нормальный»?

Сертификат, заверенный публичным CA, работает как-то по другому?

Все шифруется совершенно одинаково. Разница только в том, что в одном случае сертификат заверен некоей известной организацией, которая дорожит своим именем и им же гарантируем, что перед выдачей сертификата аутентичность была проверена, а во втором случае сертификат заверен теоретически неизвестным CA.

 

2 минуты назад, Sergey Gilfanov сказал:

В данном случае нужно, чтобы сертификат точки входа callback вызовов был подписан их CA.

У них нет своего CA, они проверяют по публичным корневым CA.

Но да, теперь я понял смысл предложения.

Share this post


Link to post
Share on other sites

@alibek проблема в том, что Сбербанк не хочет добавлять ваш сертификат в своё хранилище сертификатов (которое с вероятностью 99.9% это просто то что идёт с java), потому что потом им это надо всё переносить/менять процедуру деплоя, бэкапа, восстановления

 

Не очень понятно что вы хотите обсудить с комьюнити. как продавить Сберанк? (ну ответ, очевидно, никак)

 

И ещё. Подписанный публичными центрами можно нормально отменить (revoke) и, возможно, сбрф использует ocsp. в случае самоподписанного так сделать (через ocsp) не получится

Share this post


Link to post
Share on other sites

Причем тут Сбербанк? Как раз Сбербанк спокойно работает с самоподписанными сертификатами.

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

Вопрос — зачем в подобных случаях вообще публичная цепочка доверия?

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

Но требовать публичный сертификат для закрытого сервиса глупо. Здесь стороны удостоверяют друг друга при заключении договора, а HTTPS используется для шифрования и целостности данных.

Ну или не глупо, а я просто что-то не учитываю.

Share this post


Link to post
Share on other sites

@alibek да, я не дочитал до конца первый пост(слишком много букв)

 

я вам привёл аргументы почему это плохо (нет возможности нормально отозвать + трудозатраты с той стороны на поддержание хранилища самоподписанных сертификатов + им ещё надо будет проверять что вы там в атрибуты захерачали, мало ли кто этим воспользуется... + публичные центры проверяют что вы это вы (хотя бы по IP) - как это делать в случае передачи самоподписанного? )

Share this post


Link to post
Share on other sites
14 минут назад, alibek сказал:

Но требовать публичный сертификат для закрытого сервиса глупо. Здесь стороны удостоверяют друг друга при заключении договора, а HTTPS используется для шифрования и целостности данных. 

Без проверки сертификата шифрование и безопасность так себе, любой MITM сработает.

 

Сбер, кстати, вполне работал по простому http.

Edited by ixi

Share this post


Link to post
Share on other sites
8 minutes ago, alibek said:

Ну или не глупо, а я просто что-то не учитываю.

не учитываете стоимость решения. сами не хотите ни бесплатный поставить ни за смешные $15 взять готовое решение.

на на 99% уверен, что вы же первый откажитесь от оплаты ведения и поддержку приватных сертификатов сбербанком, когда ежегодно попросят уже не $15, а несколько больше.

 

Share this post


Link to post
Share on other sites
22 минуты назад, alibek сказал:

У них нет своего CA, они проверяют по публичным корневым CA.

 

9 минут назад, s.lobanov сказал:

я вам привёл аргументы почему это плохо (нет возможности нормально отозвать + трудозатраты с той стороны на поддержание хранилища самоподписанных сертификатов + им ещё надо будет проверять что вы там в атрибуты захерачали, мало ли кто этим воспользуется... + публичные центры проверяют что вы это вы (хотя бы по IP) - как это делать в случае передачи самоподписанного? )

С вероятностью 90% у сервиса где-то внутри есть виндовый домен. А в нем, соответственно, готовый CA, который умеет собственные сертификаты отслеживать, отзывать итд. Так что мой вариант вполне осуществим и не так уж сложен в исполнении.

Разве что созвониться или еще как связаться придется, чтобы проверить, что Certificate Request пришел именно от того, от кого должен.

Share this post


Link to post
Share on other sites
6 минут назад, ixi сказал:

Без проверки сертификата шифрование и безопасность так себе, любой MITM сработает.

Вот это интересно. Каким образом?

Можно сделать сертификат с таким же CN и прочими атрибутами, но его нельзя будет подписать моим ключом.

А отпечаток, CN и IP-адрес другой стороне можно передать хоть по email, хоть зафиксировать в договоре.

 

Share this post


Link to post
Share on other sites
Just now, alibek said:

А отпечаток, CN и IP-адрес другой стороне можно передать хоть по email, хоть зафиксировать в договоре.

всё можно. а потом при каждом чихе или изменении будете тащить бумагу с "живой синей печатью" за подписью директора и бухгалтера и выпиской из егрюл. 

 

3 minutes ago, alibek said:

можно передать хоть по email

а вот и прекрасный вариант MITM

Share this post


Link to post
Share on other sites
15 минут назад, alibek сказал:

Вот это интересно. Каким образом?

Можно сделать сертификат с таким же CN и прочими атрибутами, но его нельзя будет подписать моим ключом.

А отпечаток, CN и IP-адрес другой стороне можно передать хоть по email, хоть зафиксировать в договоре.

 

я так понял "без проверки" это дословно "без проверки", Т.е. сказать клиенту чтобы он не проверял цепочку доверия итд и работал с чем дали. в таком виде дать могут все что угодно.  (типа как curl -k) защита от пассивного снифа трафика, от МИТМ не поможет совершенно.

 

вообще вопрос не технический. Технически поставить дополнительный ЦА куда угодно можно. Вопрос политический. Если вы работаете со 100500 клиентами и каждый норовит использовать свой ЦА, то этих ЦА будет тоже 100500 их учитывать и еще и проверять чтобы для компании А не подсунули сертификат от компании Б. Тут надо или всем подписыаать сертификаты своим ЦА и только ему и доверять  (но тут обратная ситуация, если на ваш шлюз будет ломиться 100 компаний вам придется держать 100 разных шлюзов с разными сертификатами) или таки использовать публичные ЦА. Было бы проще если бы 1 сертификат можно было бы подписать кучей ЦА, но... В общем вопрос реализации и удобства обслуживания.

 

 

Ну и "самоподписанный" это наверное не то, что имелось в виду, самоподписанный, когда он сам себе ЦА и сам себя подписал, тут вообще не бывает цепочки доверия., а тут всетаки по тексту есть ЦА, пускай и не публичный...

 

зы в приватном ЦА никто не мешает использовать ocsp. оно работает.

Share this post


Link to post
Share on other sites
3 минуты назад, st_re сказал:

зы в приватном ЦА никто не мешает использовать ocsp. оно работает.

да. если поднято. автор топика, вероятно, не собирался этого делать (кстати, по затратам на поднятие и обслуживание (трудочасам) это дороже выйдет 15-20$)

Share this post


Link to post
Share on other sites
1 минуту назад, s.lobanov сказал:

да. если поднято. автор топика, вероятно, не собирался этого делать (кстати, по затратам на поднятие и обслуживание (трудочасам) это дороже выйдет 15-20$)

ну со своим ЦА да еще для внешнего потребления заморачиваться смысл есть только для больших объемов.. для 1-2 случаев купить за 30 сребренников в год и не париться...

Share this post


Link to post
Share on other sites
Только что, s.lobanov сказал:

автор топика, вероятно, не собирался этого делать

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

Просто в данной задаче (технологическое взаимодействие двух систем) я вообще не вижу необходимости в публичном CA. HTTPS нужен, чтобы данные не ходили в открытом виде.

 

7 минут назад, st_re сказал:

я так понял "без проверки" это дословно "без проверки"

Ну либо так (хотя это и слишком радикально, зато просто), либо добавить мой приватный CA в список доверенных.

 

10 минут назад, st_re сказал:

В общем вопрос реализации и удобства обслуживания.

Да, тут вполне нормально аргументировано и такая позиция мне понятна.

 

Share this post


Link to post
Share on other sites
6 минут назад, alibek сказал:

HTTPS нужен, чтобы данные не ходили в открытом виде.

HTTPS нужен для того, чтобы убеждаться, что стороны - те, за кого себя выдают.

Кстати, в описанном случае - как проверять, что в callback постучался именно сервис а не непонятно кто?

По хорошему бы ваша сторона должна попросить у стучавшегося клиентский сертификат и проверить его. Вот его - можно/нужно подписывать как раз вашим CA.

Share this post


Link to post
Share on other sites
7 минут назад, Sergey Gilfanov сказал:

Кстати, в описанном случае - как проверять, что в callback постучался именно сервис а не непонятно кто?

Ну в моем случае непонятно кто постучать не сможет — callback принимается только с IP-адресов из согласованного списка.

Еще в запросе используется токен доступа, который непонятно кто (теоретически) знать не может.

 

7 минут назад, Sergey Gilfanov сказал:

ваша сторона должна попросить у стучавшегося клиентский сертификат и проверить его. Вот его - можно/нужно подписывать как раз вашим CA.

Логика понятная, но мне кажется, что избыточная.

Например в Киви все сделано гораздо проще — к анкете прикладывается сертификат своего шлюза и Киви проверяет именно его, без всяких цепочек доверия и CA.

Правда такой сертификат нельзя отозвать (через CA), но такое и не предусматривалось — изменение/отключение сервиса делается бумажно.

Share this post


Link to post
Share on other sites
2 минуты назад, alibek сказал:

Ну в моем случае непонятно кто постучать не сможет — callback принимается только с IP-адресов из согласованного списка.

Еще в запросе используется токен доступа, который непонятно кто (теоретически) знать не может.

Ага. А чем клиентский https сертификат в качестве 'токена доступа' плох. Для того и придуман, как бы.

Share this post


Link to post
Share on other sites
22 минуты назад, Sergey Gilfanov сказал:

Кстати, в описанном случае - как проверять, что в callback постучался именно сервис а не непонятно кто?

да легко. просто делаете URL вида https://url-for-callback/xxx/KEYWORD/receive.lang

 

если KEYWORD не совпал, то значит платёж по такому запросу не принимаем. да сотрудники той организации будут знать KEYWORD, но с другой стороны они и так смогу сэмулировать левый запрос

Share this post


Link to post
Share on other sites
22 минуты назад, Sergey Gilfanov сказал:

А чем клиентский https сертификат в качестве 'токена доступа' плох.

Не то чтобы плох, но гораздо менее гибок, чем токен в заголовках/аргументах.

Share this post


Link to post
Share on other sites
20 минут назад, s.lobanov сказал:

если KEYWORD не совпал, то значит платёж по такому запросу не принимаем. да сотрудники той организации будут знать KEYWORD, но с другой стороны они и так смогу сэмулировать левый запрос

Весь https с открытыми ключами и прочими сложными алгоритмами потому и придуман, что использование просто пароля, что тут KEYWORD называется, не очень хорошо работает.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now