Сертификат jks как посмотреть

Основы Java Keytool: работа с Java Keystore

Java Keytool – это инструмент Java для управления ключами, сертификатами и хранилищами ключей. Java Keystore (или JKS) – это хранилище сертификатов открытых ключей и авторизации, которое часто используется приложениями на основе Java для шифрования, аутентификации и установки соединений HTTPS. Все его записи защищены паролем хранилища ключей. Запись хранилища ключей идентифицируется псевдонимом и содержит надежные ключи и сертификаты.

Данное руководство описывает использование команд keytool, очень полезных при работе с JKS. Также оно охватывает создание и редактирование хранилищ ключей Java для Java-приложений.

Создание и импортирование записей

Данный раздел посвящен командам Java Keytool, которые создают пары ключей и сертификатов, а также импортируют сертификаты.

Создание ключей

Используйте этот метод для поддержки HTTPS (HTTP по TLS). В данном разделе показано, как создать новую пару ключей в новом или уже существующем хранилище ключей Java, которые могут быть использованы для создания запроса на подпись сертификата (CSR) или получения SSL-сертификата в центре сертификации.

Данная команда сгенерирует пару 2048-битных RSA-ключей под указанным псевдонимом (в данном случае это domain) в указанном файле хранилища (keystore.jks).

Если же заданного хранилища ключей не существует, оно будет создано после получения запрашиваемой информации (а именно пароля хранилища ключей, строки Distinguished Name (для закрытого ключа) и пароля закрытого ключа).

Создание CSR для существующего закрытого ключа

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

Данная команда создаст CSR (domain.csr), подписанный закрытым ключом с псевдонимом domain в хранилище keystore.jks:

Введите пароль хранилища ключей, после чего запрос будет создан.

Импортирование подписанного/Root/промежуточного сертификата

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

Следующая команда импортирует сертификат (domain.crt) в хранилище ключей (keystore.jks) под указанным псевдонимом (domain). Подписанный сертификат при импортировании должен соответствовать закрытому ключу с указанным псевдонимом:

На данном этапе будет предложено ввести пароль хранилища ключей, а затем подтвердить импортирование.

Создание самоподписанного сертификата в новом/существующем хранилище

В данном разделе показано, как создать самоподписанный сертификат для приложения Java. На самом деле, для этого используется та же команда, что и для создания новой пары ключей, но с параметром days, задающим срок действия сертификата.

Итак, данная команда создаст пару 2048-битных RSA-ключей, действительных на протяжении 365 дней, с указанным псевдонимом (domain) в заданном файле ключей (keystore.jks):

Если заданного хранилища ключей не существует, команда создаст его, получив необходимые данные (это пароль хранилища, Distinguished Name (дл закрытого ключа) и пароль закрытого ключа).

Просмотр записей хранилища ключей

В данном разделе речь пойдет о содержимом Java Keystore, а именно о просмотре информации сертификата и экспортировании сертификатов.

Проверка контрольной суммы сертификата

Данная команда выводит список контрольных сумм всех сертификатов хранилища (keystore.jks) с соответствующими псевдонимами.

Подробное содержание хранилища

Данная команда выведет подробную информацию о записях, находящихся в хранилище keystore.jks, в том числе длину цепи сертификата, контрольных сумм сертификатов в цепочке, имена (distinguished name), серийные номера, а также дату создания и срок дейтвия по псевдонимам:

Использование Keytool для просмотра информации о сертификате

Данная команда выведет подробную информацию о файле сертификата (certificate.crt), в том числе контрольную сумму, distinguished name владельца и срок его действия:

При этом нужно ввести пароль хранилища.

Экспортирование сертификатов

Данная команда экспортирует бинарный DER-зашифрованный сертификат (domain.der) с псевдонимом (domain) в хранилище (keystore.jks):

Укажите пароль хранилища ключей.

Редактирование хранилища ключей

Данный раздел охватывает редактирование записей Java Keystore (например, удаление и изменение псевдонимов).

Изменение пароля хранилища

При помощи этой команды можно изменить пароль хранилища (keystore.jks):

Удаление псевдонима

Данная команда удалит псевдоним domain из хранилища keystore.jks:

Укажите пароль хранилища.

Изменение псевдонима

При помощи данной команды можно изменить псевдоним (например, domain на newdomain):

Итоги

Данное руководство описывает большинство операций, которые выполняются при управлении Java Keystores. Конечно, охватить все функции в одной статье невозможно. Но зная базовые команды, можно самостоятельно поэкспериментировать с управлением хранилищами.

Данное руководство основано на версии хранилища ключей, которое поставляется с Java 1.7.0. чтобы установить Java, читайте данную статью.

Источник

Русские Блоги

Гибкий keytool и openssl для генерации сертификатов, применения tomcat и nginx

Гибкий keytool и openssl для генерации сертификатов, применения tomcat и nginx

Справочник статей

предисловие

Вообще говоря, основное программное обеспечение Web-сервисов обычно основано на двух основных криптографических библиотеках: OpenSSL и Java.

Что такое сертификат? Зачем использовать сертификат?

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

Итак, как определить, что открытый ключ должен принадлежать издателю? Для этого требуется сертификат. Сертификат выдается органом, содержание которого содержит личность владельца сертификата и его открытый ключ, и подписывается органом с использованием его закрытого ключа. Издатель информации раскрывает свой открытый ключ, выдавая сертификат в сети. Сертификат подписан уполномоченным органом по сертификации. Центр сертификации также раскрывает свой открытый ключ, выдав свой сертификат. Сертификат органа по сертификации выдается более авторитетным Центр сертификации подписывает сертификат, образуя цепочку сертификатов. Сертификат в верхней части цепочки сертификатов называется корневым сертификатом, а корневой сертификат является только самоподписанным. Короче говоря, для подписи и аутентификации контента, распространяемого в Интернете, обязательно будет использоваться сертификат. Что касается стандартов, то сертификат следует, самым популярным является X.509

Преобразование формата сертификата

Преобразование формата сертификата происходит следующим образом:

Примечание. Служба сертификатов Alibaba Cloud Shield равномерно использует файлы цифровых сертификатов в формате PEM.

Вы можете использовать встроенный JDK Keytool Инструмент для преобразования файла сертификата формата JKS в формат PFX.
Например, вы можете выполнить следующую команду, чтобы преобразовать файл сертификата server.jks в файл сертификата server.pfx:

Вы можете использовать встроенный JDK Keytool Инструмент, PFX Формат файла сертификата в JKS Формат.
Например, вы можете выполнить следующую команду для server.pfx Преобразовать файл сертификата в s erver.jks Файл сертификата:

Вы можете использовать инструменты OpenSSL для KEY Формат файла ключа и CRT Отформатировать файл открытого ключа в PFX Формат файла сертификата.
Например, скопируйте файл ключа формата KEY (server.key) и файл открытого ключа формата CRT (server.crt) в каталог установки инструмента OpenSSL и используйте инструмент OpenSSL, чтобы выполнить следующую команду для Преобразуйте сертификат в файл сертификата server.pfx:

Можно использовать OpenSSL Инструмент, PFX Формат файла сертификата в KEY Формат файла ключа и CRT Формат файла открытого ключа.
Например, скопируйте PFX Скопируйте файл сертификата формата в OpenSSL Установочный каталог, используйте инструмент OpenSSL, чтобы выполнить следующую команду для преобразования сертификата в server.pem Файл сертификата, файл ключа формата KEY ( server.key ) И файл открытого ключа в формате CRT ( server.crt ）：

Формат сертификата

Вы можете просто отличить файл сертификата с расширением суффикса, используя следующие методы:

Затем файл сертификата в текстовом формате.

Формат файла хранилища ключей Keystore 】

Формат файла сертификата [ Certificate 】

Что такое keytool?

команда справки keytool

Результат выглядит следующим образом

Просмотр справки команды

Основной формат

Другие включают jceks, jks, dks, pkcs11, pkcs12.

Разница между test.keystore и test.jks

Это эквивалентно следующему и оба являются файлами ключей формата jks.

Keytool генерирует сертификат Tomcat

Tomcat поддерживает сертификаты формата JKS. Начиная с Tomcat7, он также поддерживает сертификаты формата PFX. Один из двух форматов сертификатов является необязательным.

Генерация закрытого ключа и сертификата

storepass : пароль хранилища файлов пароль хранилища
keypass : Пароль шифрования закрытого ключа
alias : Псевдоним объекта (включая закрытый ключ сертификата)
keyalt : Использовать алгоритм открытого ключа, по умолчанию используется DSA и необязательный алгоритм RSA
keysize: длина ключа (алгоритм по умолчанию, соответствующий алгоритму DSA, это sha1withDSA, который не поддерживает длину 2048, и в это время должен быть указан RSA)
validity : Срок действия (не менее одного года, вы не хотите часто обновлять сертификат)
keystore : Укажите файл хранилища ключей

Запросите имя и фамилию для доменного имени, сравните http://192.168.1.243 (при условии, что в вашей локальной сети используется протокол https)

распространение
Если вы хотите создать файл ключей формата pkcs12

Посмотреть детали сертификата

Результат выглядит следующим образом

JKS конвертировать в формат pkcs12 сертификат

На самом деле, приведенная выше командная строка уже предлагает

Экспортный сертификат

Экспорт сертификата предназначен для экспорта файла открытого ключа.

Импортный сертификат

Сертификат импорта фактически используется на клиентском компьютере. Если это CA, сертификат автоматически заполняется. Фактически, если это официально сертифицированный сертификат, этот шаг можно пропустить.

Источник

Учебник по Java Keystore

Содержание

1. Введение

Кто из нас не посещал ebay, amazon, чтобы купить что-нибудь, или его личный банковский счет, чтобы проверить это. Считаете ли вы, что эти сайты достаточно безопасны для размещения ваших личных данных, таких как (номер кредитной карты или номер банковского счета и т. Д.)?

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

Многие серверы приложений Java и веб-серверы поддерживают использование хранилищ ключей для конфигурации SSL. Если вы создаете безопасные Java-программы, обучение созданию хранилища ключей является первым шагом.

2. SSL и как это работает

HTTP-соединение на основе HTTP всегда инициируется клиентом с использованием URL-адреса, начинающегося с https: // вместо http: //. В начале сеанса SSL выполняется рукопожатие SSL. Это рукопожатие производит криптографические параметры сеанса. Упрощенный обзор того, как обрабатывается рукопожатие SSL, показан на диаграмме ниже.

Вкратце, как это работает:

Мир SSL имеет, по сути, три типа сертификатов: закрытые ключи, открытые ключи (также называемые открытыми сертификатами или сертификатами сайта) и корневые сертификаты.

3. Частные ключи

Закрытый ключ содержит идентификационную информацию сервера, а также значение ключа. Он должен хранить этот ключ в безопасности и защищаться паролем, поскольку он используется для согласования хэша во время рукопожатия. Кто-то может использовать его для расшифровки трафика и получения вашей личной информации. Это как оставить ключ от дома в замке.

4. Публичные сертификаты

Источник

Варианты хранения криптографических ключей

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

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

Во многих случаях секретные ключи — личные удостоверения ваших сотрудников (и, следовательно, часть персональных данных организации), так что их защита приравнивается к защите отпечатков пальцев при использовании биометрических учётных данных. Вы же не позволите хакеру добыть отпечаток своего пальца? То же самое и с секретными ключами.

В этой статье мы обсудим варианты защиты и хранения закрытых ключей. Как вы увидите, эти варианты могут незначительно отличаться в зависимости от типа сертификата(ов) и от того, как вы его используете (например, рекомендации для сертификатов SSL/TLS отличаются от рекомендаций для сертификатов конечных пользователей).

Хранилища сертификатов/ключей в ОС и браузерах

Примеры: хранилище сертификатов Windows, связка ключей Mac OS

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

Ещё один плюс такого варианта — его довольно легко настраивать. Вы можете включить/отключить экспорт закрытого ключа, включить для него надёжную защиту (ввод пароля при каждом использовании сертификата), и можно создать резервные копии, если закрытый ключ экспортируется. Кроме того, при включении роуминга профилей в Windows сертификат привязывается к профилю и становится доступным при входе на другой компьютер с этим профилем.

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

И последнее: Chrome и IE используют хранилище сертификатов Windows, в то время как у Firefox собственное хранилище сертификатов (от Mozilla). Это значит, что если вы импортируете сертификат в хранилище Windows, то Chrome и IE автоматически найдут его, а Firefox нет.

Типичные приложения:

Если решите сохранить файл на удалённом сервере, то следует особенно позаботиться об ограничении доступа к нему. Если кто-то получит доступ, то сможет использовать ваш сертификат. Аналогично, следует быть особенно осторожным с лёгким копированием и распространением этих файлов. Хотя это и большое удобство для вас, но одновременно и злоумышленнику будет просто сделать копию, если он получит доступ к вашему хранилищу ключей. Пароль закрытого ключа по-прежнему необходим для эффективного использования скопированного файла. Это еще одна причина, чтобы использовать надёжные пароли из 15-ти и больше символов, содержащие заглавные буквы, цифры и специальные символы. С этим вариантом хранения нужно учитывать ещё одну вещь: на конечного пользователя накладывается больше ответственности с точки зрения того, где находится файл и правильно ли он хранится.

Если вы не можете использовать криптографическое оборудование или хранилище ключей Windows (описано выше), но всё же хотите повысить безопасность (вместо того, чтобы просто разместить файл хранилища ключей на компьютере), то можно записать этот файл на флэшку, которая будет лежать в безопасном месте. Конечно, здесь теряется некоторое удобство, так что если нужно часто использовать подпись, то вы скорее захотите хранить файл локально для облегчения доступа.

Типичные приложения:

Криптографические токены и смарт-карты

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

С токеном каждый раз при использовании сертификата нужно вводить пароль. Это значит, что даже если кто-то получит ваш токен, ему всё равно понадобится пароль. Хранение ключа в токене означает, что вы можете безопасно использовать один и тот же сертификат на нескольких компьютерах без необходимости создания нескольких копий и прохождения процесса экспорта/импорта. Криптографическое оборудование соответствует FIPS, что требуется для некоторых отраслевых и государственных регламентов.

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

Типичные приложения:

Как правило, все варианты использования, перечисленные для хранилищ в ОС/браузере (подпись документов и кода, аутентификация клиента, Windows IIS), поддерживают крипто-токены или смарт-карты — если есть соответствующие драйверы. Однако это не всегда практично (например, в веб-серверах или автоматизированных системах сборки для подписи кода, которые будут требовать ввод пароля каждый раз при применении подписи).

Соответствие нормативным требованиям — одна из основных причин использования криптографических токенов.

Аппаратные криптографические модули (HSM)

HSM — ещё одно аппаратное решение для хранения ключей, особенно если вы не хотите полагаться на отдельные токены либо это кажется слишком обременительным. В то время как токены больше ориентированы на ручной ввод или отдельные приложения (например, подписание небольшого количества документов или кода, аутентификация в VPN или других сетях), то HSM предоставляют API, поддерживают автоматизированные рабочие процессы и автоматизированную сборку. Они также соответствуют требованиям FIPS и обычно обеспечивают более высокий рейтинг, чем токены.

Традиционно HSM — это локальные физические устройства, требующие квалифицированных ресурсов для управления и обеспечения базовых требований и SLA. Обслуживание HSM может оказаться дорогим и ресурсоёмким процессом, что в прошлом препятствовало распространению этой технологии. К счастью, в последние годы появились облачные модули HSM, которые предоставляют многие из преимуществ локальных HSM, не нуждаясь в локальном обслуживании.

Примером может служить знакомый многим сервис Key Vault в облаке Microsoft Azure, которое хранит криптографические ключи в облачном HSM от Microsoft. Если у вас небольшая организация, которая не позволит себе покупку и управление собственным HSM, то это отличное решение, которое интегрируется с публичными центрами сертификации, включая GlobalSign.

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

Типичные приложения:

Будущие методы хранения ключей

Мы рассмотрели основные варианты, которые использовались в течение многих лет. Но кажется, что ничто в мире информационной безопасности, в том числе и хранение ключей, не застраховано от влияния IoT, так что разрабатываются новые варианты.

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

Доверенный платформенный модуль (TPM)

Модули TPM сами по себе не новы, но всё чаще их используют для защиты закрытых ключей. Доверенный платформенный модуль можно использовать для хранения (или переноса) корневого ключа и защиты дополнительных ключей, созданных приложением. Ключи приложений нельзя использовать без TPM, что делает его очень полезным методом аутентификации для оконечных точек, таких как ноутбуки, серверы и производители устройств Интернета вещей. В то время как многие ноутбуки уже поставляются с TPM, пока эта технология не слишком широко используется в корпоративном секторе. Однако в мире IoT они часто применяются для безопасной индентификации устройств как аппаратный корень доверия.

IoT создал проблему, когда много анонимно взаимодействующих устройств облегчают хакерам перехват сообщений или имперсонификацию устройств. Модуль TPM внедряется ещё на этапе производства для защиты криптографического ключа и, следовательно, для надёжной идентификации устройства.

Мы тесно сотрудничаем с Infineon для разработки решений Интернета вещей, сочетающих идентификацию устройств на основе PKI с корнями доверия на основе TPM. Для получения дополнительной информации ознакомьтесь с подтверждением концепции: «Безопасная аутентификация и управление оборудованием с помощью облачных служб сертификатов GlobalSign и OPTIGA TPM от Infineon.»

Физически неклонируемые функции (PUF)

Технология физически неклонируемых функций (PUF) — это сдвиг парадигмы в защите ключей. Вместо хранения ключей (с вероятностью физической атаки) они генерируются из уникальных физических свойств статической памяти SRAM конкретного чипа и существуют только при включении питания. То есть вместо надёжного хранения закрытого ключа один и тот же ключ восстанавливается снова и снова по требованию (пока устройство не выйдет из строя). Этот ключ гарантированно уникален, потому что при генерации используется присущая неконтролируемая неупорядоченность в кремниевой структуре чипа.

Технология PUF в сочетании с доверенной средой исполнения (TEE) — привлекательное решение, если требуется недорогая, простая в интеграции и ультра-безопасная защита ключа. PUF вместе с PKI составляют исчерпывающее решение для идентификации.

Наш партнёр Intrinsic ID разработал такую систему подготовки ключа на основе SRAM PUF, которая производит уникальные, защищённые от подделки и копирования идентификаторы устройств на аппаратном уровне. Используя наши службы сертификации, мы переводим эти идентификаторы в цифровые удостоверения, добавляя возможности PKI. Таким образом, каждому устройству присваивается уникальная, защищённая от клонирования пара ключей, которая не хранится на устройстве в выключенном состоянии, но устройство способно воссоздать этот ключ по запросу. Это защищает от атаки на выключенное устройство.

Дополнительно о нашем совместном решении для идентификации
устройств Интернета вещей см. недавний вебинар: «Стойкие идентификаторы устройств с сертификатами на основе SRAM PUF».

Не теряйте (секретные) ключи от своей крепости!

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

_______________________________________________________

АКЦИЯ GLOBALSIGN: Wildcard SSL + 1 ГОД В ПОДАРОК
Защитите все субдомены одним сертификатом!

Экономьте до 30 тысяч рублей при покупке сертификата Wildcard SSL на 2 года!
Промо-код: WC001HRFR

Акция действует для подписчиков блога GlobalSign до 15 июня 2018 г.

Дополнительную информацию вы можете получить у менеджеров GlobalSign по телефону: +7 (499) 678 2210 либо заполнив форму на сайте с указанием промо-кода.

Источник