Элемент управления ActiveX может сделать свое дело. Но я действительно не вмешивался, чтобы помочь с решением, больше чтобы не согласиться с позицией, что то, что вы делаете, представляет собой угрозу безопасности.
Для ясности, вам нужен защищенный шифр (надеюсь, AES, а не DES), и вы уже управляете своими конечными точками, просто не в состоянии полностью исключить перехватчики сетевых данных случайного режима, которые могут перехватывать пароли в виде открытого текста или другие конфиденциальные данные.
SSL - это «Уровень защищенных сокетов», и по определению он НЕ зависит от ЛЮБЫХ сертификатов.
Однако все эффективные современные шифры требуют, чтобы он аутентифицировал конечные точки туннеля, что не всегда является необходимостью для каждого приложения; разочарование, с которым я сталкивался в многочисленных внутренних процедурах автоматизации центров обработки данных, использующих API веб-служб для управления узлами, где «пользователи» были фактически процессами, которым требовался обмен зашифрованным ключом до согласования команд RESTful.
В моем случае VLAN были защищены через ACL, поэтому я действительно "мог" отправлять заголовки с открытым текстом для аутентификации. Но только печатание заставило меня немного рвать в рот.
Я уверен, что я буду обижен за то, что напечатал это, но я чрезвычайно закален в боях и сделал бы те же самые комментарии к вам через 10-15 лет моей ИТ-карьеры. Поэтому я сочувствую их заботам и очень ценю, если они достаточно увлечены безопасностью, чтобы зажечь меня. Со временем они это поймут .....
Но я согласен с тем, что ПЛОХАЯ идея «обучать» пользователей устанавливать корневые ЦС самостоятельно. С другой стороны, если вы используете самозаверяющий сертификат, вы должны обучить его его установке. И если пользователь не знает, как определить, является ли сертификат CA заслуживающим доверия, он определенно не сможет определить самоподписанный сертификат из сертификата CA, и поэтому любой из этих процессов будет иметь тот же эффект.
Если бы это был я, я бы автоматизировал этот процесс вместо того, чтобы помогать конечным пользователям, чтобы он стал настолько скрытым от них, насколько это возможно, точно так же, как правильная PKI сделала бы для предприятия.
Говоря об этом, я просто подумал о возможном решении. Используйте модель Microsoft PKI. С помощью Server 2012 R2 вы можете доставлять доверенные ключи конечным точкам, которые даже не являются членами домена, используя «управление устройством» через «рабочие пространства», и клиентские машины могут подписываться на несколько рабочих областей, поэтому они не передаются исключительно вашим, если они подписываются. Как только они это сделают и аутентифицируются, роль службы сертификации AD будет выдвигать все необходимые сертификаты корневого CA, которые присутствуют в активном каталоге или на указанном сервере LDAP. (Если вы используете автономные серверы CA)
Кроме того, я понимаю, что этой теме уже 7 лет, но я уверен, что на нее все еще ссылается большое количество людей, нуждающихся в аналогичных решениях, и они чувствуют себя обязанными разделить противоположное мнение. (Хорошо, Microsoft, где мой отклик на плагин, который я тебе дал?)
-cashman