1. Для .NET сборок надо различать собственно strong name key (достаточно пары ключей) и Authenticode/подписывание манифеста/подпись инсталлера (желателен X.509 сертификат). Первое предназначено для того чтобы отличить одну сборку от другой, второе — чтобы с определённой долей вероятности указать издателя (или того кто украл приватный ключ).
2. Если пара ключей для strong name key берётся из сертификата (pfx-файла), никакой дополнительной информации (кому выдан сертификат и т.п.) в сборку не вносится. Как бы очевидно, уточняю на всякий. Таким образом, если я хочу чтобы мою сборку не спутали с аналогичной от другого издателя, достаточно сгенерить пару ключей, спрятать private key подольше и не заморачиваться с получением сертификата/его продлением.
3. Если всё-таки требуется подтверждение факта, что код издал именно я, то сборка должна быть подписана сертификатом, CA которого должен входить в список TrustedCA на компьютере клиента. Это может быть достигнуто 3мя способами (последние 2 только для корпоративной сети):
3.1. Получить сертификат у поставщика, заключившего соглашение с МС о выдаче сертификатов для code signing.
3.2. Windows Certificate Services.
3.3. Абсолютный хардкор: самостоятельно сгенерить всю цепочку "корневой сертификат — сертификаты для подписи определённых типов сертификатов — конечные сертификаты" и установить корневой сертификат либо как trusted ca домена, либо на каждый пользовательский компьютер (ручками или ч/з политики).
4. Полученный сертификат надо регулярно обновлять — даже если он будет скомпрометирован, это обнаружится при следующем обновлении.
4.1. Обновление заключается в изменении подписи сертификата (ключи остаются прежними), или сертификат заменяется целиком?
4.2. Требуются ли какие-либо действия на компьютерах пользователей после обновления сертификата?
5. В любом случае, полученный сертификат следует использовать только для подписи кода, надо шифровать трафик/подписывать почту/документы — желательно получить другие сертификаты, с правами только на соответствующий тип подписи.
Если кто-то может проконсультировать по пунктам 3.2. и 3.3. — отпишитесь пожалуйста, есть ещё несколько вопросов.
Здравствуйте, Sinix, Вы писали:
S>Если кто-то может проконсультировать по пунктам 3.2. и 3.3. — отпишитесь пожалуйста, есть ещё несколько вопросов.
S>Спасибо!
Ну ты это — задавай вопросы-то. 3.3 не пробовал (ибо незачем), а вот по 3.2 могу подсказать...
По имеющимся вопросам:
4. Для этого каждым СА поддерживается CRL — certificate revocation list. СА сервак в составе WinServer Standart+ так же имеет CRL, который автоматически накатывается на мемберы домена(ов).
4.1. Сертификат заменяется целиком
4.2. Нет, проверяется валидность сертификата на момент подписи — если сертификат позже истёк, то подпись всё равно считается валидной. Потому истёкший сертификат, и отозванный — разные вещи, ибо во втором случае все подписи, сделанные с его помощью, считаются невалидными.
5. Технически возможно сделать сертификат "для всего", но тут ты прав и лучше так не делать.
Да, кстати способ 3.2 можно использовать по тому же принципу, что и 3.3 — только надо будет добавить сертификат СА в список доверенных (в мемберах домена это делается автоматически). Таким образом, 3.2 можно рассматривать как частный случай 3.3.
Не поручусь за 100% верность вышесказанного (пишу по памяти) — но вроде так...
Здравствуйте, koandrew!
K>Ну ты это — задавай вопросы-то. 3.3 не пробовал (ибо незачем), а вот по 3.2 могу подсказать...
Ок. Заранее извиняюсь за наивность вопросов, серьёзно в тему ещё не забурился.
1. Не было проблем с валидностью X.509 сертификатов?
2. Насколько активно сервис участвует в жизненном цикле сгенеренного сертификата? Не, интуитивно понятно: получил сертификат — свободен. Не будет ли проблем, если цепочку сертификатов желательно использовать в нескольких несвязанных доменах? Что-то в памяти крутится что для генерации Certificate Service использует самостоятельно сгенерированный сертификат и подменить его — ни-ни.
Причём откуда я это взял —
3. Не слишком ли избыточно использовать сервис только для генерации трёх-пяти сертификатов (хотя, тут стоит поднять, желающие попользовать найдутся)
4. Как там с пользовательским интерфейсом + насколько нужно углубляться в спецификацию X.509 для "правильного" создания сертификата?
Пока цель стоит получить code signing сертификат и посмотреть что с ним можно сделать. Плюс задел на будущее — чтобы потом по возможности легко нагенерить кучу сертификатов для подписи доументов/шифрования трафика/СУБД и т.п.
K>По имеющимся вопросам: K>4.1. Сертификат заменяется целиком
Таак... т.е. если планируется внедрить какие-то политики на базе сертификатов, придётся их переиодически изменять из-за изменения публичного ключа сертификата? Нет ли такого понятия как "переподписанный сертификат"?
K>4.2. Нет, проверяется валидность сертификата на момент подписи — если сертификат позже истёк, то подпись всё равно считается валидной. Потому истёкший сертификат, и отозванный — разные вещи, ибо во втором случае все подписи, сделанные с его помощью, считаются невалидными.
Здравствуйте, Sinix, Вы писали:
S>Ок. Заранее извиняюсь за наивность вопросов, серьёзно в тему ещё не забурился.
Да я тоже, в общем-то, далёк от того, чтобы быть профи в этом вопросе...
Сразу скажу — всё нижесказанное относится к Certificate service Win2008 Std, на которой я, собственно, и "ставил опыты"
S>1. Не было проблем с валидностью X.509 сертификатов?
Не понял вопроса S>2. Насколько активно сервис участвует в жизненном цикле сгенеренного сертификата? Не, интуитивно понятно: получил сертификат — свободен.
Участие сервиса ограничивается поддержкой CRL. S>Не будет ли проблем, если цепочку сертификатов желательно использовать в нескольких несвязанных доменах? Что-то в памяти крутится что для генерации Certificate Service использует самостоятельно сгенерированный сертификат и подменить его — ни-ни. S>Причём откуда я это взял —
При установке служб ЦС вроде бы имеется возможность указать сертификат. Но имейте в виду, что имя сертификата (точнее, его атрибут Subject) намертво привязывается к DNS-имени сервера. Но ничто не мешает на корневом ЦС сгенерить сертификаты для дочерних. Кстати, имейте в виду, что после установки служб ЦС изменить DNS-имя машины будет невозможно — так что утрясите этот вопрос перед установкой.
S>3. Не слишком ли избыточно использовать сервис только для генерации трёх-пяти сертификатов (хотя, тут стоит поднять, желающие попользовать найдутся)
Ну хлеба он вроде бы не просит
S>4. Как там с пользовательским интерфейсом + насколько нужно углубляться в спецификацию X.509 для "правильного" создания сертификата? S>Пока цель стоит получить code signing сертификат и посмотреть что с ним можно сделать. Плюс задел на будущее — чтобы потом по возможности легко нагенерить кучу сертификатов для подписи доументов/шифрования трафика/СУБД и т.п.
К сожалению, здесь, как и во всём связанным с безопасностью и криптографией, всё довольно непросто, и поизучать теорию стоило бы... Но я ниже попробую изложить абсолютный минимум знаний, который позволит вам выполнить задачу.
K>>По имеющимся вопросам: K>>4.1. Сертификат заменяется целиком S>Таак... т.е. если планируется внедрить какие-то политики на базе сертификатов, придётся их переиодически изменять из-за изменения публичного ключа сертификата? Нет ли такого понятия как "переподписанный сертификат"?
Пока сертификат ещё валиден, его можно обновить, при этом в новый сертификат вставляется thumbprint обновляемого сертификата. Истёкшие сертификаты можно только заменить полностью.
Теперь немного теории...
Сертификат по сути представляет из себя контейнер для атрибутов, которые собственно и содержат полезную нагрузку. Каждый атрибут однозначно определяется OID (Object ID). Некоторые примеры OID можно посмотреть тут: http://support.microsoft.com/?id=287547. Совокупность этих атрибутов и образуют сертификат. В процессе создания сертификата эти данные подписываются с помощью закрытого ключа ЦС. Важно понимать, что закрытый ключ не является частью сертификата и хранится в контейнере ключей, будучи защищён с помощью DPAPI, что исключает компрометацию ключа простым копированием БД сертификатов. Его можно экспортировать/импортировать только в специальный формат, защищённый паролем, так что задача незаконного завладения закрытым ключём осложнена чисто технически. Более того, ключ можно пометить как неэкспортируемый, тогда достать его будет совсем невозможно...
Достаточно, перейдём к практике. В ЦС имеется шаблон CodeSigning, который, в принципе, вам подойдёт. Только в качестве Subject (то, что увидит юзер в поле Publisher) будет полное AD-имя юзера, от которого делается запрос. Итак, поехали.
1. Создаём inf-файл политики со следующим содержанием:
. После успешного выполнения мы получим файл запроса <имя_файла_запроса.req>, и в контейнере текущего юзера будет сгенерирован закрытый ключ.
3. Выполняем команду:
Последний параметр не обязателен. В процессе вас попросят выбрать ЦС, на который будем отправлять запрос. На выходе мы получим файл сертификата *.cer.
4. Импортируем этот сертификат в хранилище с настройками по умолчанию.
Важно всю вышеуказанную последовательность действий выполнять на одной и той же машине.
В принципе, сертификат готов к применению, но для переноса его на другую машину его нужно экспортировать.
5. Открываем certmgr.msc и находим сертификат (он будет в Certificates — Current User/Personal/Certificates). В контекстном меню выбираем
"Export", указываем, что хотим экспортировать закрытый ключ, остальные параметры — по вкусу и необходимости (например, если вам нужно будет использовать сертификат на машине, не входящей в домен, но надо будет экспортировать всю цепочку). В процессе запросят пароль. Забывать его крайне не рекомендуется
6. Переносим полученный pfx-файл на целевую машину и импортируем его в хранилище (последнее строго говоря необязательно, но очень удобно).
Всё, мы готовы к работе.
Процесс подписи вообще прост. Открываем .NET FW SDK command prompt и вводим команду signtool signwizard. Откроется визард, с помощью которого вы элементарно завершите процесс. Настоятельно рекомендуется использовать timestamp server. Я использую http://timestamp.comodoca.com/authenticode и вам его рекомендую. Его использование абсолютно бесплатно, и нигде регистрироваться не нужно.
Всё, дело сделано
Здравствуйте, koandrew, Вы писали:
S>>1. Не было проблем с валидностью X.509 сертификатов? K>Не понял вопроса
Перефразирую: не генерятся ли серитфикаты таким образом, что всякие third-party скажут: "а что это такое???".
*уже отпал в связи с разжёвыванием процесса генерации.
K>При установке служб ЦС вроде бы имеется возможность указать сертификат. Но имейте в виду, что имя сертификата (точнее, его атрибут Subject) намертво привязывается к DNS-имени сервера. Но ничто не мешает на корневом ЦС сгенерить сертификаты для дочерних. Кстати, имейте в виду, что после установки служб ЦС изменить DNS-имя машины будет невозможно — так что утрясите этот вопрос перед установкой.
Ага-ага... похоже, что про это я и пытался вспомнить. Проблема: домены физически изолированы. С другой стороны — какая разница что там написано, пока сертификат для внутреннего применения?
K>Совокупность этих атрибутов и образуют сертификат. В процессе создания сертификата эти данные подписываются с помощью закрытого ключа ЦС.
Х-ммм... А разве каждый сертификат не включает в себя ещё и уникальную пару ключей (или, как вариант, только открытый ключ)??? Почему-то казалось, что ЦС генерит самоподписанный сертификат (или использует готовый) и подписывает выдаваемые сертификаты им (и так по цепочке).
K><имя_файла_цепочки_сертификатов.p7b>
Я так понимаю, без этого файла сведения о цепочке подписей не будут внесены в сертификат, и если у нас цепочка "корневой сертификат-сертификат для выдачи code-signing сертификатов-code-signing сертификат", то внесение корневого сертификата в trusted CA будет недостаточно?
K>Настоятельно рекомендуется использовать timestamp server. Я использую http://timestamp.comodoca.com/authenticode и вам его рекомендую. Его использование абсолютно бесплатно, и нигде регистрироваться не нужно. K>Всё, дело сделано
1. Timestamp — чтобы не было вопросов насчёт валидности даты подписания?
1.1. Его надо использовать только для подписи кода, или ещё и при генерации сертификатов?
2. Стоит ли использовать пару ключей из сертификата как strong name keys сборки? Или сгенерить 2 сертификата: 1 для snk pair, другой для authenticode ? (на мой взгляд — избыточно)
3. Какой алгоритм хэширования/длину ключа стоит выставить? (с учётом, что сертификат может использоваться сторонними инструментами)
4. Есть ли аналоги ms certificate services, или какие-либо инструменты облегчающие генерацию цепочки сертификатов?
Здравствуйте, Sinix, Вы писали:
S>Ага-ага... похоже, что про это я и пытался вспомнить. Проблема: домены физически изолированы. С другой стороны — какая разница что там написано, пока сертификат для внутреннего применения?
А какая, собственно, разница?
K>>Совокупность этих атрибутов и образуют сертификат. В процессе создания сертификата эти данные подписываются с помощью закрытого ключа ЦС. S>Х-ммм... А разве каждый сертификат не включает в себя ещё и уникальную пару ключей (или, как вариант, только открытый ключ)??? Почему-то казалось, что ЦС генерит самоподписанный сертификат (или использует готовый) и подписывает выдаваемые сертификаты им (и так по цепочке).
Открытый ключ включён в сертификат как один из атрибутов. Приватный ключ хранится отдельно, за исключением случая экспорта. ЦС подписывает сертификаты не "сертификатом" (это невозможно, ибо в нём нет приватного ключа), а соответствующим сертификату приватным ключом.
S>Я так понимаю, без этого файла сведения о цепочке подписей не будут внесены в сертификат, и если у нас цепочка "корневой сертификат-сертификат для выдачи code-signing сертификатов-code-signing сертификат", то внесение корневого сертификата в trusted CA будет недостаточно?
Нет, сведения о том, кто выдал сертификат, хранятся в сертификате (один уровень), но при экспорте сертификата и при подписи можно специально указать, чтобы включалась вся цепочка.
S>1. Timestamp — чтобы не было вопросов насчёт валидности даты подписания?
Да
S>1.1. Его надо использовать только для подписи кода, или ещё и при генерации сертификатов?
Первое. S>2. Стоит ли использовать пару ключей из сертификата как strong name keys сборки? Или сгенерить 2 сертификата: 1 для snk pair, другой для authenticode ? (на мой взгляд — избыточно)
Мы используем разные. Для strong name — обычный snk, для подписи — сертификат. Потому как при компрометации snk (например, при привлечении к проекту оказавшихся не очень чистоплотными фрилансеров) по большому счёту ничего особенного не происходит (ибо snk не содержит никаких сведений о его владельце), в то время как компрометация сертификата — вещь оооочень неприятная, ибо влечёт за собой его отзыв со всем сопутствующим гемором по ре-подписи, ре-паблишингу и редеплойменту всего им подписанного.
S>3. Какой алгоритм хэширования/длину ключа стоит выставить? (с учётом, что сертификат может использоваться сторонними инструментами)
Какую надо — такую и ставьте. Список поддерживаемых ЦС довольно широк. Тока учтите, что машина, на которой эта подпись будет проверяться, также должна иметь используемого провайдера и поддерживать используемую длину ключа (см в МСДНе по поводу поддерки). S>4. Есть ли аналоги ms certificate services, или какие-либо инструменты облегчающие генерацию цепочки сертификатов?
Не знаю, ибо мне хватает МСовских Кстати, в комлекте с виндой идёт веб-морда к ЦС, которую очень удобно юзать для генерации запросов и установки сертификатов прямо из браузера (IE-only).
S>Огромное спасибо за ссылки и разьяснение!
You are welcome!
Здравствуйте, Sinix, Вы писали:
S>Ага-ага... похоже, что про это я и пытался вспомнить. Проблема: домены физически изолированы. С другой стороны — какая разница что там написано, пока сертификат для внутреннего применения?
Конкретно по этому вопросу наверняка подсказать я тебе не смогу — ибо самому не доводилось такое делать. Посему предлагаю тебе задать этот вопрос в "Администрировании..." — вроде там у нас обитают бородатые дядьки
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sinix, Вы писали:
S>>какая разница что там написано, пока сертификат для внутреннего применения? K>А какая, собственно, разница?
Вот и я о том же%)
K>Нет, сведения о том, кто выдал сертификат, хранятся в сертификате (один уровень), но при экспорте сертификата и при подписи можно специально указать, чтобы включалась вся цепочка.
А зачем тогда нужен <имя_файла_цепочки_сертификатов.p7b>?
По остальному вопросов пока нет. Ещё раз огрромное спасибо!
Здравствуйте, Sinix, Вы писали:
S>А зачем тогда нужен <имя_файла_цепочки_сертификатов.p7b>?
Это выходной файл, в который будут помещены все сертификаты в цепочке до генерируемого. Потому этот параметр и не обязателен.
S>По остальному вопросов пока нет. Ещё раз огрромное спасибо!
Ну и отлично Ты лучше начни это дело пробовать — тогда проще будет, и на большую часть заданных тут вопросов ты сам найдёшь ответы. Просто нужно понять логику этой кухни — тогда всё будет понятно и очевидно...
В ЦС имеется шаблон CodeSigning, который, в принципе, вам подойдёт. Только в качестве Subject (то, что увидит юзер в поле Publisher) будет полное AD-имя юзера, от которого делается запрос. Итак, поехали.
