Внешняя проверка веб-сайтов: есть ли сервис с поддержкой ssl client certificate?

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

запили сам, это не так сложно

Вообще-то клиентский сертификат - это подписанный CA открытый ключ. Может быть, сначала всё-таки стоит подумать, а потом отвечать?

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

Да, но миниум 5 разных независимых белых IP-адресов - это разве несложно?

Я понимаю, что российский менталитет - это «запили на коленке как-нибудь, зачем деньги пл`отить», но ни для одной крупной организации грубый кустарный «авось-на-глазок» почему-то не подходит.

Как минимум хотелось бы платить за определённый сервис с определённым SLA, а не за машинки на Амазоне. Причём для нас критично, чтобы проверки осуществлялись с российских IP, а не из произвольных стран мира, откуда и клиенты-то к нам не ходят. А то будет печально, если половина российских клиентов отвалится, но из Гондураса сайт будет открываться просто превосходно.

Да, а 5 разных независимых белых IP-адресов - тоже несложно?

купить 5 VPS в соответствующих местах

маловероятно, что такой сервис существует, особенно с российскими IP адресами, клиентская аутентификация по сертификатам не очень популярна

Эмм... Вот вы когда на https://google.com ходите, Вы там тоже приватный ключ предоставляете?

Насколько я знаю, всё, что в данном случае требуется от сервера - это проверить, подписан ли клиентский сертификат известным ему Certification Authority. Точно так же ваш браузер проверяет «валидность» сертификата Google.com - для этого ему совершенно не нужен приватный ключ Google.com'а!

Эмм... Вот вы когда на https://google.com ходите, Вы там тоже приватный ключ предоставляете?

нет, потому что гугл меня не аутентифицирует

Точно так же ваш браузер проверяет «валидность» сертификата Google.com - для этого ему совершенно не нужен приватный ключ Google.com'а!

но приватный ключ нужен серверу гугла, чтобы мой браузер мог его аутентифицировать

но приватный ключ нужен серверу гугла, чтобы мой браузер мог его аутентифицировать

А можно поподробнее? ;)

https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake

Вообще-то клиентский сертификат - это подписанный CA открытый ключ.

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

всё, что в данном случае требуется от сервера - это проверить, подписан ли клиентский сертификат известным ему Certification Authority

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

Ты в курсе что клиентский сертификат у каждого клиента свой, и приватный ключ свой? Это как пара логин/пароль. ТС просто выдает бесправную тестовую учетку провайдеру, и он себе шлет запросы.

Вообще в интернетах мало кто дружит с этими штуками. Наверное слишком сложно.

Ты в курсе что клиентский сертификат у каждого клиента свой, и приватный ключ свой? Это как пара логин/пароль. ТС просто выдает бесправную тестовую учетку провайдеру, и он себе шлет запросы.

это ТС-у надо быть в курсе, я при чём

ТС просто выдает бесправную тестовую учетку провайдеру, и он себе шлет запросы.

Только очень часто настраивают так, что сервер клиентов по сертификату не различает никак.

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

Ога ога. Только клиент обычно сам генерит приватный ключ и никто кроме клиента его не знает. На пересдачу.

Только очень часто настраивают так, что сервер клиентов по сертификату не различает никак.

Очень часто некоторые неучи так делают. Например те которые сейчас идут на пересдачу.

Ога ога. Только клиент обычно сам генерит приватный ключ и никто кроме клиента его не знает. На пересдачу.

ЧСВ свое подкрути, а то в экран не влезает. ТС пришлось бы этому сервису и сертификат подписать. Т.е. владельцы сервиса получили бы доступ к их сайту, если там не различают клиента по сертификату.

Очень часто некоторые неучи так делают.

Ну так никто и не спорит. Только проблема в том, что среди неучей попадаются авторы популярного софта. Найди, мне, например, ручку в uwsgi, позволяющую различать клиентов по SSL сертификату.

ТС пришлось бы этому сервису и сертификат подписать.

Значит приватный ключ уже светить не надо? Прогресс.

Найди, мне, например, ручку в uwsgi, позволяющую различать клиентов по SSL сертификату.

Не там ищешь. Это лежит на плечах того кто непосредственно занят работой с сертификатами. Например для nginx http://nginx.org/en/docs/http/ngx_http_ssl_module.html (ctrl+f $ssl_client_)

вот только этого в uwsgi не хватало еще

Ты сам-то читал, что по твоей ссылке написано?

The server requests a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest message.

The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.

The client responds with a Certificate message, which contains the client's certificate.

The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.

The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.

Где здесь про наличие твоего закрытого ключа у гугла?

почему моего закрытого ключа, очевидно, что имелся в виду закрытый ключ от серверного сертификата гугла, выданный для домена google.com или какого ещё, а ты что подумал?

Сорри. Я наконец-то прочитал ОП :)

Значит приватный ключ уже светить не надо? Прогресс

ТС-у пришлось бы отдать и приватный ключ, и сертификат. Ну только если бы этот гипотетический сервис сам генерил ключи, отдавал пользователю CSR, пользователь его подписывал и отдавал назад.

Не там ищешь. Это лежит на плечах того кто непосредственно занят работой с сертификатами.

Ты не поверишь, но некоторые пользуются uwsgi без nginx. И даже пользователи nginx часто о таких вещах не задумываются.

Чего это не поверю? Я и не такое видел. Например один персонаж на лоре говорит что клиентские сертификаты не нужны потому что некоторые юзают uwsgi без nginx. Иногда у людей оч слабо работает логическое мышление.

Например один персонаж на лоре говорит что клиентские сертификаты не нужны потому что некоторые юзают uwsgi без nginx.

А давай ты ссылку дашь на это заявление о том, что клиентские сертификаты не нужны. А то есть мнение, что кто-то не тем местом читает.

Просто признай что не знал как это все работает.

Т.е. ссылки не дашь. До свиданья.

Трудно признавать свою безграмотность да? Ну ты постарайся. Через нихочу к выздоровлению.

просто рассуждаем логически, безо всяких знаний о реальном устройстве дел. В асимметричной криптографии любой может зашифровать данные твоим открытым ключом, но расшифровать это послание можешь только ты своим приватным, значит, для того, чтобы отправить сообщение, серверу достаточно только твоего открытого ключа. Дальше, аутентификация - как сервер проверит, что этот открытый ключ действительно твой? Очень просто, этот открытый ключ должен быть подписан приватным ключом, который известен серверу, или центром сертификации, которому доверяет сервер. И снова серверу не нужен твой приватный ключ.

На техническом ресурсе надо такие простые вещи разжевывать, до чего довели планету это веб-хипсторы!

просто рассуждаем логически

Ага, давай. Это я люблю.

Дальше, аутентификация - как сервер проверит, что этот открытый ключ действительно твой? Очень просто, этот открытый ключ должен быть подписан приватным ключом, который известен серверу, или центром сертификации, которому доверяет сервер.

Это только первая часть проверки. Сервер еще должен удостовериться, что клиент знает приватный ключ - поэтому клиент отсылает специальное сообщение, подписанное приватным ключом

https://tools.ietf.org/html/rfc5246#section-7.4.8

И снова серверу не нужен твой приватный ключ.

Клиенту нужен. Если ты прочитаешь исходный пост, то увидишь, что сервис, который нужен ТС, должен действовать как SSL клиент.

На техническом ресурсе надо такие простые вещи разжевывать

И не говори.

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

а дальше я беру и перехватываю сниффером этот самый «открытый ключ подписанный приватным ключом центра сертификации» и тоже аутентифицируюсь с ним, не имея приватного ключа

А давай я тебе разжую почему ты тупой, а?

Вот смотри:

• Перехватил ты этот открытый ключ
  
• Отправил его в аутентификационном запросе серверу
  
• Сервер авторизовал твой запрос и отправил тебе ответ
  
• ...
  
• Обосрись, ответ зашифрован тем самым открытым ключём и без закрытого хер ты его расшифруешь
  
  Ну и что дала тебе эта аутентификация?

Если клиент не знает приватного ключа — он не сможет расшифровать то, что зашифровано публичным.

Но нам то ни к чему знать приватный ключ этого проверяющего сервиса или делиться с ним нашим, у него свой собственный. Зачем «светить свой приватный ключ»?

может мне ответ сервера и не нужен, достаточно, чтоб он запрос обработал

да, вовка-коровка про подпись приватным ключем сказал, я этот этап пропустил, прошу прощения. тем не менее, зачем мне давать сервису проверки свой приватный ключ?

Чтобы он запрос обработал тебе придётся подтвердить получение авторизационного ответа, а ты его прочитать не сможешь.

В этом топике уже достаточно людей обосралось на технической безгамотности. Достаточно. Асинхронное шифрование не дураки и не на коленке придумывали.

Чтобы вовка смог тебя похакоть же!

Чтобы он запрос обработал тебе придётся подтвердить получение авторизационного ответа, а ты его прочитать не сможешь.

зачем ты сочиняешь на ходу свой велосипедный криптопротокол? теперь внезапно авторизационные ответы откуда-то появились. Сначала всю спецификацию выложи, потом можно дальше дискуссию продолжать

Нет, такой тупняк только в игнор

Если клиент не знает приватного ключа — он не сможет расшифровать то, что зашифровано публичным.

Я чего-то не понял, что тебе не понравилось. Я с этим твоим утверждением и не спорил.

тем не менее, зачем мне давать сервису проверки свой приватный ключ?

Сервис должен проверить доступность сайта по HTTPS. Для этого нужно, чтобы прошел полный хендшейк. А для этого нужна пара из закрытого и открытого ключа, а также сертификат с этим открытым ключом, подписанный рутовым сертификатом, которому доверяет сервер. Эту пару ключей может, конечно, сгенерировать и сам сервис, но пользователю сервиса все равно нужно будет подписать сертификат для открытого ключа. Гораздо проще бы выглядело, если бы пользователь сразу выдавал сервису приватный ключ и сертификат.

сообщение, подписанное приватным ключом

сообщение, подписанное приватным ключом

И что не так? В ходе хендшейка, клиент отсылает специальное сообщение Certificate Verify, которое содержит все предыдущие сообщения из хендшейка, зашифрованные приватным ключом клиента. Сервер расшифровывает это сообщение публичным ключом клиента и сверяет, что сообщение переданное клиентом совпадает со всеми сообщениями из хендшейка, которые видел сервер.

что не так?

Всё не так

Всё не так

А слова ты свои чем подтвердишь? Я выше ссылку на RFC дал.

Единственное, что клиент не шифрует сообщение, а просто подписывает.

Ты сам-то читал что там по ссылке?

Ну давай не тяни, расскажи, что я не так прочитал.

Всё