По приведенной выше ссылке вы можете подписать драйвер модели ядра с помощью сертификата подписи кода, а затем снова подписать его с помощью перекрестно подписанного сертификата. Это требуется для драйвера режима ядра.
Вопрос в том, есть ли какая-либо причина/выгода от подписания ваших пакетов exe/msi сертификатом с перекрестной подписью?
Если нет никакой пользы, зачем она нужна для драйвера режима ядра? Как это делает его более безопасным?
Перекрестная подпись дает дополнительный уровень доверия, что важно для драйверов режима ядра. Перекрестная подпись обеспечивает дополнительное доверие, поскольку крайне маловероятно, что оба центра сертификации будут скомпрометированы.
Для EXE и MSI может показаться, что перекрестная подпись означает, что вашему исполняемому файлу все еще можно доверять в случае, если один из авторитетов был скомпрометирован.
РЕДАКТИРОВАТЬ:
Мой личный опыт, связанный с этим, связан с сборками, подписанными Authenticode, и с тем, как они могут загружаться медленно (вы не сказали, является ли ваш EXE сборкой .NET). См. здесь https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assemblies/
Характеристики нагрузки сборки
Когда CLR загружает сборку с подписью Authenticode, она всегда пытается проверить эту подпись. Это отличается от загрузчика Windows, который проверяет подпись файла только в определенных случаях, например, когда файл является элементом управления ActiveX. Эта проверка может занять довольно много времени, поскольку может требуется несколько раз подключиться к сети, чтобы загрузить актуальные списки отозванных сертификатов, а также убедиться, что на пути к доверенному корню существует полная цепочка действительных сертификатов. Таким образом, когда подпись Authenticode применяется к сборке, нередко можно увидеть задержку в несколько секунд во время загрузки этой сборки.
Также обратите внимание, что оптимизация применяется к сборкам со строгими именами, где подпись строгого имени не проверяется, если сборка загружается из GAC, не применяется к подписям Authenticode. Поскольку Authenticode предоставляет возможность отозвать сертификат, мы не можем предположить, что, поскольку подпись Authenticode сборки была действительной, когда она попала в GAC, она будет оставаться действительной каждый раз, когда мы ее загружаем.
Для меня это означает, что если ваш EXE-файл создан с помощью .NET (т. е. это сборка), то, вероятно, чем большим числом ЦС он подписан, тем медленнее он может загружаться. Если это не .NET или элемент управления ActiveX (или некоторые экземпляры), то задержки не будет.
