Большинству администраторов Windows, знакомых с темой PKI, известна утилита MakeCert.exe, с помощью которой можно создать самоподписанный сертификат. Эта утилита включена в состав Microsoft .NET Framework SDK и Microsoft Windows SDK. В современных версиях Windows 11/10/8.1 и Windows Server 2022/2019/2016/2012R2 вы можете создать самоподписанный сертификат с помощью встроенных командлетов PowerShell без использования дополнительных утилит.
Создать самоподписанный SSL сертификат в PowerShell
Для создания самоподписанного сертификата в PowerShell нужно использовать командлет New-SelfSignedCertificate, входящий в состав модуля PKI (Public Key Infrastructure).
Чтобы вывести список всех доступных командлетов в модуле PKI, выполните команду:
Get-Command -Module PKI
Самоподписанные SSL сертификаты рекомендуется использовать в тестовых целях или для обеспечения сертификатами внутренних интранет служб (IIS, Exchange, Web Application Proxy, LDAPS, ADRMS, DirectAccess и т.п.), в тех случая когда по какой-то причине приобретение сертификата у внешнего провайдера или разворачивание инфраструктуры PKI/CA невозможны.
Совет. Не забывайте, что вы можете использования полноценные бесплатные SSL сертификаты от Let’s Encrypt. Например, вы можете SSL сертификат Let’s Encrypt и привязать его к сайту IIS.
Для создания сертификата нужно указать значения -DnsName (DNS имя сервера, имя может быть произвольным и отличаться от имени localhost) и -CertStoreLocation (раздел локального хранилища сертификатов, в который будет помещен сгенерированный сертификат).
Чтобы создать новый SSL сертификат для DNS имени test.contoso.com (указывается FQDN имя) и поместить его в список персональных сертификатов компьютера, выполните команду:
New-SelfSignedCertificate -DnsName test.contoso.com -CertStoreLocation cert:\LocalMachine\My
Команда вернет отпечаток нового сертификата (Thumbprint), Subject и EnhancedKeyUsageList. По умолчанию такой сертификат можно использовать для аутентификации клиента Client Authentication (1.3.6.1.5.5.7.3.2) или сервера Server Authentication (1.3.6.1.5.5.7.3.1).
Если вы запустите эту команду в PowerShell без прав администратор, появится ошибка:
New-SelfSignedCertificate : CertEnroll::CX509Enrollment::_CreateRequest: Access denied. 0x80090010 (-2146893808 NTE_PERM)
Если вы указали нестандартный криптографический провайдер CSPs (например, с помощью параметров
-KeyAlgorithm "ECDSA_secP256r1" -Provider 'Microsoft Smart Card Key Storage Provider'
), убедитесь, что он установлен на компьютере (по умолчанию используется CSP Microsoft Enhanced Cryptographic Provider). Иначе появится ошибка:
New-SelfSignedCertificate: CertEnroll::CX509Enrollment::_CreateRequest: Provider type not defined. 0x80090017 (-2146893801 NTE_PROV_TYPE_NOT_DEF).
По-умолчанию генерируется самоподписанный сертификат со следующим параметрами:
- Криптографический алгоритм: RSA;
- Размер ключа: 2048 бит;
- Допустимые варианты использования ключа: Client Authentication и Server Authentication;
- Сертификат может использоваться для: Digital Signature, Key Encipherment ;
- Срок действия сертификата: 1 год.
- Криптопровадер: Microsoft Software Key Storage Provider
Данная команда создаст новый сертификат и импортирует его в персональное хранилище компьютера. Откройте оснастку certlm.msc и проверьте, что в разделе Personal хранилища сертификатов компьютера появился новый сертификат.
С помощью командлета Get-ChildItem можно вывести все параметры созданного сертификата по его отпечатку (Thumbprint):
PSPath : Microsoft.PowerShell.Security\Certificate::LocalMachine\My\76360EAA92D958ECF2717261F75D426E6 DB5B4D1 PSParentPath : Microsoft.PowerShell.Security\Certificate::LocalMachine\My PSChildName : 76360EAA92D958ECF2717261F75D426E6DB5B4D1 PSDrive : Cert PSProvider : Microsoft.PowerShell.Security\Certificate PSIsContainer : False EnhancedKeyUsageList : {Client Authentication (1.3.6.1.5.5.7.3.2), Server Authentication (1.3.6.1.5.5.7.3.1)} DnsNameList : {test.contoso.com} SendAsTrustedIssuer : False EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty PolicyId : Archived : False Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid} FriendlyName : HasPrivateKey : True PrivateKey : System.Security.Cryptography.RSACng IssuerName : System.Security.Cryptography.X509Certificates.X500DistinguishedName NotAfter : 12/2/2023 3:41:18 PM NotBefore : 12/2/2022 3:21:18 PM PublicKey : System.Security.Cryptography.X509Certificates.PublicKey RawData : {48, 130, 3, 45…} SerialNumber : 24682351DA9C59874573BA2B5BB39874 SignatureAlgorithm : System.Security.Cryptography.Oid SubjectName : System.Security.Cryptography.X509Certificates.X500DistinguishedName Thumbprint : 76360EAA92D958ECF2717261F75D426E6DB5B4D1 Version : 3 Handle : 2007435579936 Issuer : CN=test.contoso.com Subject : CN=test.contoso.com
Примечание. Срок действия такого самоподписанного сертификата истекает через 1 год с момента его создания. Можно задать другой срок действия сертификата с помощью атрибута —NotAfter.Чтобы выпустить сертификат на 3 года, выполните следующие команды:
$todaydate = Get-Date
$add3year = $todaydate.AddYears(3)
New-SelfSignedCertificate -dnsname test.contoso.com -notafter $add3year -CertStoreLocation cert:\LocalMachine\My
Можно создать цепочку сертификатов. Сначала создается корневой сертификат (CA), а на основании него генерируется SSL сертификат сервера:
$rootCert = New-SelfSignedCertificate -Subject "CN=TestRootCA,O=TestRootCA,OU=TestRootCA" -KeyExportPolicy Exportable -KeyUsage CertSign,CRLSign,DigitalSignature -KeyLength 2048 -KeyUsageProperty All -KeyAlgorithm 'RSA' -HashAlgorithm 'SHA256' -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider"
New-SelfSignedCertificate -CertStoreLocation cert:\LocalMachine\My -DnsName "test2.contoso.com" -Signer $rootCert -KeyUsage KeyEncipherment,DigitalSignature
Чтобы изменить длину ключа сертификата и алгоритм шифрования, нужно использовать параметры
–KeyAlgorithm
,
–KeyLength
и
–HashAlgorithm
. Например:
New-SelfSignedCertificate -KeyAlgorithm RSA -KeyLength 2048 -HashAlgorithm "SHA256"
Если на компьютере доступен модуль TPM 2.0, можно использовать его для защиты ключа:
Как сгенерировать SAN (SubjectAltName) сертификат с помощью PowerShell?
Командлет New-SelfSignedCertificate позволяет создать сертификат с несколькими различными именами Subject Alternative Names (SAN).
Примечание. Утилита Makecert.exe, в отличии от командлета New-SelfSignedCertificate, не умеет создавать сертификаты с SAN.
Если создается сертификат с несколькими именами, первое имя в параметре DnsName будет использоваться в качестве CN (Common Name) сертификата. К примеру, создадим сертификат, у которого указаны следующие имена:
- Subject Name (CN): adfs1.contoso.com
- Subject Alternative Name (DNS): web-gw.contoso.com
- Subject Alternative Name (DNS): enterprise-reg.contoso.com
Команда создания сертификата будет такой:
New-SelfSignedCertificate -DnsName adfs1.contoso.com,web_gw.contoso.com,enterprise_reg.contoso.com -CertStoreLocation cert:\LocalMachine\My
Также можно сгенерировать wildcard сертификат для всего пространства имен домена, для этого в качестве имени сервера указывается *.contoso.com.
New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname *.contoso.com
Вы можете привязать сертификат не только к DNS имени, но и к IP адресу. Для этого вместе параметр -DnsName нужно использовать -TextExtension. Например:
Как вы видите, в поле Subject Alternative Name теперь содержится IP адрес.
Экспорт самоподписаного сертификата в Windows
Для экспорта полученного сертификата c закрытым ключом в pfx файл, защищенный паролем, нужно получить его отпечаток (Thumbprint). Сначала нужно указать пароль защиты сертификата и преобразовать его в формат SecureString. Значение Thumbprint нужно скопировать из результатов выполнения команды New-SelfSignedCertificate.
$CertPassword = ConvertTo-SecureString -String “YourPassword” -Force –AsPlainText
Export-PfxCertificate -Cert cert:\LocalMachine\My\2779C0490D558B31AAA0CEF2F6EB1A5C2CA83B30 -FilePath C:\test.pfx -Password $CertPassword
Можно экспортировать открытый ключ сертификата:
Export-Certificate -Cert Cert:\LocalMachine\My\2779C0490D558B31AAA0CEF2F6EB1A5C2CA83B30 -FilePath C:\testcert.cer
Проверьте, что в указанном каталоге появился CER (PFX) файл сертификата. Если щелкнуть по нему правой клавишей и выбрать пункт меню Install Certificate, можно с помощью мастера импорта сертификатов добавить сертификат в корневые доверенные сертификаты компьютера.
Полученный открытый ключ или сам файл сертификата можно распространить на все компьютеры и сервера в домене с помощью GPO (пример установки сертификата на компьютеры с помощью групповых политик).
Сгенерировать сертификат для подписи кода типа Code Signing
В PoweShell 3.0 командлет New-SelfSifgnedCertificate позволял генерировать только SSL сертификаты, которые нельзя было использоваться для подписывания кода драйверов и приложений (в отличии сертификатов, генерируемых утилитой MakeCert).
В версии PowerShell 5 командлет New-SelfSifgnedCertificate теперь можно использовать чтобы выпустить сертификат типа Code Signing.
Вы можете обновить версию PowerShell согласно инструкции.
Для создания самоподписанного сертфиката для подписывания кода приложений, выполните команду:
$cert = New-SelfSignedCertificate -Subject "Cert for Code Signing” -Type CodeSigningCert -CertStoreLocation cert:\LocalMachine\My
Теперь можно подписать ваш PowerShell скрипт эти сертификатом:
Set-AuthenticodeSignature -FilePath C:\PS\test_script.ps1 -Certificate $cert
Если при выполнении команды появится предупреждение UnknownError, значит этот сертификат недоверенный, т.к. находится в персональном хранилище сертификатов пользователя.
Нужно переместить его в корневые сертификаты (не забывайте периодически проверять хранилище сертификатов Windows на наличие недоверенных сертфикатов и обновлять списки корневых сертификатов):
Теперь вы можете использовать этот самоподписанный сертификат для подписи PowerShell скриптов, драйверов или приложений.
Создать самоподписанный SSL сертификат SHA-256 для IIS
Обратите внимание, что при создании самоподписанный сертификат для IIS через консоль Internet Information Manager (пункт меню Create Self-Signed Certificate), создается сертификат с использованием алгоритма шифрования SHA-1. Такие сертификаты многими браузерами считаются недоверенными, поэтому они могут выдавать предупреждение о небезопасном подключении. Командлет New-SelfSignedCertificate позволяет создать более популярный тип сертификата с помощью алгоритма шифрования SHA-256.
Вы можете привязать самоподписанный сертификат SHA-256, созданный в PowerShell, к сайту IIS. Если вы с помощью PowerShell создали SSL сертификат и поместили его в хранилище сертификатов компьютера, он будет автоматически доступен для сайтов IIS.
Запустите консоль IIS Manager, выберите ваш сайт, затем в настройке Site Binding, выберите созданный вами сертификат и сохраните изменения.
Также можно привязать SSL сертификат к сайту IIS по его отпечатку:
New-IISSiteBinding -Name "Default Web Site" -BindingInformation "*:443:" -CertificateThumbPrint $yourCert.Thumbprint -CertStoreLocation "Cert:\LocalMachine\My" -Protocol https
Code Signing в Windows, просто и недорого
Хотел бы рассказать тут о такой важной особенности разработки под Windows как Code Signing. А ведь многие достаточно серьёзные разработчики до сих пор ей не пользуются, и очень зря. Помимо того что при запуске вашего неподписанного приложения появляется противная красная иконка с крестом и неприятным текстом:
«Этот файл не имеет цифровой подписи которая может подтвердить производителя. Вы должны запускать программы только от производителей которым доверяете.»
Это ещё и пропуск на корпоративный рынок.
При запуске неподписанной программы появляется такое окно:
А так выглядит окно когда программа подписана:
Один важный момент, прежде чем получать сертификат, очень желательно зарегистрировать вашу компанию или ИП в агенстве Dun & Bradstreet и получить DUNS номер. Этот номер очень уважается компаниями которые выдают сертификаты и при предъявлении этого номера, в абсолютном большинстве случаев, более никаких подтверждающих документов не спрашивают. Иначе придётся высылать сканы уставных документов, а иногда и каких-нибудь счетов на компанию, например за телефон. Для получения сертификата на ИП это один из главных шагов. Без этого в случае ИП может вообще ничего не получиться.
Сам процесс подписания программы/инсталлятора достаточно простой и легко автоматизируется, если надо могу описать и его.
Вот собственно и всё. Если вы работаете на рынке программного обеспечения для windows — сертификат это важная и необходимая вещь. Я надо признать и сам стал избегать неподписанных программ после этого.
Подписывание пакета приложения Windows 10
Подписывание пакета приложения — это обязательный шаг в процессе создания развертываемых пакетов приложений Windows 10. В Windows 10 все приложения должны быть подписаны с помощью допустимого сертификата для подписи кода.
Для успешной установки приложения для Windows 10 пакет не только подписывается, но и настраивается как надежный на устройстве. Это означает, что сертификат должен быть связан с одним из доверенных корневых сертификатов на устройстве. По умолчанию в Windows 10 настроено доверие к сертификатам от большинства центров сертификации, предоставляющих сертификаты для подписи кода.
Установка меток времени
Настоятельно рекомендуется использовать метки времени при подписывании приложения с помощью сертификата. Это действие сохраняет подпись, обеспечивая принятие пакета приложений платформой развертывания приложения, даже если срок действия сертификата истек. Во время проверки пакета метка времени позволяет проверить подпись пакета с учетом времени подписывания. Такие пакеты будут приняты, даже если сертификат недействителен. Пакеты без меток времени будут проверяться с учетом текущего времени и, если сертификат недействителен, Windows не примет такой пакет.
Ниже описаны разные сценарии подписывания приложения с использованием меток времени и без них.
Если приложение установлено на устройстве, оно будет выполняться даже после истечения срока действия сертификата независимо от того, были ли установлены метки.
Режим устройства
Windows 10 позволяет пользователям выбирать следующие режимы работы устройства в настройках приложения: «Приложения Microsoft Store», «Неопубликованные приложения» и «Режим разработчика».
Приложения Microsoft Store — это самый безопасный режим, так как он разрешает установку приложений только из Microsoft Store. Приложения в Microsoft Store проходят процесс сертификации, гарантирующий, что приложения безопасны для использования.
Неопубликованные приложения и Режим разработчика — это менее строгие режимы использования приложений, которые были подписаны с помощью других сертификатов, которые являются доверенными и которые связаны с одним из доверенных корневых сертификатов на устройстве. Выбирайте режим разработчика, только если вы являетесь разработчиком, который создает или отлаживает приложения для Windows 10. См. подробнее о режиме разработчика.
Цифровые подписи в исполняемых файлах и обход этой защиты во вредоносных программах
Ну вроде как удалось решить вопросы с кармой, но они ником образом не касаются сегодняшней темы, а лишь объясняют некоторое опоздание её выхода на свет (исходные планы были на ноябрь прошлого года).
Сегодня я предлагаю Вашему вниманию небольшой обзор по системе электронных подписей исполняемых файлов и способам обхода и фальсификации этой системы. Также будет рассмотрен в деталях один из весьма действенных способов обхода. Несмотря на то, что описываемой инфе уже несколько месяцев, знают о ней не все. Производители описываемых ниже продуктов были уведомлены об описываемом материале, так что решение этой проблемы, если они вообще считают это проблемой, на их ответственности. Потому как времени было предостаточно.
Идея и технология электронной подписи для исполняемых файлов возникла ещё в эпоху Windows NT. C момента появления Windows Vista компания Microsoft начала активную компанию по продвижению этой технологии. По задумке производителя, подписанный код может идти только от доверенного автора этого кода, а следовательно гарантированно не наносит вреда системе и защищён от ошибок (три ха-ха).
Тем не менее, поскольку в механизме подписи чаще всего используется довольно сложный криптоустойчивый механизм, общее доверие к подписанному коду распространилось. Не ушли от этого и антивирусные вендоры. Верно: если код подписан, то он явно не может быть вирусом, а потому ему можно доверять априори, тем самым снизив вероятность ложных срабатываний. Поэтому в большинстве современных антивирусных продуктов по умолчанию стоит обход проверки подписанных файлов, что повышает скорость сканирования и снижает вероятность ложных срабатываний. Более того, зачастую подписанные программы автоматически заносятся в категорию «доверенных» поведенческих анализаторов ака хипсов.
Становится ясно, что подписав свои творения валидной подписью, вирусмейкер получает довольно богатую аудиторию клиентов, у которых даже с активным и регулярно обновляемым антивирусом произойдёт заражение. Очевидно, что это — весьма лакомый кусочек, что легко заметно на примере уже ставшего знаменитым вируса Stuxnet, где код был подписан валидными сертификатами Realtek (позже сообщалось и о подписях от JMicron).
Но у этого подхода есть и оборотная сторона: после выявления скомпрометированной подписи она немедленно отзывается, а по самому факту подписи АВ-вендоры ставят сигнатурный детект, понятно, что с 100%-ным срабатыванием. Учитывая то, что приобрести украденный сертификат, необходимый для подписывания крайне дорого, ясно, что вирусмейкеры заинтересованы в тотальном обходе механизма проверки подписи, без валидных private-ключей или с помощью самостоятельной генерации таких ключей. Это позволит обходить защиту не только антивирусных продуктов, но и устанавливать драйвера и ActiveX-компоненты без предупреждений, да и вообще как-то пробиться в мир х64, где без подписей ничего не установить вообще.
Но об этом — подробнее на практике.
Кто-то из великих сказал, что чтобы опередить врага, надо начать мыслить как он. Итак, если мы вирусмейкеры, то что мы можем сделать?
1. Скопировать информацию о сертификате с какого-нибудь чистого файла.
Это наиболее популярный способ на данный момент. Копируется информация подписи до мельчайших подробностей, вплоть до цепочки доверенных издателей. Понятно, что такая копия валидна только на взгляд пользователя. Однако то, что отображает ОС вполне может сбить с толку неискушённого и быть воспринято как очередной глюк — ещё бы, если все издатели правильные, то почему это подпись невалидна? Увы и ах — таких большинство.
2. Использовать самоподписанные сертификаты с фэйковым именем.
Аналогично выше описанному варианту за исключением того, что даже не копируется цепочка в пути сертификации.
Несмотря на то, что слабость алгоритма MD5 уже давно описана (тут и тут), он до сих пор часто используется в электронных подписях. Однако реальные примеры взлома MD5 касаются или очень маленьких файлов, или приводят к неправильной работе кода. На практике не встречаются вирусы с поддельными взломанными подписями на алгоритме MD5, но тем не менее такой способ возможен теоретически.
4. Получить сертификат по обычной процедуре и использовать его в злонамеренных целях.
Одна из наиболее распространённых методик авторов так называемых riskware, adware и фэйковых антивирусов. Примером может послужить фэйковый Perfect Defender (стандартный развод: «просканируйтесь бесплатно — у вас вирус — заплатите нам и мы его удалим») существует с подписями нескольких контор:
• Jeansovi llc
• Perfect Software llc
• Sovinsky llc
• Trambambon llc
Интересно, что реально существуют абсолютно нормальные программы с такими именами владельцев:
• Verified Software
• Genuine Software Update Limited
• Browser plugin
Понятно, что если уж этому верить, то ошибиться при первом взгляде на сертификат несложно.
Справедливости ради отмечу, что подписать х64-драйвер далеко не так просто, в этом случае пока нарушений не замечено.
5. Найти какого-нибудь работника доверенной компании и попросить его подписать Ваш код.
Без комментариев. Все любят деньги. Вопрос только в сумме 🙂
6. Украсть сертификат.
На данный момент известно три больших семейства троянцев, «заточенных», в частности, под похищение сертификатов. Это:
• Adrenalin
• Ursnif
• Zeus
• SpyEye (возможно)
7. Заразить систему разработки доверенного разработчика и внедрять злонамеренный код в релизы до подписания.
Яркий пример такого заражения — вирус-концепт Induc.a. Вирус внедряет код на этапе компиляции, заражая систему разработки. В итоге разработчик даже не знает, что в его программе появился невидимый «довесок». Релиз проходит подпись и выходит в свет с полноценным сертификатом. Видишь суслика? А он есть! 😉
К счастью, Induc.a является только PoC, выполняя только заражение систем разработки без реализации какого бы то ни было дополнительного вредоносного функционала.
Ну а теперь — обещанные вкусняшки.
УЯЗВИМОСТЬ ИЛИ КАК Я ПРОВЁЛ ЭТИМ ЛЕТОМ
Как видим, вариантов обхода подписи достаточно много. В нашем примере будет рассмотрен модифицированный вариант 1 и 2, описанные выше.
Итак, что нам потребуется?
— MakeCert.exe
— cert2spc.exe
— sign.exe
— ruki.sys
— mozg.dll
Думаю, что для хабрачитателя не составит труда найти эти компоненты, но для самых ленивых выкладываю первые три здесь. Последние два не выкладываю в виду жёсткой привязки к железу, полному отсутствию кроссплатформенности и специфичности кода 🙂
В результате выполнения мы получим veri.pvk и veri.cer, пригодные для подписывания.
Теперь создадим дочерний сертификат с использованием полученных только что:
В итоге получим kl.pvk и kl.cer, которые будут доверенными сертификатами от недоверенного издателя. Цепочку можно продолжать долго, задуривая наивного пользователя. Но итог будет один: сертификат не будет валидным, потому как в цепочке есть один недоверенный элемент. НО!
В Windows имеется возможность установки любого сертификата, в том числе и самоподписанного, в качестве доверенного. Это удобно: в ряде случаев разработчик может сделать себе самоподписанный сертификат, ввести его в доверенные и спокойно работать со своими приложениям. В нашем случае это удобно вдвойне, потому как такой внос — очевидно, простое внесение информации в реестр. при чём информации отнюдь не специфичной для конкретной системы.
Установим на нашу тестовую виртуалку любой монитор реестра, после чего внесём наш искомый сертификат от якобы VeriSign в доверенные. Отследим, где произошло изменение — и voila! Мы можем сделать дамп соответствующей ветки реестра, после чего засунуть её в инсталлер. В итого, наш инсталлер вносит в реестр инфу, автоматически превращая сертификат первичного издателя в доверенный и валидируя всю цепочку.
Чтобы окончательно не открывать все карты, скажу только, что в моём случае дамп реестра имел вид
Windows Registry Editor Version 5.00
ну или если только для текущего пользователя, то
Windows Registry Editor Version 5.00
Внеся в реестр эти данные, программа с фэйковой цепочкой подписи автоматом проходила проверку по sigverif.exe. Ну а подписать наш код с помощью полученного сертификата вообще просто, достаточно батника:
Обратите внимание на использование таймстампа timestamp.verisign.com/scripts/timstamp.dll — теоретически вполне возможно использование собственного сервера на собственном домене, что позволит каждый раз видеть, что кто-то проверил подпись нашей программы на своём компьютере, а значит получать IP и время проверки. Правда удобно? 😉
Если потребуется, в следующей статье я расскажу, как настроить хипс для защиты соответсвующих веток реестра во избежание описанного внесения сертификатов в доверенные. Отписывайтесь в комментах — возможно, что эту уязвимость уже пофиксили.
В статье использован материал презентации Jarno Niemela (F-Secure).
Создание сертификата для подписи пакета приложения
MakeCert.exe не рекомендуется к использованию. Текущие рекомендации по созданию сертификата см. в разделе Создание сертификата для подписания пакета.
узнайте, как использовать MakeCert.exe и Pvk2Pfx.exe для создания тестового сертификата подписи кода, чтобы вы могли подписывать пакеты приложений Windows.
перед развертыванием пакетной Windows приложения необходимо подписать цифровой подписью. если вы не используете Microsoft Visual Studio 2012 для создания и подписи пакетов приложений, необходимо создать собственные сертификаты для подписи кода и управлять ими. сертификаты можно создавать с помощью MakeCert.exe и Pvk2Pfx.exe из набора драйверов Windows (WDK). Затем можно использовать сертификаты для подписывания пакетов приложений, чтобы их можно было развернуть локально для тестирования.
Это важно знать
Технологии
Предварительные требования
Инструкции
Шаг 1. Определение имени издателя пакета
чтобы сделать сертификат подписи, который вы создадите, использовать с пакетом приложения, который необходимо подписать, имя субъекта сертификата подписи должно соответствовать атрибуту Publisher элемента Identity в AppxManifest.xml для этого приложения. Например, предположим, что AppxManifest.xml содержит:
Эта строка параметра указывается в кавычках и является учетом регистра и пробела.
Шаг 2. создание закрытого ключа с помощью MakeCert.exe
Используйте служебную программу MakeCert для создания самозаверяющего тестового сертификата и закрытого ключа:
Эта команда предложит указать пароль для PVK-файла. Рекомендуется выбрать надежный пароль и защитить закрытый ключ в безопасном месте.
Рекомендуется использовать предлагаемые параметры из предыдущего примера по следующим причинам.
Создает самозаверяющий корневой сертификат. Это упрощает управление тестовым сертификатом.
Помечает базовое ограничение для сертификата как конечную сущность. Это предотвращает использование сертификата в качестве центра сертификации (ЦС), который может выдавать другие сертификаты.
Задает значения расширенного использования ключа (EKU) для сертификата.
Не ставьте пробел между двумя значениями, разделенными запятыми.
Задает дату окончания срока действия сертификата. Укажите значение параметра expirationDate в формате мм/дд/гггг. Рекомендуется выбирать дату истечения срока действия, если это необходимо для целей тестирования, как правило, меньше года. Эта дата окончания срока действия в сочетании с ключом времени существования подписывания может помочь ограничить окно, в котором сертификат может быть скомпрометирован и недоступен.
Дополнительные сведения о других параметрах см. в разделе MakeCert.
шаг 3. создание файла личных данных Exchange (. pfx) с помощью Pvk2Pfx.exe
Файлы MyKey. PVK и MyKey. cer являются теми же файлами, которые MakeCert.exe созданы на предыдущем шаге. С помощью необязательного параметра/по можно указать другой пароль для результирующего PFX-файла; в противном случае PFX-файл имеет тот же пароль, что и MyKey. PVK.
Дополнительные сведения о других параметрах см. в разделе Pvk2Pfx.
После создания PFX-файла можно использовать файл с помощью средства SignTool для подписания пакета приложения. Дополнительные сведения см. в разделе как подписать пакет приложения с помощью средства SignTool. Но сертификат по-прежнему не является доверенным для локального компьютера для развертывания пакетов приложений, пока он не будет установлен в хранилище доверенных сертификатов на локальном компьютере. Вы можете использовать Certutil.exe, который поставляется вместе с Windows.
Установка сертификатов с помощью WindowsCertutil.exe
Запустите Cmd.exe от имени администратора.
Выполните следующую команду:
Рекомендуется удалить сертификаты, если они больше не используются. В той же командной строке администратора выполните следующую команду:
CertID — серийный номер сертификата. Выполните следующую команду, чтобы определить серийный номер сертификата:
Соображения безопасности
Добавив сертификат в хранилища сертификатов локальной машины, вы меняете доверие сертификатов всех пользователей на компьютере. Рекомендуется установить все сертификаты подписи кода, необходимые для тестирования пакетов приложений в хранилище сертификатов «Доверенные лица». Немедленно удалите эти сертификаты, когда они больше не нужны, чтобы предотвратить их использование для компрометации доверия системы.
Связанные темы
How to sign an app package using SignTool (Подписывание пакета приложения с помощью SignTool)
Как подписать программу цифровой подписью
Что такое цифровая подпись для программы
Подпись программы – это процесс добавления специального кода (электронной подписи) к исполняемым файлам и драйверам на этапе разработки.
Электронная подпись позволяет пользователям убедиться, что данная программа:
Электронная подпись для программы также может содержать информацию о версии или другие метаданные. По сути это цифровой аналог обычной рукописной подписи и печати.
Польза от подписания программ для пользователей состоит в том, что они знают, кем было опубликовано данное ПО, и что оно не было изменено. Для разработчиков же это выгодно тем, что их программам доверяют, и подделать их труднее.
Как правило, подписывается не сам исполняемый файл, а его хэш-сумма. Это позволяет уменьшить размер цифровой подписи.
Подтвердить авторство и отсутствие изменений после подписания можно благодаря тому, что:
Для чего используется
Электронная подпись используется в большинстве криптографических протоколов, применяется для распространения ПО, в финансовых транзакциях и других операциях, для которых важно уметь распознать случаи фальсификации.
Наиболее частое применение подписи программного кода – обеспечение безопасности при установке программы. Например, файлы обновлений операционных систем содержат подписи компании-разработчика, чтобы принимающая система могла убедиться в целостности файлов и в том, что они действительно созданы данным производителем, даже если обновления доставляются через третьи лица (скачиваются с сайта дистрибьютора или устанавливаются с дисков).
Как получать цифровую подпись для программы
Электронные подписи создаются с помощью алгоритма подписи с открытым ключом, например, RSA. В алгоритме с открытым ключом на самом деле используются два различных ключа: открытый и закрытый. Закрытый ключ знает только его владелец, а открытый ключ доступен всем. В технологии электронной подписи с помощью закрытого ключа генерируется подпись, а соответствующий ему открытый ключ используется для её проверки.
Чтобы получить электронную подпись, необходимо обратиться в специальный центр сертификации (или удостоверяющий центр). Центр сертификации выдаёт ключи (закрытый и открытый) и сертификат (собственно подпись).
С помощью закрытого ключа разработчик вычисляет хэш-сумму своего кода (в специальном ПО или через веб-сайт), прикрепляет хэш-сумму и сертификат к коду и компилирует его – получается подписанная программа.
Помимо выдачи ключей и сертификатов, центр сертификации отзывает истёкшие или скомпрометированные сертификаты и ведёт соответствующие базы данных.
Существует также вариант, при котором разработчик внедряет в код свою собственную, личную подпись. Конечному пользователю в этом случае необходимо получить открытый ключ непосредственно у разработчика, чтобы выполнить проверку ПО при первом запуске.
Кроме программной реализации цифровой подписи, существует также её аппаратная реализация (например, с помощью смарт-карт, USB-токенов и т.п.).
Однако само по себе наличие цифровой подписи в программе не гарантирует, что последняя безопасна. Наличие подписи говорит о том, что программа была получена из данного источника и не была изменена после того, как была подписана. Доверять источнику программы или нет, решает сам пользователь.
Лицензирование программ
Лицензирование позволяет из написанной программы сделать продукт, пригодный для продажи. Как и с цифровой подписью, разработчик может попытаться создать собственные механизмы или подключиться к существующим системам. Как правило, такие системы позволяют оперативно запустить продажи на основе распространения дистрибутива и серийных номеров, а также обеспечивают защиту от копирования, взлома и модификации.
Что такое цифровая подпись для программы
Подпись программы – это процесс добавления специального кода (электронной подписи) к исполняемым файлам и драйверам на этапе разработки.
Электронная подпись позволяет пользователям убедиться, что данная программа:
- подписана именно данным автором, и
- не была изменена или повреждена после подписания.
Электронная подпись для программы также может содержать информацию о версии или другие метаданные. По сути это цифровой аналог обычной рукописной подписи и печати.
Польза от подписания программ для пользователей состоит в том, что они знают, кем было опубликовано данное ПО, и что оно не было изменено. Для разработчиков же это выгодно тем, что их программам доверяют, и подделать их труднее.
Как правило, подписывается не сам исполняемый файл, а его хэш-сумма. Это позволяет уменьшить размер цифровой подписи.
Подтвердить авторство и отсутствие изменений после подписания можно благодаря тому, что:
- Создать подпись можно только с помощью закрытого ключа, известного только владельцу подписи.
- При любом изменении программы изменяется ее хэш-сумма, и подпись становится недействительной, о чем выдается соответствующее предупреждение.
Для чего используется
Электронная подпись используется в большинстве криптографических протоколов, применяется для распространения ПО, в финансовых транзакциях и других операциях, для которых важно уметь распознать случаи фальсификации.
Наиболее частое применение подписи программного кода – обеспечение безопасности при установке программы. Например, файлы обновлений операционных систем содержат подписи компании-разработчика, чтобы принимающая система могла убедиться в целостности файлов и в том, что они действительно созданы данным производителем, даже если обновления доставляются через третьи лица (скачиваются с сайта дистрибьютора или устанавливаются с дисков).
Как получать цифровую подпись для программы
Электронные подписи создаются с помощью алгоритма подписи с открытым ключом, например, RSA. В алгоритме с открытым ключом на самом деле используются два различных ключа: открытый и закрытый. Закрытый ключ знает только его владелец, а открытый ключ доступен всем. В технологии электронной подписи с помощью закрытого ключа генерируется подпись, а соответствующий ему открытый ключ используется для её проверки.
Чтобы получить электронную подпись, необходимо обратиться в специальный центр сертификации (или удостоверяющий центр). Центр сертификации выдаёт ключи (закрытый и открытый) и сертификат (собственно подпись).
С помощью закрытого ключа разработчик вычисляет хэш-сумму своего кода (в специальном ПО или через веб-сайт), прикрепляет хэш-сумму и сертификат к коду и компилирует его – получается подписанная программа.
Сертификат – это электронный документ, который подтверждает, что подпись принадлежит данному лицу. Сертификат содержит следующую информацию:
- уникальный номер;
- дата начала и окончания срока действия;
- данные о владельце;
- уникальный ключ проверки сертификата (открытый);
- название используемой подписи или стандарты, которым она соответствуют;
- название центра сертификации.
С помощью открытого ключа любой пользователь может проверить, является ли цифровая подпись действительной, то есть соответствует ли она данной программе и открытому ключу пользователя. Проверка подписи осуществляется с помощью специального ПО или на специализированных сайтах. Проверяются следующие параметры:
- срок действия ключа;
- отсутствие ключа в списке отозванных;
- факт выдачи ключа авторизованным центром сертификации.
Помимо выдачи ключей и сертификатов, центр сертификации отзывает истёкшие или скомпрометированные сертификаты и ведёт соответствующие базы данных.
Существует также вариант, при котором разработчик внедряет в код свою собственную, личную подпись. Конечному пользователю в этом случае необходимо получить открытый ключ непосредственно у разработчика, чтобы выполнить проверку ПО при первом запуске.
Кроме программной реализации цифровой подписи, существует также её аппаратная реализация (например, с помощью смарт-карт, USB-токенов и т.п.).
Однако само по себе наличие цифровой подписи в программе не гарантирует, что последняя безопасна. Наличие подписи говорит о том, что программа была получена из данного источника и не была изменена после того, как была подписана. Доверять источнику программы или нет, решает сам пользователь.
Лицензирование программ
Лицензирование позволяет из написанной программы сделать продукт, пригодный для продажи. Как и с цифровой подписью, разработчик может попытаться создать собственные механизмы или подключиться к существующим системам. Как правило, такие системы позволяют оперативно запустить продажи на основе распространения дистрибутива и серийных номеров, а также обеспечивают защиту от копирования, взлома и модификации.
Подробнее о лицензировании программного обеспечения.
Оглавление
1. OpenSSL: инструкция по использованию и аудит безопасности
2. Что такое OpenSSL и для чего используется
3. Как работают SSL сертификаты
4. Как генерировать сертификаты в OpenSSL
5. Какую команду использовать, genpkey или genrsa
6. Как пользоваться OpenSSL (команды OpenSSL)
7. Как создать сертификаты SSL (TLS) для сайтов
8. Рецепты и советы по генерации SSL сертификатов
8.1 Создание запроса на подпись (CSR) из существующих сертификатов
8.2 Автоматическая генерация CSR
8.3 Создание сертификатов, действительных для нескольких имён хостов
8.5 Как получить бесплатный валидный сертификат для сайта
9. Просмотр содержимого ключей и сертификатов
10. Форматы ключей и сертификатов
11. Конвертация ключей и сертификатов
11.1 PEM и DER преобразование
11.2 Конвертация PKCS#12 (PFX)
12. Где хранятся корневые сертификаты Центров Сертификации (CA) в операционной системе
12.1 Корневые сертификаты Центров Сертификации (CA) в Linux
12.1.1 Общесистемные корневые CA сертификаты
12.1.2 Mozilla Network Security Services (NSS)
12.1.3 Google Chrome / Chromium
12.2 Корневые сертификаты Центров Сертификации (CA) в Windows
12.2.1 Общесистемные корневые CA сертификаты
12.2.2 Google Chrome
13. Как добавить корневой сертификат в доверенные
13.1 Как добавить корневой сертификат в доверенные в Linux
13.1.1 Как добавить корневой сертификат в доверенные в Linux на уровне системы
13.1.2 Как добавить корневой сертификат в доверенные в Linux в веб браузеры
13.2 Как добавить корневой сертификат в доверенные в Windows
13.2.1 Как добавить корневой сертификат в доверенные в Windows на уровне системы
13.2.2 Как добавить корневой сертификат в доверенные в Windows в веб браузеры
14. Цепи сертификатов
15. Верификация (проверка) сертификатов
16. Проверка настройки HTTPS
17. Как создать Корневой Центр Сертификации (Root CA)
18. Шифрование файлов в OpenSSL
18.1 Симметричное шифрование файлов в OpenSSL
18.2 Как зашифровать строки в OpenSSL (симметричное шифрование)
18.3 Асимметричное шифрование файлов в OpenSSL
19. Пининг сертификатов (pinning)
20. Словарь основных терминов OpenSSL
21. Программы для проверки настроек SSL и сбора информации
Инструкция по использованию и аудит безопасности
Знаете ли вы, что один единственный корневой сертификат хакера, установленный в вашу систему, фактически лишает её защиты с помощью шифрования SSL (TLS)? Знаете ли вы, что на самом деле для передачи основных данных браузеры не используют ассиметричное шифрование (с помощью сертификатов), а используют симметричное (парольная фраза)? Задумывались ли вы, можете ли Удостоверяющий Центр, выдавший SSL сертификат, расшифровать при желании передаваемый на сайт трафик? Почему VNC сессия, защищённая самодельным сертификатом, считается надёжной, а подключение к сайту, использующего такой же сертификат, нет? Почему для сайтов не подходят самодельные сертификаты? Знаете ли вы, что в вашей системе уже установлены сотни корневых сертификатов различных Центров Сертификации которым безоговорочно доверяют веб браузеры и другие приложения?
В этой статье мы разберёмся, как работает SSL (TLS) шифрование, как пользоваться утилитами OpenSSL, как создавать свои собственные ключи и Центры Сертификации, как подписывать сертификаты для сайтов, как просмотреть детальную информацию о сертификате и ключе, как конвертировать сертификаты в различные форматы и как проверить различные аспекты безопасности SSL (TLS), как проверить, какие сертификаты установлены в качестве доверенных корневых, как добавить новый доверенный сертификат или удалить сертификат из доверенных..
Что такое OpenSSL и для чего используется
OpenSSL — это криптографический инструментарий, реализующий сетевые протоколы Secure Sockets Layer (SSL v2/v3) и Transport Layer Security (TLS v1) и соответствующие им стандарты криптографии.
Программа openssl — это инструмент командной строки для использования различных криптографических функций криптографической библиотеки OpenSSL в консоли. Основны возможности:
- Создание и управление закрытыми ключами, открытыми ключами и параметрами.
- Криптографические операции с открытым ключом
- Создание сертификатов X.509, CSR и CRL
- Расчёт дайджестов сообщений
- Шифрование и дешифрование с помощью шифров
- Клиентские и серверные тесты SSL/TLS
- Обработка подписанной или зашифрованной почты S/MIME
- Запросы отметок времени, генерация и проверка
Как работают SSL сертификаты
Сгенерированные в OpenSSL ключи могут использоваться для шифрования различных данных, но самое популярное использование — шифрование в HTTPS протоколе, где используется ассиметричное шифрование, это означает, что для шифрования используется один ключ, а для расшифровки — второй ключ. Эти ключи называются:
- приватный ключ
- публичный ключ
Как можно понять из названия, публичный ключ не является секретным. Он свободно распространяется и используется для шифрования данных, которые можно расшифровать только приватным ключом.
Публичный и приватный ключ генерируются вмести и криптографически связаны.
Ещё данная пара ключей может использоваться для подписи данных и проверки подписи. Эта подпись подтверждает то, что данные удостоверены владельцем приватного ключа и в последствии эти данные не были изменены. Подписываются данные приватным ключом (которые имеет одно определённое лицо), а проверить подпись можно публичным ключом, который может получить каждый.
Любой может сгенерировать пару ключей, поэтому возникает проблема идентификации — как проверить, что публичный ключ выпущен определённым лицом?
Это можно было бы сделать например так: владелец сайт mysite.org генерирует пару публичный-приватный ключ и просит третью сторону подписать его публичный ключ. В результате публичный ключ распространяется с цифровой подписью, которую можно проверить публичным ключом третьей стороны. На самом деле, всё именно так и происходит, а подписанный публичный ключ, вместе с дополнительной информацией (например, название домена, для которого он подписан) упаковываются в сертификат.
Сертификат, по сути, это публичный ключ, а также информация о домене и другая сопутствующая информация, подписанная электронной подписью.
В результате процедура создания сертификата выглядит так:
- Владельцем сайта генерируется пара приватный и публичный ключ.
- Публичный ключ вместе с другой информацией для подписи (например, название доменного имени) упаковывается в файл в специальном формате. Он называется — Certificate Signing Request (CSR), то есть «запроса на подпись сертификата».
- Данный запрос на подпись (CSR) отправляется в Центр Сертификации (CA), который, используя свой приватный корневой ключ, создаёт подпись для этих данных и всё это упаковывается в другой специальный файл, называемый сертификат.
В результате получается сертификат со следующими свойствами:
- Он может зашифровать данные (в нём есть публичный ключ), которые способен расшифровать только приватный ключ составляющий пару этому сертификату
- Сертификат может быть проверен на подлинность (у него есть цифровая подпись) с помощью сертификата Центр Сертификации (CA), который его создал
При подключении к сайту пользователи получают свою копию сертификата этого сайта, и браузер автоматически проверяет её по доверенным корневым сертификатам, которые содержаться в операционной системе или хранятся в веб браузере.
После этого браузер шифрует с помощью сертификата сайта данные и отправляет их на сервер, эти данные может расшифровать только владелец приватного ключа, то есть сервер. Таким образом происходит согласование ключа, используемого для последующего шифрования.
Как генерировать сертификаты в OpenSSL
На самом деле, приватный ключ веб-сервера и приватный ключ Центр Сертификации (CA) по своей природе ничем не отличаются — они генерируются одной и той же командой. Но Центр Сертификации (CA) имеет особый статус постольку:
- Его приватный ключ используется для подписи сертификатов (поэтому он называется корневым, хотя в физическом смысле не отличается от приватного ключа сервера)
- Его публичный ключ (сертификат) добавлен на компьютеры всех пользователей в качестве доверенного
- Цифровая подпись в сертификате не предназначена для проверки третьей стороной, поскольку сертификат является самоподписанным. Единственное отличие самоподписанного сертификата из Центр Сертификации (CA) от того, который вы можете сгенерировать сами, в том, что он у вас размещён среди доверенных (в операционной системе или в браузере). Вы можете самостоятельно созданный самоподписанный сертификат разместить среди доверенных, и он будет иметь точно такую же силу как и корневой сертификат из Центр Сертификации (CA)
Вернёмся к процедуре подписи, а фактически создания сертификата сервера — создаваемый сертификат должен быть криптографически связан с приватным ключом сервера. Но приватный ключ должен быть известен исключительно его владельцу (серверу). Выходом из данной ситуации является использования уже упомянутого Certificate Signing Request (CSR), то есть «запроса на подпись сертификата». То есть Центру Сертификации передаеъётся публичный ключ и название домена, но приватный ключ остаётся в тайне. Именно в этом смысл существования CSR.
В учебных целях вы можете создать свои корневые ключи и даже свой «Центр Сертификации (CA)». Затем создадим пару приватный и публичный ключ сервера. Используя ключ сервера мы создадим запрос на подпись сертификата (CSR). Приватным ключом CA мы подпишем (создадим) сертификат для сервера.
Также мы научимся добавлять свой корневой сертификат в доверенные, проверять и управлять уже присутствующими доверенными сертификатами.
Какую команду использовать, genpkey или genrsa
В пакете OpenSSL есть две команды, которые выполняют очень похожее действие — генерируют пару приватный-публичный ключ RSA:
openssl genpkey -algorithm RSA openssl genrsa
На самом деле, форматы создаваемых этими программами RSA ключей немного различаются. Команда genpkey заменяет команду genpkey, а также ещё две команды: gendh и gendsa.
То есть использовать надо genpkey с которой нужно указать алгоритм ключа опцией -algorithm.
Как пользоваться OpenSSL (команды OpenSSL)
Команды OpenSSL не столько сложные, сколько запутанные.
Во-первых, их много (48 основных команд, 28 digest команд, 84 cipher команды, а также алгоритмы и методы), некоторые из них выполняют более чем одну функцию, некоторые имеют пересекающиеся функции и не всегда непонятно, какую команду выбрать.
Синтаксис использования команд OpenSSL:
openssl КОМАНДА ОПЦИИ
Ещё один пример как команды OpenSSL могут сбить с толку: у команды x509 есть опция -req, а у команды req есть опция -x509.
Если вы хотите получить справку по командам OpenSSL, то вам нужно знать, что это делается так:
man openssl-КОМАНДА # ИЛИ man КОМАНДА
man openssl-req man openssl-x509 man openssl-genpkey man openssl-enc man openssl-rsa # ИЛИ man req man x509 man genpkey man enc man rsa
Команды openssl могут быть громоздкими за счёт того, что через одну из опций команды передаются опции сертификата.
На самом деле, для типичных задач используется всего несколько команд и несколько опций. Поэтому если понимать суть, то всё довольно просто.
Перечень команд OpenSSL, которые мы будем использовать:
- genpkey (заменяет genrsa, gendh и gendsa) — генерирует приватные ключи
- req — утилита для создания запросов на подпись сертификата и для создания самоподписанных сертификатов PKCS#10
- x509 — утилита для подписи сертификатов и для показа свойств сертификатов
- rsa — утилита для работы с ключами RSA, например, для конвертации ключей в различные форматы
- enc — различные действий с симметричными шифрами
- pkcs12 — создаёт и парсит файлы PKCS#12
- crl2pkcs7 — программа для конвертирования CRL в PKCS#7
- pkcs7 — выполняет операции с файлами PKCS#7 в DER или PEM формате
- verify — программа для проверки цепей сертификатов
- s_client — команда реализует клиент SSL/TLS, который подключается к удалённому хосту с использованием SSL/TLS. Это очень полезный инструмент диагностики для серверов SSL
- ca — является минимальным CA-приложением. Она может использоваться для подписи запросов на сертификаты в различных формах и генерировать списки отзыва сертификатов. Она также поддерживает текстовую базу данных выданных сертификатов и их статус
- rand — эта команда генерирует указанное число случайных байтов, используя криптографически безопасный генератор псевдослучайных чисел (CSPRNG)
- rsautl — команда может быть использована для подписи, проверки, шифрования и дешифрования данных с использованием алгоритма RSA
- smime — команда обрабатывает S/MIME почту. Она может шифровать, расшифровывать, подписывать и проверять сообщения S/MIME
Чтобы увидеть полный список команд выполните:
openssl list -commands
asn1parse ca ciphers cms crl crl2pkcs7 dgst dhparam dsa dsaparam ec ecparam enc engine errstr gendsa genpkey genrsa help list nseq ocsp passwd pkcs12 pkcs7 pkcs8 pkey pkeyparam pkeyutl prime rand rehash req rsa rsautl s_client s_server s_time sess_id smime speed spkac srp storeutl ts verify version x509