Я осенью уже поднимал вопрос о проблемах, возникших после истечения промежуточного сертификата от GlobalSign. Я им тогда написал, они не ответили, тем временем я путем шаманства с сертификатами и версиями signtool добился исправления цепочки, драйверы стали нормально грузиться под Win10, а проверить в Win7/8 без подключенного отладчика, чтобы проверялась подпись, как-то не дошли руки.

Сегодня пользователь пожаловался, что его Win7x64 считает драйвер неподписанным, и не грузит его. Проверил в своих Win7/8 — то же самое. И Digital Signatures в свойствах файлов SYS/CAT, и signtool verify (с ключом /kp и без него) показывают, что все в порядке. Обновление Win7 для SHA256 стоит и у меня, и у пользователя.

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

Что это вообще за бред? Как такое может получаться?

Для подписи и проверки использую signtool 6.1.7600.16385 (из SDK/WDK от Win7). Уж с семеркой-то оно должно быть совместимо, сколько лет работало-то...

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Что это вообще за бред? Как такое может получаться?

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

https://www.youtube.com/watch?v=XjuhbRRJW08

Здравствуйте, velkin, Вы писали:

V>Бред это политика микрософта с обязательными платными сертификатами

Не понял. Гугл и эппл выдают сертификаты сами и бесплатно? Производители браузеров, предупреждающих об отсутствии или несоответствии сертификата у сайта, тоже раздают сертификаты бесплатно?

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Сертификаты в киберпространстве жизненно необходимы, как и удостоверения личности в реальном пространстве.

Это не так, ещё недавно не было никаких сертификатов. Удивительно, но драйвера под винду загружались просто так и никто не жаловался. А что сейчас:

ЕМ>Сегодня пользователь пожаловался, что его Win7x64 считает драйвер неподписанным, и не грузит его.

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

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

Для примера: Как отключить проверку цифровой подписи драйвера в Windows 7

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

Здравствуйте, velkin, Вы писали:

V>ещё недавно не было никаких сертификатов. Удивительно, но драйвера под винду загружались просто так и никто не жаловался.

А еще раньше не было никаких удостоверений личности. И тоже никто не жаловался, кроме обманутых разного рода жуликами.

V>Пользователь верит производителю программного обеспечения

На каком основании он верит производителю? Как пользователь определяет, кто именно является производителем? Пользователь получает ПО непосредственно от человека, которому он лично доверяет?

V>и хочет его запустить. Причём не факт, что он верит центру сертификации или микрософтам.

На каком основании доверия центру сертификации или микрософтам должно быть меньше?

V>Но он не может этого сделать.

Может, но ценой дополнительных телодвижений.

V>Они не могут спросить пользователя, что дескать драйвера не подписаны, вы действительно хотите их установить?

Они спрашивают, если драйвер не сертифицирован WHQL. Но в ситуации массового распространения ПО, работающего с деньгами и данными разной степени конфиденциальности, установка драйвера неизвестного происхождения только по желанию пользователя (который в среднем, к сожалению, глуп и доверчив) — слишком опасное мероприятие.

Здравствуйте, Евгений Музыченко, Вы писали:

...
ЕМ>Сегодня пользователь пожаловался, что его Win7x64 считает драйвер неподписанным, и не грузит его. Проверил в своих Win7/8 — то же самое. И Digital Signatures в свойствах файлов SYS/CAT, и signtool verify (с ключом /kp и без него) показывают, что все в порядке. Обновление Win7 для SHA256 стоит и у меня, и у пользователя.

ЕМ>Затем обнаружил, что система не грузит драйвер только в том случае, если нет соединения с интернетом. Если оно есть, то драйвер грузится, хотя предупреждение о неудаче проверки подписи все равно выдается. Если драйвер однажды успешно загрузился, после этого можно отключить интернет, удалить драйвер, и устанавливать его любое количество раз — он будет загружаться, но система будет ругаться на подпись.

ЕМ>Что это вообще за бред? Как такое может получаться?

ЕМ>Для подписи и проверки использую signtool 6.1.7600.16385 (из SDK/WDK от Win7). Уж с семеркой-то оно должно быть совместимо, сколько лет работало-то...

ЕМ>Чем еще можно поискать, где глюк? Получается, что сообщение о неподписанном драйвере выдается не по отказу ядерного загрузчика, а по результатам независимой проверки подписи, а ядерный загрузчик, в свою очередь, пользуется результатами проверки подписи через сеть.

Верно, во время установки устройства сначала проверяется подпись .cat, и может быть ругань на ее невалидность, которую пользователь может игнорировать. Далее в соответствии с .inf копируются файлы на свои места и т.д., а уже после этого в дело вступает ядерный загрузчик и проверяет подпись, хранящуюся в .sys (и которая совершенно независима от подписи .cat). И если он обламывается, то устройство помечается ошибкой в Диспетчере устройств, а сообщения уже выдаются программами, не сумевшими открыть этот драйвер.

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

Какую-то информацию о проверке подписи .cat можно почерпнуть из %windir%\inf\setupapi.dev.inf.

Здравствуйте, Sergei I. Gorelkin, Вы писали:

SIG>Верно, во время установки устройства сначала проверяется подпись .cat, и может быть ругань на ее невалидность, которую пользователь может игнорировать. Далее в соответствии с .inf копируются файлы на свои места и т.д., а уже после этого в дело вступает ядерный загрузчик и проверяет подпись, хранящуюся в .sys (и которая совершенно независима от подписи .cat).

Тут где-то есть неточность — по крайней мере, для стандартных драйверов MS, среди которых чуть не половина .sys не подписана.

SIG>И если он обламывается, то устройство помечается ошибкой в Диспетчере устройств, а сообщения уже выдаются программами, не сумевшими открыть этот драйвер.

Нет, сообщение выдает Program Compatibility Assistant. В обоих случаях (и когда драйвер грузится, и когда нет).

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

В том-то и дело, что речь не о чистой системе, а только о свежезагруженной. После перезагрузки, если отключить интернет, драйвер снова перестает загружаться.

SIG>Только эти сертификаты делают валидной подпись .sys, а с подписью .cat остаются проблемы.

Даже если и так, то почему? И .sys, и .cat подписываются одной и той же командной строкой, с кросс-сертификатом. И в закладках Digital Signatures все шоколадно. Вот мне и интересно, откуда берется разница в алгоритме проверки ядерным загрузчиком и средствами пользовательского режима, и почему наличие интернет-соединения влияет именно на проверку в ядре, хотя обычно как раз наоборот.

SIG>Какую-то информацию о проверке подписи .cat можно почерпнуть из %windir%\inf\setupapi.dev.inf.

Там то же самое, что выдают версии signtool новее 6.1.7600 без ключа /kp: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

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

Здравствуйте, Sergei I. Gorelkin, Вы писали:

SIG>в дело вступает ядерный загрузчик и проверяет подпись, хранящуюся в .sys

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

	Подпись сертификатом 2013-го, сделанная в 2015-м
	Verifying: vrtaucbl.sys Hash of file (sha1): 20B371AB981BF6DFC0228A5BE1889E3BADD5E0AD Signing Certificate Chain: Issued to: GlobalSign Root CA Issued by: GlobalSign Root CA Expires: Fri Jan 28 13:00:00 2028 SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C Issued to: GlobalSign CodeSigning CA — G2 Issued by: GlobalSign Root CA Expires: Sat Apr 13 11:00:00 2019 SHA1 hash: 9000401777DD2B43393D7B594D2FF4CBA4516B38 Issued to: Muzychenko Evgenii Viktorovich Issued by: GlobalSign CodeSigning CA — G2 Expires: Tue May 17 19:32:18 2016 SHA1 hash: 4E77B804FF532214FE99C4FE28B5C9411BD5BA1B

	Подпись сертификатом 2017-го, сделанная в 2018-м
	Verifying: vrtaucbl.sys Hash of file (sha256): 4C584E215C43AD1989B2989919FBA54F3AB307ADDF74C2EDE8CAE9112F86E60E Signing Certificate Chain: Issued to: GlobalSign Root CA Issued by: GlobalSign Root CA Expires: Fri Jan 28 13:00:00 2028 SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C Issued to: GlobalSign Issued by: GlobalSign Root CA Expires: Mon Mar 18 11:00:00 2019 SHA1 hash: 4765557AF418C68A641199146A7E556AA8242996 Issued to: GlobalSign Extended Validation CodeSigning CA — SHA256 — G3 Issued by: GlobalSign Expires: Sat Jun 15 01:00:00 2024 SHA1 hash: 87A63D9ADB627D777836153C680A3DFCF27DE90C Issued to: Muzychenko Evgenii Viktorovich, IP Issued by: GlobalSign Extended Validation CodeSigning CA — SHA256 — G3 Expires: Tue Aug 18 12:57:24 2020 SHA1 hash: D25CEAE07AE5BA4193D69126003095E85A33BBE1

То же самое видно и во вкладке Digital Signatures/Certification Path. Где подвох? Я всю эту кухню не до конца понимаю, это раздражает.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Sergei I. Gorelkin, Вы писали:

SIG>>Верно, во время установки устройства сначала проверяется подпись .cat, и может быть ругань на ее невалидность, которую пользователь может игнорировать. Далее в соответствии с .inf копируются файлы на свои места и т.д., а уже после этого в дело вступает ядерный загрузчик и проверяет подпись, хранящуюся в .sys (и которая совершенно независима от подписи .cat).

ЕМ>Тут где-то есть неточность — по крайней мере, для стандартных драйверов MS, среди которых чуть не половина .sys не подписана.

Да, подписи драйверов из исходного состава системы хранятся отдельно от бинарников, но, судя по всему, среди 3rd party драйверов такое не встречается.

SIG>>И если он обламывается, то устройство помечается ошибкой в Диспетчере устройств, а сообщения уже выдаются программами, не сумевшими открыть этот драйвер.

ЕМ>Нет, сообщение выдает Program Compatibility Assistant. В обоих случаях (и когда драйвер грузится, и когда нет).

Видимо, еще зависит от способа установки. Последний раз колупался с криво подписанным драйвером в составе USB Command Verifier, там точно Program Compatibility Assistant не вылезал.

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

ЕМ>В том-то и дело, что речь не о чистой системе, а только о свежезагруженной. После перезагрузки, если отключить интернет, драйвер снова перестает загружаться.

Тут я неправильно понял Тогда действительно все загадочнее...

SIG>>Только эти сертификаты делают валидной подпись .sys, а с подписью .cat остаются проблемы.

ЕМ>Даже если и так, то почему? И .sys, и .cat подписываются одной и той же командной строкой, с кросс-сертификатом. И в закладках Digital Signatures все шоколадно. Вот мне и интересно, откуда берется разница в алгоритме проверки ядерным загрузчиком и средствами пользовательского режима, и почему наличие интернет-соединения влияет именно на проверку в ядре, хотя обычно как раз наоборот.

Посмотрел повнимательнее один из драйверов — и вправду подписан в двух местах, если signtool указать ключ /as — он говорит, что подпись в соответствующем oemX.cat, если не указывать — ничего не говорит и проверяет .sys.

SIG>>Какую-то информацию о проверке подписи .cat можно почерпнуть из %windir%\inf\setupapi.dev.inf.

ЕМ>Там то же самое, что выдают версии signtool новее 6.1.7600 без ключа /kp: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

Хех, у меня signtool 6.1.7600.16385 (еще старый?) выдал это же на драйвер, установленный без ошибок... Причем, корневой сертификат в списке доверенных присутствует.

ЕМ>Насколько я понимаю, для подписи с кросс-сертификатом это нормально, и /kp как раз и реализует нужный алгоритм проверки.

В моем представлении, алгоритм /kp выполняется только ядром, а пользовательском режиме — нет, возможно поэтому и возникает ошибка. Интереснее то, что в закладке Digital Signatures проверка выполняется явно без /kp, и почему там все нормально, а с signtool нет —

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Sergei I. Gorelkin, Вы писали:

SIG>>в дело вступает ядерный загрузчик и проверяет подпись, хранящуюся в .sys

ЕМ>Вот, кстати, еще чего не понимаю. Пишут, что для успешной проверки в режиме ядра необходимо, чтобы цепочка сертификатов заканчивалась на корневом сертификате MS, для чего и используется кросс-сертификат, выдаваемый MS. Однако ж, смотрю на свои прежние подписи (с которыми драйверы ставятся и загружаются без ошибок), как старым сертификатом 2013-го года, так и нынешним, сделанную в 2018-м, и все они оканчиваются на сертификат, выданный GS для GS:

...

ЕМ>То же самое видно и во вкладке Digital Signatures/Certification Path. Где подвох? Я всю эту кухню не до конца понимаю, это раздражает.

Это похоже на выхлоп signtool verify /v без ключа /kp. Если добавить /kp, должна добавиться и информация о кросс-сертификате. Там как бы две цепочки сертификатов, одна обычная, а вторая заканчивается на MS.
А вкладка Digital Signatures об этом вообще не знает.

Здравствуйте, Sergei I. Gorelkin, Вы писали:

SIG>Да, подписи драйверов из исходного состава системы хранятся отдельно от бинарников

Но не все. Какие-то подписаны внутри, какие-то снаружи.

SIG>Видимо, еще зависит от способа установки. Последний раз колупался с криво подписанным драйвером в составе USB Command Verifier, там точно Program Compatibility Assistant не вылезал.

Странно, поскольку сообщение от Assistant вылезает только через 5-10 с после внешне успешного (если не проверять флаги проблем) завершения установки. То есть, не похоже, чтобы его вызывали из UpdateDriverForPlugAndPlayDevices.

SIG>В моем представлении, алгоритм /kp выполняется только ядром, а пользовательском режиме — нет, возможно поэтому и возникает ошибка. Интереснее то, что в закладке Digital Signatures проверка выполняется явно без /kp, и почему там все нормально, а с signtool нет —

И почему у signtool с /kp тоже все нормально, а в ядре — нет.

SIG>Если добавить /kp, должна добавиться и информация о кросс-сертификате.

Спасибо, я не сообразил, что этот вывод тоже зависит от /kp. С ним все заканчивается на корневом от MS:

	Подпись старым сертификатом в 2015-м
	Cross Certificate Chain: Issued to: Microsoft Code Verification Root Issued by: Microsoft Code Verification Root Expires: Sat Nov 01 14:54:03 2025 SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3 Issued to: GlobalSign Root CA Issued by: Microsoft Code Verification Root Expires: Thu Apr 15 21:05:08 2021 SHA1 hash: CC1DEEBF6D55C2C9061BA16F10A0BFA6979A4A32 Issued to: GlobalSign CodeSigning CA — G2 Issued by: GlobalSign Root CA Expires: Sat Apr 13 11:00:00 2019 SHA1 hash: 9000401777DD2B43393D7B594D2FF4CBA4516B38 Issued to: Muzychenko Evgenii Viktorovich Issued by: GlobalSign CodeSigning CA — G2 Expires: Tue May 17 19:32:18 2016 SHA1 hash: 4E77B804FF532214FE99C4FE28B5C9411BD5BA1B

	Подпись текущим сертификатом в 2018-м
	Cross Certificate Chain: Issued to: Microsoft Code Verification Root Issued by: Microsoft Code Verification Root Expires: Sat Nov 01 14:54:03 2025 SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3 Issued to: GlobalSign Root CA Issued by: Microsoft Code Verification Root Expires: Thu Apr 15 21:05:08 2021 SHA1 hash: CC1DEEBF6D55C2C9061BA16F10A0BFA6979A4A32 Issued to: GlobalSign Issued by: GlobalSign Root CA Expires: Mon Mar 18 11:00:00 2019 SHA1 hash: 4765557AF418C68A641199146A7E556AA8242996 Issued to: GlobalSign Extended Validation CodeSigning CA — SHA256 — G3 Issued by: GlobalSign Expires: Sat Jun 15 01:00:00 2024 SHA1 hash: 87A63D9ADB627D777836153C680A3DFCF27DE90C Issued to: Muzychenko Evgenii Viktorovich, IP Issued by: GlobalSign Extended Validation CodeSigning CA — SHA256 — G3 Expires: Tue Aug 18 12:57:24 2020 SHA1 hash: D25CEAE07AE5BA4193D69126003095E85A33BBE1

	Подпись новым сертификатом три дня назад
	Cross Certificate Chain: Issued to: Microsoft Code Verification Root Issued by: Microsoft Code Verification Root Expires: Sat Nov 01 14:54:03 2025 SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3 Issued to: GlobalSign Issued by: Microsoft Code Verification Root Expires: Wed Jun 04 18:47:53 2025 SHA1 hash: 814A5BB5E9093011E121E75169008F6F4667363D Issued to: GlobalSign Extended Validation CodeSigning CA — SHA256 — G3 Issued by: GlobalSign Expires: Sat Jun 15 01:00:00 2024 SHA1 hash: 87A63D9ADB627D777836153C680A3DFCF27DE90C Issued to: Muzychenko Evgenii Viktorovich, IP Issued by: GlobalSign Extended Validation CodeSigning CA — SHA256 — G3 Expires: Tue Aug 18 12:57:24 2020 SHA1 hash: D25CEAE07AE5BA4193D69126003095E85A33BBE1

Есть в последней цепочке хоть что-нибудь подозрительное?

Попробовал подписать новыми (вплоть до 18362) версиями signtool. Если без временной метки, то ничего не меняется. Если с меткой, то все версии или виснут, или падают сразу после выдачи "Done Adding Additional Store", в зависимости от того, какой URL сервера времени задаю в параметрах.

Дурдом, однако.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Как такое может получаться?

С подсказки GlobalSign, присмотрелся более внимательно к их руководству, и заметил, что они предлагают использовать кросс-сертификат R1 от MS, вместе с их собственным R1-R3. Сейчас вспоминаю, что после протухания их промежуточного сертификата я именно так и пытался делать, но подписывание не работало. Разбираться было некогда, я попробовал кросс-сертификат R3, все заработало, а проверить под семеркой/восьмеркой без отладчика тогда руки не дошли.

Сейчас попробовал связку R1 с R1-R3 (его пришлось установить в Intermediate, ибо иначе его сунуть некуда) — семерки/восьмерки такую подпись принимают, драйвер грузится.

Но остается вопрос: можно ли считать нормальной ситуацию, в которой две разных цепочки сертификатов одинаково успешно проверяются всеми версиями signtool с ключом /kp, в том числе и на целевых машинах, но одна из этих цепочек не принимается ядерным загрузчиком целевых машин?

И есть ли другие средства проверки подписи драйвера, кроме signtool /kp?