Air-gapped.NET подписанное кодом приложение не будет устанавливать/запускать

мы недавно обновили наши приложения, чтобы использовать кодовую подпись SHA-256 с новым сертификатом. Сборки имеют строгое имя, подписанное с помощью Sign the assembly опция в Visual Studio 2015. Событие post build в Visual Studio запускает два signtool.exe процессы для входа как в SHA-256, так и в устаревший сертификат SHA-1:

call "C:Program Files (x86)Windows Kitsbinx86signtool.exe" 
sign /f "<mystrongName.pfx>" /p "<password>" /t 
<timestampURL> "$(TargetPath)"

call "C:Program Files (x86)Windows Kitsbinx86signtool.exe" 
sign /f "<mystrongName.pfx>" /p "<password>" /fd sha256 /tr 
<timestampURL> /td sha256 /as /v "$(TargetPath)"

наконец, мы используем Advanced Installer в качестве установочного упаковщика, и это тоже подписано кодом на Digital Signature страницы с использованием сертификата и отметка на .подпись exe.

окончательный файл установки устанавливается и запускается на подключенных к интернету машинах Windows, как и следовало ожидать. Вы можете видеть, что сертификат назначен и действителен, а также Цепочка сертификатов через свойства обеих настроек.exe и в runtime при установке. Кроме того, Windows распознает приложение как доверенный источник и отображает соответствующие проверенные данные издателя.

наша клиент-база в большинстве глобальна 100 компаний и большинство развертываний будут происходить в воздушных сетях. В одном из наших обновленных развертываний fist в этой среде не удалось проверить сертификат, препятствуя завершению установки.

это имело смысл, потому что машины Windows (2012 server R2) были изолированы от интернета и, из-за политики компании, имели Turn off Automatic Root Certificates значение Enabled. Этот параметр можно найти в Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication Settings папка приложения MMC (вам нужны сертификаты плагин установлен).

при тестировании на нашем локальном тестовом стенде даже машины, не подключенные к интернету, будут устанавливать сертификаты из утилиты установки, если указанный выше параметр реестра был по умолчанию (Disabled). Мы могли бы повторить проблему, изменив параметр политики в соответствии с клиентами (Enabled).

в качестве обходного пути мы вручную загрузили корневой сертификат центра сертификации и установили его как доверенный корневой сертификат, и установка будет действуйте нормально.

когда мы представили этот обходной путь клиенту, установка все еще не удалась, несмотря на корневой сертификат центров сертификации, присутствующий в доверенных корневых сертификатах машины.

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

Я не совсем уверен, что это исправит проблему, потому что, когда мы тестировали локально, сертификат все еще был найден установщиком и позволил продолжить установку, когда корневой сертификат центра сертификации был установлен вручную.

то, что я не могу сделать, это реплицировать среду клиентов, чтобы точно воспроизвести проблема (которая не помогает). Это почти так же, как если бы Windows обходила хранилище доверенных корневых сертификатов локального компьютера. Я предполагаю, что если это возможно, это будет так, что Windows может проверить центральное корневое хранилище сертификатов.

возможно ли это даже настроить в Windows? Если да, то где я могу найти документацию по этому вопросу или как это делается?

я пропустил что-то в шагах подписи кода или в моем понимании того, что должно быть происходит на установочной машине во время проверки сертификата?

Я в недоумении, что делать, чтобы заставить этот установщик работать. То, что я не могу себе позволить, это продолжать возвращаться к клиенту, чтобы заставить их продолжать тестирование наших установок. Во-первых, это действительно не правильный процесс для отладки, поскольку поставщик-поставщик это не проблема клиентов, но, что более важно, мне нужно, чтобы наша команда поняла, что вызывает это и как это исправить правильно.

в идеале я не то, что отбросить метку времени, если мне не нужно, потому что по дороге это вызовет новые проблемы, если программное обеспечение не будет обновлено до истечения срока действия сертификата.

любой и вся помощь приветствуется.

1 ответов


Я думаю, что одной из причин, по которой сертификат не может быть проверен в среде airgapped, может быть то, что отзыв не может быть проверен. Как вы знаете, сертификат может быть отозван, и есть два разных протокола для проверки, если это так, CRL и OCSP. Оба требуют сетевого доступа к ЦС, выдавшему сертификат.

ли аннулирования фактически проверяются, регулируется политикой, как описано здесь, и это может вызвать проблемы.