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

Ну так объяснить можешь? Аля «Ты написал так, а на самом деле все вот так...». А то больше на троллинг смахивает.

Так в rfc всё написано как надо, возьми да прочитай внитмательней.
И что чем шифруется и чем расшифровывается и куда и зачем отправляется — всё уже давно придумано и описано.

Написано. Может у меня с английским сильно туго, но в RFC написано

7.4.6. Client Certificate ...

Meaning of this message:

This message conveys the client's certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing) or calculating the premaster secret (for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm, and any negotiated extensions.

Итого: клиент отправляет свой сертификат, который будет использоваться сервером для проверки сообщения CertificateVerify (сертификат с диффи-хеллманом пропустим - почти не используется). Значит, CertificateVerify отправляется клиентом, а сервер его проверяет.

Переходим к описанию CertificateVerify

7.4.8. Certificate Verify

When this message will be sent:

This message is used to provide explicit verification of a client certificate. This message is only sent following a client certificate that has signing capability (i.e., all certificates except those containing fixed Diffie-Hellman parameters). When sent, it MUST immediately follow the client key exchange message.

Structure of this message:

struct { digitally-signed struct { opaque handshake_messages[handshake_messages_length]; } } CertificateVerify;

Here handshake_messages refers to all handshake messages sent or received, starting at client hello and up to, but not including, this message, including the type and length fields of the handshake messages. This is the concatenation of all the Handshake structures (as defined in Section 7.4) exchanged thus far. Note that this requires both sides to either buffer the messages or compute running hashes for all potential hash algorithms up to the time of the CertificateVerify computation. Servers can minimize this computation cost by offering a restricted set of digest algorithms in the CertificateRequest message.

The hash and signature algorithms used in the signature MUST be one of those present in the supported_signature_algorithms field of the CertificateRequest message. In addition, the hash and signature algorithms MUST be compatible with the key in the client's end-entity certificate. RSA keys MAY be used with any permitted hash algorithm, subject to restrictions in the certificate, if any.

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

Последний раз спрашиваю - что здесь не так?

Вот видишь — достаточно внимательно прочитать rfc и

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

Превращается в

клиент отсылает специальное сообщение CertificateVerify, чтобы доказать, что он знает приватный ключ

, что уже больше похоже на правду.

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

И у тебя этих мелочей ещё не так много в постах, как в постах тех, кому у меня комментарии матом установлены. А то ведь бывает переврут при переводе пару мелочей, а смысл вдруг взял и с ног на голову перевернулся.

По существу же вопрос был не о том, как происходит handshake, а о том, какой внешний провайдер готов распределённо тестировать сайты, реализуя при этом полноценный двусторонний handshake.

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

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

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

У меня пока решения нет. Будет инвестор — за месяц сделаю готовый продукт. Но нет инвестора. И лишнего свободного месяца тоже нет.