Расспределение ключей OpenVPN

Секретный ключ не надо пересылать вообще.

Клиент должен сгенерить секретный ключ и CSR у себя и отправить CSR админу, который его подпишет и отправит обратно user.crt и ca.crt.

На клиенте:
openssl req -days 3650 -nodes -new -keyout client0.key -out client0.csr
Подписываете ключ на сервере:
openssl ca -days 3650 -out client0.crt -in client0.csr

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

Кстати, если корневой сертификат самоподписаный, то возможен man-in the-middle, а если подписан третьей стороной (нпример VeriSign) то атака посредника провалится?

>Кстати, если корневой сертификат самоподписаный, то возможен man-in the-middle, а если подписан третьей стороной (нпример VeriSign) то атака посредника провалится?

нет

Локонично однако :) Почему же нет, ведь атакующий может подминить открытые ключи при обмене, а подлинность их и не проверишь т.к. нет публичного ключа удостоверяющего центра, который кстати говоря должен был подписать открытые ключи клиента и сервера собственным секретным ключом. Так что мне кажется что вы неправы...

"Локонично" - это от локона или локомотива?

По сути: М-и-М атака и СА, подписавший сертификат - ортогональны. Важно то, чьей подписи доверяет клиент. Будет доверять только "большим" СА из начального списка - тогда любой самоподписанный серт пойдет лесом. Для того, чтоб клиент молча доверял еще каким-то СА - нужны доп. технические меры, заметные (или не заметные, в виндах это возможно!) пользователю. А иначе будут громкая ругань.

Вы вообще поняли очём речь?

1. Атакующий "помещает себя" между сервером и клиентом (ARP перенаправление например)

2. Подменяет открытые ключи сервера и клиента при передаче их от одного к другому.

3. Подменяет ca.crt при передаче от сервера к клиенту (если сa.crt самоподписанный)

4. Трафик от клиента идёт на ложный сервер атакующего, при этом (уж как реализует атакующий) трафик маршрутизируется на легитимный сервер (маршрутизируется хостом атакующего). При этом лигитимный сервер думает что трафик идёт от легитимного клиента, т.к. атакующей подминил публичные ключи и ca.crt (внимание!) при первом установлении связи (возможно вас это смутило).

А третья сторона препятствует этой атаке тем, что ca.crt (публичный ключ УЦ) уже находится в хранилище (при инсталяции ОС) и если атакующий подменит публичные ключи, тогда сервер и клиент всегда могут проверит ЭЦП на публичных ключах, заведомо правильным публичным ключом УЦ, тоесть ca.crt.

За это всяким центрам сертификации деньги и платят. Всё выше сказанное мо ИМХО т.к. чётко понимания пока к сожаленю нет...

>Кстати, если корневой сертификат самоподписаный, то возможен man-in the-middle, а если подписан третьей стороной (нпример VeriSign) то атака посредника провалится?

Да.
Забей.

Спасибо! Хоть один дельный ответ :) Каждый пост - проблематика для исследования, каждый комент - куча информации. Люблю ЛОР! :)

можно диктовать ca.crt и сертификат по телефону. Это совсем не сложно. И нужно всего-то один раз. Ну или доставить на дискете в бронированном автомобиле с эскортом.