Выдать сертификат звонящему маршрутизатору под Win 2003
 

Ситация следующая. Есть две сети. В каждой установлен софтовый маршрутизатор на Win2003. В одной сети (А) маршрутизатор является членом домена, во второй сети (Б) -- выделенный хост-бастион. В сети А есть развёрнут Центр сертификации.
Необходимо реализовать VPN-соединение двух подсетей А и Б с использованием L2TP/IPSec с выдачей сертификатов конечным точкам VPN-туннеля (т.е. маршрутизаторам в сетях А и Б). В сети А это просто решается через автоматическую выдачу. Но вот как запихнуть сертификат в маршрутизатор сети Б, который не является членом домена сети А?

Сертификат нужного сервера экспортировать, на маршрутизаторе импортировать в доверенные.

Нужного это какого? Корневого СА? Он экспортирован в .cer-формате на хост-бастион, являющийся VPN-сервером. Но нужен ещё набор сертификатов, которые бы подтвердили надёжность самого хоста. Т.е. нужно выдать сертификат на корневом СА, но из какого шаблона и с какими параметрами. Пробовал уже модифицированные сертификаты RAS и IAS-сервера. Не покатило. Пробовал Offline Router. Тоже не сработало. Экспортирую в .pfx (p12-формат, с архивированным ключом). Но даже это не помогает. В общем, нужет тип сертификата или набор необходимых параметров.
Вопрос то не шибко сложный, но не на технете, не в сапорте мелкомягком ничего вразумительно ответить не смогли.

хм... на обоих шлюзах устанавливаем СА сертификаты и для каждого шлюза свой локальный сертификат. Всё, больше никаких сертификатов не нужно. Тип только забыл, но по-умолчанию он уже стоял... Правда я настраивал ПН не на винде, но я так понимаю для шлюзов всё равно... Вот сайт , где можно инфу найти. Там у них дока где-то есть, по которой я сертификаты генерил для шлюзов.
Кстати, можете у них скачать КриптоПро триальную версию (на месяц), нагенерить себе сетрификатов, и забыть о них.
Единственный момент - Домен на шлюзе А. Совершенно не знаю как себя ВПН поведёт.

exo, в организации в домене А и раз развёрнута PKI. Есть издающие сертификаты Центры сертификации и они вполне справляются, но пока дело доходило только до компов в лесу. А тут звонящий маршрутизатор не является членом леса.

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

exo, это ПО -- RRAS ;) И сертификаты он берёт из локального хранилища, в которое запихнуть сертификат сложности никакой нет. Но несмотря на наличие сертификата в логах на принимающей стороне отмечено, что была попытка соединения, но соединение не завершено из-за того, что вверительные данные или сертификат не соответствуют. По PPTP с MS CHAP v2 всё устанавливается на ура.

ну вот Вам логи и указали на ошибку - ЦС когда устанавливался? Переустанавливался ли он перед генерецие сертификатов для Б-маршрутизатора? Разные ЦС выдают разные СА.

Нет, корневой Центр сертификации один и тот же. Хотя, вот вы меня на мысль натолкнули, что действительно один из выдающих сертицикаты Цс переустанавливался и возможно цепочки неодинаковые на VPN-маршрутизаторе, IAS и звонящем маршрутизаторе.

один из? ЦС должен быть один! или разные ЦС должны быть как-то связанны между собой.
если так - то всё. Ибо СА уникален - там когда устанавиливается ЦС - генерится ключ на основании движений "мышки" или написанных "знаков".

Нет, PKI позволяет реализовать многозвеньевые схемы. В данном случае есть один офлайновый корневой ЦС. Он выдаёт сертификаты уже непосредственно издающим ЦС, которые и обслуживают потребителей. Вот один из издающих ЦС слетел и его переустанавливали.

я стаким не работал, увы. У меня один ЦС, делал все сертификаты на нём.
Но как видите из логов - ошибка только в самих сертификатах.

Увы, все попытки тщетны. Не хочет пахать L2TP/IPSec.

Kirill_80, а если на обоих маршрутизаторах поменять сертификаты?

exo, попробую завтра, но вряд ли получиться, субъекты выдачи у сертификатов разные.

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

Ничего не дало.

Проблема решилась, виноват был ублюдочный WinGate, который какой-то местный умник впихнул в промежуточную сеть.