О Code Signing

lexa - 15/Мар/2012 09:58

Хочу сказать, что процедура выдачи Verisign Code Signing сертификатов, если пользоваться вот прямо их средствами, какая-то ужасающая:

  • Приватный ключ (сгенерированный Verisign) приезжает в формате .p12
  • Сертификат - в формате PEM
  • Signtool хочет все вместе в формате .PFX (он же, похоже, .p12)
При этом - никаких инструкций "как с этой фигней взлететь" (для сертификатов сайтов - хоть есть "как это все поставить в Apache"), только строгое предупреждение в E-mail, по смыслу такое:
  • Вам обязательно нужны два intermediate-сертификата, возьмите их отсюда.
  • А на странице где эти сертификаты - две textarea с сертификатами, дескать Select All и сохраните в текстовый файл.

Кроме того, в E-mail инструкции строго написано, что скачивать сертификат можно строго на том компьютере, который делал запрос. Что делать, если за прошедшее время машинка дала дуба (а нам рисовали сертификат 2 недели, не верьте что в Штатах все быстро) - неизвестно.

На этом фоне рождаются душераздирающие инструкции вроде всосите все в MSIE и им экспортируйте, но они годятся только если private key уже импортирован в систему (например, сделан MS-овской тулзой, которая сразу инсталлирует сделанный ключ в систему), скачаный с Verisign приватный ключ - не импортируется.

Под катом - инструкция, как все починить с помощью OpenSSL (записки для себя):

1. Verisign-овские intermediate - сохраняем в .PEM-файлы и импортируем в систему (по правой кнопке в Windows Explorer - все работает). Signtool их умеет оттуда взять, вот и прекрасно.

2. Конвертируем Private key в PEM-формат:

openssl pkcs12 -in key.p12 -out key.pem  -nomacver
Спросит пароли: на исходный ключ key.p12 и на новое шифрование в pem. Пароли могут быть разными. -nomacver - не верифицировать целостность ключа, почему-то OpenSSL считает его нецелостным.

3. Слепляем из сертификата (в PEM-формате, он так пришел из Verisign) и сконвертированного нами ключа (который на прошлом шаге мы сконвертировали в PEM) ключик в формате PKCS12:

openssl pkcs12 -export -inkey key.pem -in cert.cer -out keyandcert.pfx
Опять спросят пароль на key.pem (мы его задали на прошлом шаге) и пароль экспорта. Они опять могут быть разными.

4. Проверяем результат:

Подписываем:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe"  sign /f keyandcert.pfx /p mypassword myfile.dll
Проверяем:
signtool.exe  verify /pa /v myfile.dll
Hash of file (sha1): CE33C7881C92EC4BD05119CFBFD062D4C2F0C24E

Signing Certificate Chain:
    Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
    Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
    Expires:   Thu Jul 17 03:59:59 2036
    SHA1 hash: 4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5

        Issued to: VeriSign Class 3 Code Signing 2010 CA
        Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
        Expires:   Sat Feb 08 03:59:59 2020
        SHA1 hash: 495847A93187CFB8C71F840CB7B41497AD95C64F

            Issued to: LibRaw LLC
            Issued by: VeriSign Class 3 Code Signing 2010 CA
            Expires:   Thu Feb 28 03:59:59 2013
            SHA1 hash: E5FDED60148BB9A3DB4F86A171676A013ECD1E3C

File is not timestamped.

Successfully verified: myfile.dll

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

P.S. Вопрос к тем, кто понимает механику процесса. Можно ли для таймстампинга использовать произвольный timestamp сервер? А то Verisign-овский как-то работает через раз, вечером работал, сейчас - ругается на несоответствие его RFC3161, при этом с комодовским - все нормально. Верификация такой двойной подписи - проходит нормально (на Win7 и на XP), но может быть что-то сломается когда кончится действие нашего сертификата?

Comments

_slw (not verified) - 15/Мар/2012 10:19

я что-то не понял, как это -- приватные ключи аерисигн генерит? wtf?

b00ter (not verified) - 15/Мар/2012 10:23

Присоединяюсь. Они, наверное, там совсем укурились.

lexa - 15/Мар/2012 10:32

Для лохов (вроде нас) - ключ можно сгенерировать прямо там.
С учетом того, что мне, по большому счету, насрать на возможную утечку этого самого ключа у верисайна (если утечет - то утечет много), так делать проще.
Это много у кого есть, когда я StartSSL-евский сертификат делал бесплатный (для сайта)- там тоже была такая возможность.

В обоих случаях можно свой CSR загрузить, но вот для Code Signing - я честно не знаю что писать в Subject, поэтому пусть уж сам Verisign.

vitus_wagner (not verified) - 15/Мар/2012 10:51

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

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

lexa - 15/Мар/2012 10:53

Меня вот гораздо больше беспокоит, когда банковский сертификат генерируется непонятно чем (Ява-апплетом, к примеру) и нельзя понять, это непонятно-что не выливает ли private key кому следует.

J0hn - 15/Мар/2012 12:25

во, меня это тоже смутило.
Правда у меня это было только для инет банка физ.лица(там даже не java апплет был, а ActiveX) (для ИП у меня всё локально генерировалось). Но тем не менее очень неприятно, ведь основные средства на физ.счетах у меня.

_slw (not verified) - 15/Мар/2012 10:57

зачем ему знать мой приватный ключ?

_slw (not verified) - 15/Мар/2012 10:58

ну так покажи, что кошерно писать во все поля

lexa - 15/Мар/2012 11:08

У нас написано вот так:

Subject: C=US, ST=Maryland, L=N. Potomac, O=LibRaw LLC, OU=Digital ID Class 3 - Microsoft Software Validation v2, CN=LibRaw LLC

При этом OU мы не заполняли. Возможно, MS-овская тулза для делания CSR сделает это сама

vitus_wagner (not verified) - 15/Мар/2012 13:16

Вообще говоря, при выписывании сертификата удостоверяющий центр волен добавить или исключить любые поля с любыми значениями. Никто не обещал что Subject выданного сертификата будет побитово (или с точнгостью до результата функции X509_NAME_hash) c Subject CSR.

Поскольку на то есть certification policy удостоверяющего центра.

vitus_wagner (not verified) - 15/Мар/2012 13:08

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

vitus_wagner (not verified) - 15/Мар/2012 10:49

MAC в данном случае не MAC-адрес сетевой карты, а message authentication code - криптографический контроль целостности ключа. Во всяком случае опция -nomacver отключает именно проверку Message Authentication code, предусмотренного в формате PKCS#12

lexa - 15/Мар/2012 10:52

Спасибо, поправил.
Почему он считается некошерным OpenSSL-ем - честное слово не знаю. Без nomacver - не работает. После проделанных процедур - все, наоборот, работает. Загадка.

vitus_wagner (not verified) - 15/Мар/2012 13:05

В man pkcs12 есть некоторые соображения по этому поводу. Например, стандарт PKCS#12 теоретически позволяет использовать для вывода ключа шифрования ключа и ключа проверки целостности разные пароли, а большая часть софта этого не поддерживает. Поэтому openssl по умолчанию пытается проверять MAC на том же ключе, что использовался для расшифрования. У pkcs12 на эту тему еще есть опция -twopass, заставляющая запрашивать два пароля.

Вообще, конечно надо на дамп asn1 структуры смотреть. У pkcs#12 оно заковы-ы-ы-ристое.Из серии "стандарты хороши тем, что их много, и есть из чего выбирать".

wizzard0 (not verified) - 15/Мар/2012 23:32

http://lipingshare.com/Asn1Editor/ GUI дампилка; консольная есть asn1parse из openssl

vitus_wagner (not verified) - 18/Мар/2012 16:05

Опенсслевский asn1parse - очень неудобная консольная дампилка; Не показывает отступами уровень вложенности структур; Хороша только двумя вещами
1; Умеет PEM без предварительного base64-декодирования
2 Если есть openssl, то и её asn1parse уже есть.

Если хочется анализировать дамп более чем из трех строчек, лучше брать dumpasn1. (в портах и в Debian-е точно есть, под винду с легкостью собирается);. У него формат вывода куда более удобный, через конфиг настраивается преобразование oid-ов в имена, и еще он умеет после некоторых пинков работать со строками, содержащими нечто отличное от printable .

_slw (not verified) - 15/Мар/2012 12:43

внезапно (не уверен, что влияет, но):

Author: delphij
Date: Wed Mar 14 22:44:56 2012
New Revision: 232990
URL: http://svn.freebsd.org/changeset/base/232990

Log:
Add the missing IPOIB option.

Sponsored by: iXsystems, Inc.
MFC after: 3 days

Modified:
head/sys/conf/options

Modified: head/sys/conf/options
==============================================================================
--- head/sys/conf/options Wed Mar 14 22:30:14 2012 (r232989)
+++ head/sys/conf/options Wed Mar 14 22:44:56 2012 (r232990)
@@ -888,6 +888,7 @@ OFED opt_ofed.h
OFED_DEBUG_INIT opt_ofed.h
SDP opt_ofed.h
SDP_DEBUG opt_ofed.h
+IPOIB opt_ofed.h
IPOIB_DEBUG opt_ofed.h
IPOIB_CM opt_ofed.h

wizzard0 (not verified) - 15/Мар/2012 23:33

> Можно ли для таймстампинга использовать произвольный timestamp сервер?

Вроде, можно. Чтоб проверить наверняка - выключается инет и переводится время (на виртуалке желательно, так можно много чего сломать) на несколько лет вперед.

wizzard0 (not verified) - 15/Мар/2012 23:35

Там еще есть два формата таймстампов, один старый, один новый, как их прикрутить оба - я так и не понял((

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

lexa - 16/Мар/2012 07:31

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