Николай Корабельников

копать client certificate authentication.
В вашем случае https://wordpress.org/plugins/client-certificate-a...

Рекомендую отказываться от FTP. Это совсем небезопасно. Уж на крайний случай SFTP.
А если хотите, чтобы было удобно и не создавалась файловая помойка, то смотрите в сторону продуктов управляемого файлообмена. Мне нравится opentrust MFT.

посмотрите OpenTrust MFT.
Программа для управляемого файлообмена позволяет обмениваться файлами большого размера. Передача защищена https, а также есть возможность шифрования передаваемых файлов. При необходимости можно выдать незарегистрированному пользователю т.н. жетон - ссылку для загрузки файлов на ваш MFT сервер.

Если вы создаете новую VPN сеть, то придумайте и укажите этот ключ. Если же пытаетесь подключиться к существующей, то администратор сети должен вам сообщить этот ключ. Судя по всему общий ключ это PSK (pre shared key). Такой перевод.

Вы можете настроить аутентификацию по сертификатам на Apache.
Сертификаты можно хранить и на флэшках.
Мануалы ищите по словам "apache client cetrificate authentication".
Таким образом без сертификата никто зайти на ваш 1С не сможет.

Не совсем так. На самом деле у вас есть пара ключей. И закрытым ключом технически возможно подписать что угодно, хоть другой сертификат. Но назначение вашего ключа не подпись других ключей, а аутентификация SSL/TLS. Это указано в самом сертификате, который вы получили от УЦ.
Если бы УЦ выдал вам сертификат с назначением "подпись сертификатов" (и, желательно, "подпись CRL"), то вы бы могли подписывать другие сертификаты. Но это невозможно по понятным причинам.
Еще одно ограничение, которое не позволит вам выпускать сертификаты - длина пути валидации, которая тоже скорее всего указана в вашем сертификате (или сертификате УЦ). Выданный вами сертификат является сертификатом конечного пользователя.
УЦ выдают только такие сертификаты клиентам. В этом суть web trust.

Верно, ваш wildcard сертификат для доменов третьего уровня.
Читайте RFC6125
https://tools.ietf.org/html/rfc6125#section-6.4.3

Посмотрите OpenTrust PKI. Кстати, поддерживает работу с сертификатами ГОСТ (в т.ч. 2012).

По сути написанного вами вижу небольшое непонимание. Подписывает сертификаты не администратор, а Удостоверяющий Центр. Работа с сертификатами (создание, приостановка, отзыв и вообще управление жизненным циклом сертификатов) - это как раз то, что позволяет делать любой PKI.

Не сталкивался с таким решением SSO.
Если все приложения поддерживают аутентифкацию по сертификату, то самый удобный способ - использовать токен или смарт-карту.
SSO, с которыми мне удалось поработать собирают пароли от разных приложений и хранят их в Active Directory. Таким образом, пользователь может воспользоваться функционалом SSO с любого ПК в сети, войдя в свою учетную запись.

В ИБ вообще нет лучших и худших вариантов. Есть разные критерии оценки и разный контекст.
Удобнее всего наверное использовать логин(СНИЛС кажется) и пароль. Но с точки зрения безопасности это не очень хорошо.
Наибольшую защиту от возможных атак на ваш аккаунт даст использование смарт-карты для аутентификации. Кажется, она называется УЭК.
Что лучше для вас - решайте сами.

Сгенерировать новый запрос на сервере и перевыпустить сертификат

Если генерировать новый запрос на сертификат, то пропадает смысл wildcard сертификата.

Лучше разобраться в причине, почему нельзя импортировать имеющийся wildcard сертификат на ваш сервер.

4) Есть ли возможность подписать сгенерированный сервером CSR закрытым ключом Wildcard-сертификата?

Вряд ли , ведь назначение сертифката скорее всего аутентификация SSL, а не подпись сертифкатов. Следовательно подписывать вашим ключом другие сертификаты нельзя. (ну технически можно, что вы и сделали, но цепочка доверия не построится).