Желаемый порядок моих действий:
1. установка TCP соединения
2. получение идентификатора
3. выбор verify_file (сертификата) по идентификатору
4. SSL handshake
5. нормальная работа
6. закрытие подключения.

boost::asio::ssl::stream в качестве параметра принимает неконстантную ссылку на контекст. Из чего следует логичный вывод, что этот контекст можно потом менять. Поэтому, я на этапе 0 (который перед 1) создаю ssl::stream<ip::tcp::socket>(ios, ctx), а на п.3 выполняю ctx.set_verify_file() и ctx.set_verify_mode(verify_peer)... Но каково было мое удивление, когда я убрал set_verify_file() и все продолжило работать... Затем я поместил set_verify_mode() перед созданием сокета, и все перестало работать - handshake не проходит. Путем не очень долгих изысканий выяснилось, что некие очень умные люди (разработчики OpenSSL) сделали ход конем при создании SSL контекста - судя по всему, это "умный указатель" с семантикой COW (copy on write). Таким образом, использованная мной технология не работает.

Тогда я решил сначала создавать обычный tcp::socket, а затем, когда будет контекст готов, пихать его в ssl::stream... Но не тут-то было - у ssl::stream вообще нет для этого методов, а у tcp::socket есть возможность получить "нативный" дескриптор сокета (native()) и установить его (assign()), но я не нашел ничего похожего на метод "отцепления" дескриптора от сокета...

Собственно вопрос, что делать?

Это сообщение отредактировал(а) bsa - 25.11.2009, 14:52

Кажется нашел: