Частенько появляются вопросы про просмотр хранилищ сертификатов на удалённых компьютерах из PowerShell. Встроенный провайдер CERT:\ не умеет такого. Командлетов для этой задачи тоже нет (хотя PowerShell вообще не содержит ни одного даже самого примитивного командлета для работы с сертификатами). Как быть и что делать? Ведь MMC умеет ходить по хранилищам удалённых компьютеров. Ответ на самом деле простой до безобразия, но о нём почти ничего не написано.

Как известно для особой работы с хранилищем сертификата (в смысле не только посмотреть, что там есть, но и добавить туда ещё сертификатов) мы используем класс X509Store. Сначала мы создаём соответствующий объект хранилища требуемого контекста (тип хранилища и название контейнера) и методом Open() открываем его. Но в списке конструкторов класса X509Store нет ничего похожего, что бы указывало на возможность указания другого компьютера. Чаще всего используется вот этот: X509Store(String, StoreLocation). В качестве первого параметра как правило указываем название контейнера, а в качестве второго указываем само хранилище — CurrentUser или LocalMachine. Однако, для этого конструктора есть один трюк: если к первому аргументу приписать имя компьютера, мы получим доступ к хранилищу удалённого компьютера и вот как это выглядит:

# создаём объект класса X509Store с указанием удалённого компьютера в формате:
# \\ИмяКомпьютера\НазваниеКонтейнера. Второй аргумент всегда должен быть LocalMachine.
$store = New-Object Security.Cryptography.X509Certificates.X509Store(\\ComputerName\ContainerName, "LocalMachine")
# открываем соответствующий контейнер в режиме ReadOnly. Если открываем для записи, тогда
# флаг должен быть ReadWrite.
$store.Open("ReadOnly")
# просматриваем содержимое контейнера.
$store.Certificates
# вытворяем гадости с сертификатами удалённой машины

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

Даже встроенным ремотингом PowerShell'а не нужно заморачиваться. С одной стороны это крутой чит — можно не отходя от кассы доставить сертификатов куда надо. Но тут есть один нюанс. Даже имея права стандартного пользователя можно получить такой доступ, если ремотинг .NET'а не зарезан фиреволом (что внутри периметра мало практикуется) и стащить компьютерный сертификат с закрытым ключом со всеми вытекающими последствиями. Правда, тут стоит оговориться, что стащить удастся только сертификат, у которого закрытый ключ помечен как Exportable. Но, учитывая массовые рекомендации вайтпеперов МСа, в подавляющем случае это будет так. Защититься от этого можно тремя способами (расположены в порядке возрастания стоимости решения):

1. Не помечать закрытый ключ компьютерных сертификатов как разрешённый для экспорта;
2. Зафиреволить наглухо все серверы в периметре;
3. Приобрести для этих серверов HSM (Hardware Security Module).

Первый метод самый дешёвый и простой. Он не требует каких-то специальных знаний от администратора. Второй относительно дешёв, но требует достаточно глубоких знаний от администратора, т.к. некорректно настроенный фиревол может привести к потере удалённого контроля над сервером. А третий прост примерно как и первый способ, но требует определённых капиталовложений (порядка нескольких килобаксов за единицу девайса). Об этом можно дискутировать долго и упорно, моя же задача здесь предельно проста: рассказать как решить задачу и поведать о возможных последствиях