Pull to refresh

Comments 60

UFO just landed and posted this here
Лично я не в курсе этой опции, сейчас ознакомлюсь. Правильно ли я понимаю, что она доступна только для Microsoft Authenticode?
Без таймстампа приложение подписанное при валидном сертификате перестаёт таковым быть после истечения срока сертификата. Что вообще-то не очень хорошо и смысл подписи (под windows) теряется.
Спасибо за полезное дополнение, добавил эту информацию в статью.
Интересные эффекты начинаются, когда кончается срок сертификата, подтверждающего валидность timestamp-а. Тогда система признает подпись валидной или не валидной в зависимости от того, с какой ноги встала.
никогда не было проблем с сертификатами. пользуюсь с 2007 года. это наверно что-то конкретно у вас.
Временная метка — это точно такая же подпись сертификатом, только со стороны сервера времени. У него точно так же есть срок действия. Когда он кончается, что должна сделать система? Ведь срок действия делают не просто так, а в расчете на повышающуюся с каждым днем вероятность влома или кражи. Был реальный прецедент. Не у меня. Я просто констатирую факт.
Мы точно про signing time говорим?
Да, а есть варианты? Дать ссылку на разбор прецедента?
Там таймстампинг есть только у самого дорогого сертификата, сомневаюсь. что использовался именно он:
www.startssl.com/?app=40

Вот у меня файлик 2007 года — всё ок:
image
Походу виноват таки его основной сертификат. Странно то, что валидность потерялась в день потери валидности сертификата таймстампа. И не понятно, чем технически сертификаты с поддержкой таймстампа отличаются от сертификатов без поддержки, кроме цены.
Есть там таймстамп и в тех что за 60$
Ну и что тогда не сработало у него?
Склоняюсь к мысли, что где-то в атрибутах сертификата прописан параметр, который определяет действия системы по окончании срока валидности сертификата времени. Т.е. разрешает таймстампом подписывать(верисайновским или комодовским, потому что на родной его таки не пускает), но не влияет на валидность после окончания срока действия. Информации о том, что StartSSL имеют ввиду под минусом в графе «Time-Stamping extendable» я не нашел.
Спасибо, я как раз там тоже участвовал ;)
Действительно, ну может кого-нибудь ещё заинтересует.
А вам случайно не удалось выяснить, как реализован запрет на timestamping с технической стороны? Насколько я понимаю, его разрешает стандартный OID для подписывания кода, которые присутствует в Class 2 от StartSSL.
С подписью с timestamp есть такой нехороший фактор, что такой сервис предоставляет кажется только verysign, по крайней мере Thawte не предоставлял своего, а направлял использовать verysign. Проблема с verysign в том что сервис работает настабильно, а так как подписывание было прикручено к билд машине, то при ошибке билд падал, пришлось делять танцы с бубном и повторные запросы при ошибке.
Совершенно timestamp есть еще у Comodo.
timestamp.verisign.com/scripts/timstamp.dll
timestamp.comodoca.com/authenticode
timestamp.globalsign.com/scripts/timestamp.dll
tsa.starfieldtech.com

Причем, обращаю внимание, эти серверы можно использовать для подписывания любыми сертификатами (я их в компании использую для подписи скриптов сертификатом, выданным местным CA с самоподписанным сертификатом)
Не знаю как для iOS приложений, но для Mac приложений исспользуется тот-же Microsoft Authenticode и кстати ещё Firefox Addons им можно подписывать.
Сертификат Symantec как-то странно избыточен, учитывая, что сертификаты под Android, iOS, Brew разработчик может бесплатно получить.
А можете дать ссылку на информацию, как разработчики под эти платформы могут получить бесплатные сертификаты?
Сертификаты получают официальные разработчки автоматически когда выставляют свои приложения. То есть, сертификат входит в стоимость подписки разработчиков.
Видимо, речь была про это.
Под Android ты сам себе генерируешь и подписываешь его =)
Под iOS получаешь вместе с подпиской разработчика.
Спасибо, годная табличка.

Подскажите, а есть ли где-нибудь в открытом доступе информация о структуре подписанного .exe файла? Я в целом представляю как с помощью CryptoAPI подписать .exe и проверить цифровую подпись — но что при этом происходит с самим .exe фалом (сертификат в секцию ресурсов записывается, как отдельная секция, просто в конец, еще как-то, где хэш подписанный лежит...) я в гугле беглым поиском не нашел :(.
Вот это увы не подскажу, знаю только что можно, например через PE Explorer просмотреть в ресурсах подпись.
Довольно странно для человека пишущего статьи о code signing.
В случае с code signing я больше занимаюсь их продажей, чем реальным использованием, наша компания ПО не выпускает.
UFO just landed and posted this here
Мы сделали по инструкции о Mozilla и у нас всё заработало. Вот только у Thawte нет своего timestamp сервиса.
4 года назад получал сертификат Microsoft Authenticode Signing у VeriSign (сейчас называется Symantec). Получился целый квест с пересылкой нотариально заверенного перевода с описанием компании и объяснением, почему нет описания компании в желтых страницах интернета. Для американцев желтые страницы очень серьезный аргумент. Теперь каждый год продляю сертификат, это уже намного проще.
Сертификаты удобнее заказывать сразу на максимально возможный срок, если бюджет позволяет. Так и цена минимальная и мороки каждый год с продлением нету. А на счет желтых страниц — сейчас на них уже меньше обращают внимание. К примеру Thawte запрашивают верификацию у какой-то сторонней компании, которая только этим и занимается, а они уже проверяют по своим базам, подозреваю, что по открытым базам официально зарегистрированных фирм.
Thawte уже 12 лет как куплена verisign'ом. Так что тараканы там одинаковые.
Как то жалко отдавать сразу и много. В принципе, оплата за год вполне адекватная.
Может DUNS, а не жёлтые страницы?
Нет, именно в yellow pages раньше проверяли, особенно Thawte.
В желтых именно, я у них в чате спрашивал, на кой им сдались русские желтые страницы, на что получил ответ, что у них за бугром это серьезный каталог, где проверяются данные перед выкладкой, а не как у нас «рекламная песочница» (особенно была раньше).
А объяснений про «большую русскоязычную мусорку» они упорно не поняли?
Кстати, а на сайте Comodo другой список того, что можно сертификатом подписать:
Sign multiple types of code files, including .exe, .msi, .cab, VBA, Java, Adobe AIR, .ocx and .dll files

www.comodo.com/e-commerce/code-signing/code-signing-certificate.php

И кстати вопрос: есть ли корневой сертификат Comodo в Windows XP? Т.е. будет ли корректно работать подпись на старых ОС без обновлений и сервиспаков?
И еще в догонку вопрос. Учитывают ли как-то антивирусы, что программа подписана сертификатом?
Такими сведениями не обладаем. Думаю логично было бы учитывать.
Список для comodo в табличке поправили, спасибо.

Проверили на последнем компе с win xp, который у нас остался, сертификаты выданные comodo видит нормально.
Хороший цикл статей, жду продолжения :)
Хотелось бы узнать: можно ли, имея CSR, узнать какой тип сертификата я получу? SSL, SMIME или Code Sign сертификат?
Статьи по каким темам вам были бы интересны?
Ваш вопрос несколько некорректен, так как тип сертификаты выбирается в зависимости от потребностей, а не от CSR подписи.
Интересно по S/MIME сертификатам :)

Да, сертификат выбирается в зависимости от потребностей. Но просто интересно можно ли определить тип сертификата основываясь на CSR? Есть ли какие-то признаки явно указывающие, что этот CSR для выписки SSL сертификата, а вот этот CSR для выписки S/MIME.
Интересно какой сертификат нужен для настройки радиус-сервера, который будет аутентифицировать абонентов подключающихся к Wi-Fi точке доступа (протокол EAP-TLS). Как его сгенерировать и у кого подписать?
support.microsoft.com/kb/814394
В доменной среде все делается весьма просто — достаточно типовых сертификатов User на пользователя, Computer — на клиентские компьютеры и серверы RADIUS.
При наличии AD Cerificate Services и Network Policy Server все делается достаточно просто

Перед всей свистопляской очень рекоммендую прочитать Windows Server 2008 PKI and certificate security от Brian Komar. Купить ее почти нереально, но есть в PDF.

Если вкратце — то нужен сертификат с EKU OID Client Authentication И Server Authentication.
Для WIndows 8008 R2 потребуется переделать шаблон, так как «по-умолчанию» там шаблоны сертификатов User и Computer версии 1, которые не поддерживают AutoEnrollment (автообновление \ авторазвертывание)
А про «у кого подписать» — при развертывании ADCS вам просто нужно распространить сертификат своего CA (он скорее всего будет самоподписанный) на компьютеры клиентов политикой.

можно ли каким-то образом избавиться от обращений к серверу globalsign при проверке сертификата приложения? или clr в любом случае будет обновляться с сервера с определенной периодичностью?

Либо отключить проверку CRL, что "ломает" всю концепцию, либо все нужные CRL регулярно скачивать и устанавливать (как-то в обход) на обращающуюся систему (у CRL также есть даты начала и конца)

https://www.ibm.com/support/pages/how-disable-check-publisher’s-certificate-revocation

Sign up to leave a comment.