Приветы! 
У меня довольно сложный сценарий... Клиент с сервером прежде чем установить соеденение, должны обменятся N-ным количеством нестандартных сертификатов. То есть, как я понимаю, самым "лёгким" способом будет расширение SSL. Именно расширение, так как "обычный" SSL так же должен использоваться. 

Ну и конечно вопросы.. Как мне в HTTPSConnection "влезть" на уровень SSL? Это было бы оптимальным решением (самым простым).
И, что делать на стороне томкета? Можно ли плагином каким нибудь "влезть" в точку, где соеденение создаётся и отработать обмен сертификатами?

Любая информация и идеи приветствуются 

ПС: Обмен сертификатами на уровне HTTP делать не охота, так как будут необходимы несколько соеденений, что означает кучу сешенов, тпрмоза и прочие траблы.

Что из себя представляет клиент? Это тоже java приложение или нет?
Сервер это Tomcat или application server?

Клиент это Апплет, сервер Томкет.

sergejzr, что значит "нестандартный" сертификат. Не X.509 V3?



Да, вы не ишите легких путей .

Это может быть всё что угодно. После создания SSL-соединения авторизации как таковой не надо, ведь клиент и сервер знают друг о друге стандартными методами и соединение зашифровано.

Теперь как раз начинается сценарий. Проще всего объяснить случаем "на дороге".

Клиент с сервером пытаются "договориться". Например сервер спрашивает клиента "У вас есть водительское удостоверение?" в зависимости от ответа клиента сервер может запросить показать удостоверение, или "отпустить" клиента, или паспорт запросить для выписки штрафа. В свою очередь клиент может ответить вопросом "Ты - сотрудник ГИББД? Покажи удостоверение, тогда покажу тебе паспорт". Ну и тд. итп.

SSL же только даёт нам знать, что человек, с которым я разговариваю - действительно тот человек, с которым я думаю, что разговариваю.

Короче со стандартным SSL уже ничего общего, но и с HTTP ещё нет. Результатом переговоров, как я уже писал будет или ресурс, или его часть 



Ты представляешь, какими громоздкими будут переговоры? Для каждого вопроса нужно будет создавать новое соединение. И всё это через SSL...

А KeepAlive?



Я представляю, что реализовать это на уровне http, будет гораздо легче, чем "вскрывать" клиентские и серверные модули для работы с SSL и дописывать туда обмен этими сообщениями. Намного легче. И намного понятнее, с разделением мух и котлет. Это что касается N-ного кол-ва сертификатов.

Есть другой вариант (менее геморный, более IMHO правильный). Выдаем один сертификат на все виды дейтельности (я сотрудник ГИБДД, я водитель с правами). Далее обмениваемся этими сертификатами в процессе установления SSL. И потом, каждый на своей стороне уже знает (что сервер-является сотрудником ГИБДД, а у клиента-есть права). Дальнейшие длительные обмены информацией не нужны. Из минусов: даже если сервер и не является сотрудником ГИБДД, то он будет знать, что у вас есть права.

Это как раз исключается. Пока я удостоверение ГИББД не увижу, я ему свои права не покажу. В этом весь смысл. Т.е как раз тот минус, который ты нашёл в конце. На самом деле пока нет системы, которая эту дырку закрывает. Вот, теперь возможно будет 


Как это с явой работает? Не кинешь ссылкой? А то после того, как inputStream берёшь, уже ничего писать в HttpURLConnection нельзя. Возможно я ещё не в материи 



Здесь не лёгкость интересует, а сам принцип. Удобство и скорость желаемо.

Ну с HttpsURLConnection я не работал - не знаю, как там это достигается. А вот в библиотеке Apache HttpClient - keep-alive включен по умолчанию.