bg-tutorials

Как сгенерировать CSR на Android

Данное руководство показывает как сгенерировать CSR (запрос на подпись сертификата) для Android с помощью утилиты Java keytool.

Android не генерирует публичные CSR для TLS-сертификатов CA непосредственно на телефоне: сертификат публичного CA выпускается для сервера (или устройства, которым управляет пользователь), а приложения и браузеры Android его используют. Процесс с keytool, описанный ниже, создаёт запрос PKCS #10 из хранилища ключей Java, и это правильный путь, когда вам нужен TLS-сертификат, которому будет доверять приложение Android или веб-сайт, ориентированный на мобильные устройства.

Выберите правильную процедуру для вашего случая

«CSR для Android» может означать три разные вещи. Убедитесь, что вы на правильной странице, прежде чем выполнять какие-либо команды:

  • TLS-сертификат для сервера, с которым будут взаимодействовать клиенты Android. Это наиболее распространённый случай, и остальная часть этой страницы посвящена именно ему. Используйте keytool (ниже) или сгенерируйте CSR отдельно от сервера с помощью нашего генератора CSR, а затем установите выданный сертификат на веб-сервер, API-шлюз или брокер MQTT, к которому обращается ваше приложение.
  • Ключ подписи для APK или AAB. Подписание приложений Android использует самоподписанный ключ RSA или EC в хранилище ключей Java: здесь не задействован публичный CA и нет CSR для отправки. Сгенерируйте ключ с помощью keytool через мастер Android Studio Build > Generate Signed Bundle / APK (или запустите keytool вручную), а затем зарегистрируйте ключ в Google Play App Signing. Не заказывайте публичный сертификат для этого случая.
  • Сертификат устройства, выданный MDM или EMM. Android Enterprise выдаёт клиентские сертификаты управляемым устройствам через SCEP, EST или Managed Configurations API. CSR генерируется, а сертификат устанавливается автоматически посредством MDM. Ручной шаг с keytool здесь не требуется.

Если ваш случай — первый, продолжайте. Процесс состоит из двух частей: создание хранилища ключей PKCS12, содержащего закрытый ключ, а затем экспорт CSR из этого хранилища.

Что вам понадобится

  • Установленная Java (JDK или JRE), чтобы команда keytool была доступна в переменной PATH. Проверьте это командой keytool -help. В Windows папка bin Java должна быть в PATH, либо вы можете запускать keytool непосредственно из директории bin JDK.
  • Точное полное доменное имя (FQDN), которое вы хотите защитить (например, www.yoursite.com), а также любые другие имена хостов, которые вы хотите включить в тот же сертификат (для списка Subject Alternative Name).
  • Юридические реквизиты вашей организации (страна, область, город, название организации) для Distinguished Name. Используйте значения точно так, как они указаны в публичных бизнес-реестрах: CA отклонит несоответствия.

Шаг 1: Создание хранилища ключей и закрытого ключа

Если вы уже сгенерировали свой CSR, перейдите сразу к разделу отправка CSR, а затем к инструкциям по установке SSL для Android.

Откройте терминал (или командную строку в Windows) и выполните команду keytool ниже. Она создаёт новое хранилище ключей в формате PKCS12, генерирует внутри него пару ключей RSA длиной 2048 бит и сохраняет ключ под выбранным вами псевдонимом. PKCS12 является форматом хранилища ключей по умолчанию начиная с JDK 9; более старый формат JKS устарел, и его следует избегать для новых ключей.

keytool -genkeypair 
  -alias myalias 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yoursite.p12 
  -validity 825

В Windows та же команда одной строкой выглядит так (обратите внимание на абсолютный путь, чтобы вы могли снова найти файл):

keytool -genkeypair -alias myalias -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore C:certsyoursite.p12 -validity 825

Что делают эти флаги:

  • -alias myalias: имя записи внутри хранилища ключей. Выберите метку, которую вы запомните, и запишите её. Вы должны использовать этот же псевдоним при экспорте CSR и снова при импорте подписанного сертификата.
  • -keyalg RSA -keysize 2048: ключ RSA длиной 2048 бит — это текущий публичный минимум, принимаемый всеми CA. Используйте 3072 бита для ключа с более долгим сроком службы, или сгенерируйте ключ ECDSA с помощью -keyalg EC -groupname secp256r1 для более компактного и быстрого ключа (каждый современный CA выпускает сертификаты для ECDSA P-256 и P-384).
  • -storetype PKCS12: принудительно задаёт современный формат хранилища ключей PKCS12. Соответствующее расширение — .p12 (или .pfx).
  • -keystore yoursite.p12: файл хранилища ключей, который нужно создать. Замените имя на то, которое вы запомните, и храните файл в безопасности: в нём содержится ваш закрытый ключ.
  • -validity 825: срок действия самоподписанного заполнителя сертификата внутри хранилища ключей. Подписанный сертификат от CA позже заменит его, поэтому это значение не влияет на срок службы в рабочей среде.

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

Шаг 2: Ввод реквизитов вашей организации (DN)

Теперь keytool запрашивает Distinguished Name (DN): поля идентификации, которые появятся в CSR. Отвечайте на каждый запрос точным юридическим значением для вашей организации. Используйте только стандартные символы ASCII: нелатинские буквы нарушают запрос. Пунктуация также важна, поскольку CA сверяет ваши значения с публичными бизнес-реестрами.

  • What is your first and last name? Это формулировка keytool для Common Name (CN). Введите точное полное доменное имя (FQDN), которое вы хотите защитить (например, www.yoursite.com), или маску-заполнитель, например *.yoursite.com. Не вводите имя человека.
  • What is the name of your organizational unit? CA/Browser Forum отменил атрибут organizationalUnitName 1 сентября 2022 года, и публичные CA удаляют его из выпущенных сертификатов. Обратите внимание, что нажатие Enter не оставляет поле пустым: keytool подставляет собственное значение по умолчанию, поэтому DN в итоге содержит OU=Unknown, и это значение попадает в CSR. Чтобы действительно опустить этот атрибут, пропустите запросы и передайте DN напрямую с помощью параметра -dname, не включая OU в строку.
  • What is the name of your organization? Введите полное юридическое название вашей компании точно так, как оно зарегистрировано (например, Your Company LLC). Обязательно для сертификатов OV и EV; для сертификатов с проверкой домена (DV) значение игнорируется, поэтому подойдёт любой короткий заполнитель.
  • What is the name of your city or locality? Укажите полное название города, где зарегистрирована ваша компания (например, Seattle, а не SEA).
  • What is the name of your state or province? Введите полное название штата или области (например, California, а не CA).
  • What is the two-letter country code for this unit? Введите двухбуквенный код по стандарту ISO 3166-1 alpha-2 (например, US, GB, DE). Если не уверены, ознакомьтесь с официальным списком ISO.

keytool выводит собранный DN и спрашивает Is CN=…, OU=…, O=…, L=…, ST=…, C=… correct? Введите yes и нажмите Enter для подтверждения. Если вы заметили опечатку, введите no, и keytool перезапустит запросы.

Шаг 3: Экспорт CSR с указанием Subject Alternative Name

Теперь экспортируйте CSR с помощью команды keytool -certreq. Каждый публичный CA проверяет имя хоста по расширению Subject Alternative Name (SAN), а не по Common Name (браузеры и современные библиотеки TLS перестали проверять CN уже много лет назад), поэтому включайте SAN даже для одного имени хоста. Используйте тот же псевдоним, который вы указали в Шаге 1:

keytool -certreq 
  -alias myalias 
  -file certreq.csr 
  -keystore yoursite.p12 
  -ext SAN=DNS:www.yoursite.com,DNS:yoursite.com

В Windows та же команда одной строкой:

keytool -certreq -alias myalias -file certreq.csr -keystore C:certsyoursite.p12 -ext SAN=DNS:www.yoursite.com,DNS:yoursite.com

Добавьте по одной записи DNS: на каждое имя хоста для мультидоменного сертификата (разделяйте их запятыми без пробелов). Для маски-заполнителя используйте DNS:*.yoursite.com. keytool запрашивает пароль хранилища ключей, а затем записывает CSR в файл certreq.csr в вашей текущей директории.

Шаг 4: Открытие CSR и отправка его в CA

Откройте файл certreq.csr в любом текстовом редакторе (Notepad, TextEdit, nano, vim). Вы также можете вывести его в терминал:

cat certreq.csr

В командной строке Windows:

type certreq.csr

Вы увидите блок, который выглядит следующим образом:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIDXjCCAkYCAQAwgZQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
... (many lines of base64) ...
-----END NEW CERTIFICATE REQUEST-----

Выделите весь блок, включая строки BEGIN NEW CERTIFICATE REQUEST и END NEW CERTIFICATE REQUEST (некоторые CA обозначают их как BEGIN CERTIFICATE REQUEST / END CERTIFICATE REQUEST: оба варианта обозначения принимаются). Скопируйте его и вставьте в поле CSR формы заказа.

Проверка CSR перед отправкой (необязательно)

Стоит проверить Common Name, записи SAN и размер ключа перед отправкой запроса в CA. keytool выводит ту же информацию из записи хранилища ключей:

keytool -printcertreq -file certreq.csr

Предпочитаете онлайн-инструмент? Вставьте содержимое запроса в декодер CSR от SSL Dragon, чтобы просмотреть субъект, список SAN и параметры открытого ключа. Убедитесь, что Common Name соответствует имени хоста, которое будут использовать клиенты, и что все необходимые имена присутствуют в списке Subject Alternative Name.

Будет ли Android доверять выданному сертификату?

Да, для любого сертификата, подписанного публично доверенным CA. Android поставляется с системным хранилищем корневых сертификатов, которое отражает списки доверия основных браузеров, поэтому сертификату, выпущенному под одним из этих корней, доверяют Chrome, WebView и любое приложение, использующее системное хранилище доверия, без дополнительной настройки.

Стоит знать о двух нюансах, если вы также устанавливаете сертификат (или корневой сертификат частного CA) непосредственно на устройство:

  • Установленные пользователем CA игнорируются приложениями в Android 7 и более поздних версиях. Начиная с Android 7 (Nougat), по умолчанию трафику приложений доверяет только системное хранилище, а Google Chrome также игнорирует установленные пользователем CA. Если ваше приложение должно доверять частному CA, разработчику необходимо явно включить это через конфигурацию сетевой безопасности, содержащую <certificates src="user" />. Сертификатам публичных CA это не требуется: они уже находятся в системном хранилище.
  • Привязывайтесь к стабильному идентификатору, а не к отдельному сертификату. Если вы реализуете закрепление сертификата (certificate pinning) в своём приложении, привязывайтесь к хешу SPKI открытого ключа или к выпускающему CA, а не к конкретному конечному сертификату. В противном случае следующее продление заблокирует доступ пользователям.

Следующие шаги

После того как CA проверит CSR и выпустит ваш сертификат, импортируйте выданный сертификат обратно в то же хранилище ключей (под тем же псевдонимом), а затем разверните хранилище ключей на сервере, к которому будут обращаться клиенты Android. Ознакомьтесь с нашим руководством по установке SSL для Android для получения инструкций по установке на устройстве, либо с руководствами по установке для конкретных платформ в разделе как установить SSL-сертификат, если ваш бэкенд работает на Tomcat, JBoss, Nginx или другом сервере.

Сэкономьте 10% на SSL-сертификатах при заказе сегодня!

Быстрая выдача, надежное шифрование, 99,99% доверия к браузеру, специализированная поддержка и 25-дневная гарантия возврата денег. Код купона: SAVE10

Детальное изображение дракона в полете
Написано

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

Avatar of Sergiu Rosca
Technical Review by Sergiu Rosca

Sergiu Rosca is the core web developer behind SSL Dragon. He manages the technical infrastructure, platform performance, and backend integrations that keep the site running smoothly and securely. At SSL Dragon, Sergiu shares practical insights on web development, site optimization, and technical troubleshooting.

All SSL Dragon installation guides are tested on live server environments and undergo a strict peer-review process to ensure your infrastructure remains secure. Read our full Editorial Policy.