О том, как я разворачивала Package Publisher и проблема, решение которой я не нашла на просторах интернета
Поставили как-то передо мной задачу развернуть в нашей маленькой сеточке на 1000 машин сервер обновлений. Вообще, администрирование – не моя основная задача, да и последние два года windows в глаза вижу только по очень большим праздникам. Но горячо любимая служба информационных технологий сказала: «Вам безопасникам это надо, вы и занимайтесь».
Так что, собрав волю в кулак, я пошла читать мануалы по разворачиванию WSUS. И если тут все просто, понятно, а все проблемы, которые могли бы возникнуть, уже встречались кому-то и давно описаны на форумах, то с Package Publisher возникло много вопросов.
Для чего он был вообще нужен? Потому что была необходимость централизованно обновлять не только систему и приложения Microsoft, но и сторонние, в частности Firefox. Причем только на тех машинах, на которых он уже установлен. (Как альтернатива рассматривался еще LUP, функционал примерно тот же, но добрые люди на форумах сказали, что он уже не поддерживается и намного сложнее интегрируется с WinServ2016.)
Итак, WSUS был развернут. За что стоит любить Windows, так это «Далее -> Далее -> Готово, вы восхитительны». Настало время Package Publisher. Все ссылки, которые есть в принципе в интернете на него, ведут сюда. Там же есть ссылка на гит, в котором подробно описан процесс установки. А именно: скачать архив, распаковать, запустить «Wsus Package Publisher.exe».
В линухе я привыкла просто клонировать репозитории в гитхаба. А вот за что не стоит любить Windows, там все работает не так. Если скачать репозитоий, просто нажав на зеленую кнопочку, то, о ужас, в архиве не будет EXE-файла. Серьезно, я 20 минут пыталась понять, в чем подвох, и где я его потеряла. Оказалось, надо просто качать определенный релиз.
Установка порадовала, точнее ее отсутствие. EXE-шник запускается, без всякой установки, сам находит WSUS (на той же машине разворачивала) и при подключении к нему выдает сообщение об отсутствии сертификата и невозможности опубликовать обновления.
Логично предположить, что следующим шагом надо скормить WSUS Package Publisher сертификат (Tools -> Certificate). Можно сгенерировать самоподписанный. Но очень уж не хотелось так делать. Тем более коллега недавно развернул локальный сервер сертификации. Что интересно, кнопка загрузки сертификата становится активной только после ввода парольной фразы. «Close». Проверив в консоли mmc, что нужный мне сертификат находится в контейнере «WSUS», а все связанные в «доверенные издатели» и «доверенные корневые центры сертификации», я искренне надеялась, что после перезапуска службы WSUS будет мне счастье. Ага!
При создании обновления (о том, как это сделать для Firefox можно почитать тут), на последнем этапе возникает ошибка: «Verification of file signature failed for file:
\\[serverName]\UpdateServicesPackages\AppName_abf10b91-bfa6-44ff-aa54-099e4bf1487d\a7f3d4b2-02b6-4f0c-ab9b-e38c8de9c3f0_1.cab» (Невозможно проверить сигнатуру для файла…). Гугл говорит, что причина в том, что сертификата не хватает в контейнере «доверенные корневые центры сертификации». Но он там был! И не только он! Куда я только его не пробовала положить. Безуспешно.
Через полтора часа безуспешных попыток, я сдалась и решила все же использовать самоподписанный сертификат WPP. Не за что не поверите, что я увидела, зайдя в консоль mmc.
Для подписи кода генерируется специальный сертификат
То есть сертификат должен быть сгенерирован специально для подписи кода. Что еще важно, закрытый ключ должен быть экспортируемым! А дальше дело техники, с помощью ГПО распространить цепочку сертификатов на машинки сети (тут уже без закрытого ключа), и можно централизовано устанавливать и обновлять любые приложения.
Итак, если у вас возникает ошибка Verification of file signature failed for file, или любая другая похожая:
Невозможно проверить сигнатуру для файла \\[serverName]\UpdateServicesPackages\AppName_abf10b91-bfa6-44ff-aa54-099e4bf1487d\a7f3d4b2-02b6-4f0c-ab9b-e38c8de9c3f0_1.cab
Verification of file signature failed for file: \\[serverName]\UpdateServicesPackages\AppName_abf10b91-bfa6-44ff-aa54-099e4bf1487d\a7f3d4b2-02b6-4f0c-ab9b-e38c8de9c3f0_1.cab
Поставили как-то передо мной задачу развернуть в нашей маленькой сеточке на 1000 машин сервер обновлений. Вообще, администрирование – не моя основная задача, да и последние два года windows в глаза вижу только по очень большим праздникам. Но горячо любимая служба информационных технологий сказала: «Вам безопасникам это надо, вы и занимайтесь».
Так что, собрав волю в кулак, я пошла читать мануалы по разворачиванию WSUS. И если тут все просто, понятно, а все проблемы, которые могли бы возникнуть, уже встречались кому-то и давно описаны на форумах, то с Package Publisher возникло много вопросов.
Для чего он был вообще нужен? Потому что была необходимость централизованно обновлять не только систему и приложения Microsoft, но и сторонние, в частности Firefox. Причем только на тех машинах, на которых он уже установлен. (Как альтернатива рассматривался еще LUP, функционал примерно тот же, но добрые люди на форумах сказали, что он уже не поддерживается и намного сложнее интегрируется с WinServ2016.)
Итак, WSUS был развернут. За что стоит любить Windows, так это «Далее -> Далее -> Готово, вы восхитительны». Настало время Package Publisher. Все ссылки, которые есть в принципе в интернете на него, ведут сюда. Там же есть ссылка на гит, в котором подробно описан процесс установки. А именно: скачать архив, распаковать, запустить «Wsus Package Publisher.exe».
В линухе я привыкла просто клонировать репозитории в гитхаба. А вот за что не стоит любить Windows, там все работает не так. Если скачать репозитоий, просто нажав на зеленую кнопочку, то, о ужас, в архиве не будет EXE-файла. Серьезно, я 20 минут пыталась понять, в чем подвох, и где я его потеряла. Оказалось, надо просто качать определенный релиз.
Установка порадовала, точнее ее отсутствие. EXE-шник запускается, без всякой установки, сам находит WSUS (на той же машине разворачивала) и при подключении к нему выдает сообщение об отсутствии сертификата и невозможности опубликовать обновления.
Логично предположить, что следующим шагом надо скормить WSUS Package Publisher сертификат (Tools -> Certificate). Можно сгенерировать самоподписанный. Но очень уж не хотелось так делать. Тем более коллега недавно развернул локальный сервер сертификации. Что интересно, кнопка загрузки сертификата становится активной только после ввода парольной фразы. «Close». Проверив в консоли mmc, что нужный мне сертификат находится в контейнере «WSUS», а все связанные в «доверенные издатели» и «доверенные корневые центры сертификации», я искренне надеялась, что после перезапуска службы WSUS будет мне счастье. Ага!
При создании обновления (о том, как это сделать для Firefox можно почитать тут), на последнем этапе возникает ошибка: «Verification of file signature failed for file:
\\[serverName]\UpdateServicesPackages\AppName_abf10b91-bfa6-44ff-aa54-099e4bf1487d\a7f3d4b2-02b6-4f0c-ab9b-e38c8de9c3f0_1.cab» (Невозможно проверить сигнатуру для файла…). Гугл говорит, что причина в том, что сертификата не хватает в контейнере «доверенные корневые центры сертификации». Но он там был! И не только он! Куда я только его не пробовала положить. Безуспешно.
Через полтора часа безуспешных попыток, я сдалась и решила все же использовать самоподписанный сертификат WPP. Не за что не поверите, что я увидела, зайдя в консоль mmc.
Для подписи кода генерируется специальный сертификат
То есть сертификат должен быть сгенерирован специально для подписи кода. Что еще важно, закрытый ключ должен быть экспортируемым! А дальше дело техники, с помощью ГПО распространить цепочку сертификатов на машинки сети (тут уже без закрытого ключа), и можно централизовано устанавливать и обновлять любые приложения.
Итак, если у вас возникает ошибка Verification of file signature failed for file, или любая другая похожая:
- Генерируем в локальном центре сертификации Code Signing сертификат для нашего WSUS, где установлен Package Publisher. Закрытый ключ должен быть экспортируемым.
- Экспортируем сертификат с закрытым ключом и добавляем его в Package Publisher после ввода секретного ключа. Перезапускаем службу WSUS.
- Экспортируем без закрытого ключа и распространяем на клиентские машины.
- Обновляем и устанавливаем любые приложения централизованно и наслаждаемся жизнью.
AcidVenom
Статья о том, как важно читать инструкции.
Vasilisa_V Автор
Да, Вы абсолютно правы.
Но цель написания этой статьи была немного в другом. А именно объяснить возможную причину возникновения ошибки и дать решение, если кто-то с ней уже столкнулся. По тексту ошибки сложно найти ответ, тем более на русскоязычных ресурсах.
Спасибо.
yosemity
Ровно сейчас воюю с WSUSPP, сжег уже два стула. Насколько же удобным был LUP в части развертывания msi и насколько ущербным это сделали в WSUSPP.
perlestius
Вот он — корень зла. Это должны делать именно айтишники, а не безопасники. Дело ИБ — это аудит систем, а не их управление/администрирование.
sub31
Интересный инструмент и очень полезный, но…
Есть же SCCM. Ему эта задача несколько ближе, чем распространение чужих программных средств со своей подписью.
AcidVenom
И сколько будет стоить SC на 1000 машин?