How to Generate a CSR on Android

This tutorial shows you how to generate a CSR (Certificate Signing Request) for Android with the Java keytool utility.

Android does not generate public-CA TLS CSRs on the phone itself: a public-CA certificate is issued for a server (or a device the user controls), and Android apps and browsers consume it. The keytool flow below produces a PKCS #10 request from a Java keystore, which is the right path when you need a TLS certificate that an Android app or mobile-targeted website will trust.

Pick the right procedure for your case

“CSR for Android” can mean three different things. Make sure you are on the right page before you run any commands:

• A TLS certificate for a server that Android clients will talk to. This is the most common case, and the rest of this page covers it. Use keytool (below) or generate the CSR off-server with our CSR Generator, then install the issued certificate on the web server, API gateway, or MQTT broker that your app reaches.
• A signing key for an APK or AAB. Android app signing uses a self-signed RSA or EC key in a Java keystore: there is no public CA involved and no CSR to submit. Generate the key with keytool from Android Studio’s Build > Generate Signed Bundle / APK wizard (or run keytool by hand), then enroll the key with Google Play App Signing. Do not order a public certificate for this.
• A device certificate provisioned by an MDM or EMM. Android Enterprise issues client certificates to managed devices over SCEP, EST, or the Managed Configurations API. The CSR is generated and the certificate installed automatically by the MDM. There is no manual keytool step.

If your case is the first one, continue. The flow has two parts: create a PKCS12 keystore that holds the private key, then export the CSR from that keystore.

What you will need

• A Java installation (JDK or JRE) so the keytool command is available on your PATH. Confirm with keytool -help. On Windows, Java’s bin folder must be on PATH, or you can run keytool from the JDK’s bin directory directly.
• The exact fully qualified domain name (FQDN) you want to secure (for example www.yoursite.com), plus any other hostnames you want on the same certificate (for the Subject Alternative Name list).
• Your organization’s legal details (country, state, city, organization name) for the Distinguished Name. Use the values exactly as they appear on public business records: the CA will reject mismatches.

Step 1: Create the keystore and the private key

If you already generated your CSR, skip ahead to submit the CSR and then to the Android SSL installation instructions.

Open a terminal (or Command Prompt on Windows) and run the keytool command below. It creates a new keystore in PKCS12 format, generates a 2048-bit RSA key pair inside it, and stores the key under the alias you choose. PKCS12 has been the default keystore format since JDK 9; the older JKS format is deprecated and should be avoided for new keys.

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

On Windows, the same command on one line looks like this (note the absolute path so you can find the file again):

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

What the flags do:

• -alias myalias: the entry name inside the keystore. Pick a label you will recognize and write it down. You must reuse this exact alias when you export the CSR and again when you import the signed certificate.
• -keyalg RSA -keysize 2048: a 2048-bit RSA key is the current public minimum every CA accepts. Use 3072 bits for a longer-lived key, or generate an ECDSA key with -keyalg EC -groupname secp256r1 for a smaller, faster key (every modern CA issues against ECDSA P-256 and P-384).
• -storetype PKCS12: forces the modern PKCS12 keystore. The matching extension is .p12 (or .pfx).
• -keystore yoursite.p12: the keystore file to create. Replace the name with something you will remember, and keep the file safe: it holds your private key.
• -validity 825: how long the self-signed placeholder certificate inside the keystore is valid. The signed certificate from the CA replaces it later, so this value does not affect production lifetime.

keytool then prompts for a keystore password. Choose a strong password and store it in your secrets manager. You will need it for every later keytool command and for any server that consumes the keystore. With PKCS12 keystores, the key password equals the keystore password, so there is only one password to remember.

Step 2: Enter your organization details (DN)

keytool now asks for the Distinguished Name (DN): the identity fields that will appear in the CSR. Answer each prompt with the exact legal value for your organization. Use standard ASCII characters only: non-Latin letters break the request. Punctuation matters too, since the CA matches your values against public business records.

• What is your first and last name? This is keytool’s wording for the Common Name (CN). Enter the exact FQDN you want to secure (for example www.yoursite.com), or a wildcard such as *.yoursite.com. Do not enter a person’s name.
• What is the name of your organizational unit? Leave this field blank and press Enter. The CA/Browser Forum retired the organizationalUnitName attribute on 2022-09-01, and public CAs strip it from issued certificates.
• What is the name of your organization? Enter the full legal name of your company, exactly as registered (for example Your Company LLC). Required for OV and EV certificates; for Domain Validation (DV) certificates the value is ignored, so any short placeholder works.
• What is the name of your city or locality? Write the full city name where your company is registered (for example Seattle, not SEA).
• What is the name of your state or province? Enter the full state or province name (for example California, not CA).
• What is the two-letter country code for this unit? Enter the two-letter ISO 3166-1 alpha-2 code (for example US, GB, DE). See the official ISO list if you are unsure.

keytool prints the assembled DN and asks Is CN=…, OU=…, O=…, L=…, ST=…, C=… correct? Type yes and press Enter to confirm. If you spot a typo, type no and keytool restarts the prompts.

Step 3: Export the CSR with a Subject Alternative Name

Now export the CSR with keytool -certreq. Every public CA validates the hostname against the Subject Alternative Name (SAN) extension, not against the Common Name (browsers and modern TLS libraries stopped checking the CN years ago), so include a SAN even for a single hostname. Use the same alias you set in Step 1:

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

On Windows, the same command on one line:

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

Add one DNS: entry per hostname for a multi-domain certificate (separate them with commas, no spaces). For a wildcard, use DNS:*.yoursite.com. keytool prompts for the keystore password, then writes the CSR to certreq.csr in your current directory.

Step 4: Open the CSR and submit it to the CA

Open certreq.csr in any text editor (Notepad, TextEdit, nano, vim). You can also print it to the terminal:

cat certreq.csr

On Windows Command Prompt:

type certreq.csr

You will see a block that looks like this:

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

Select the entire block, including the BEGIN NEW CERTIFICATE REQUEST and END NEW CERTIFICATE REQUEST lines (some CAs label them BEGIN CERTIFICATE REQUEST / END CERTIFICATE REQUEST: either label is accepted). Copy it and paste it into the CSR field on your order form.

Check the CSR before you submit it (optional)

It is worth confirming the Common Name, SAN entries, and key size before you send the request to the CA. keytool prints the same information against the keystore entry:

keytool -printcertreq -file certreq.csr

Prefer an online tool? Paste the contents of the request into SSL Dragon’s CSR Decoder to read back the subject, the SAN list, and the public-key parameters. Confirm that the Common Name matches the hostname clients will use and that every required name appears under the Subject Alternative Name list.

Will Android trust the issued certificate?

Yes, for any certificate signed by a publicly trusted CA. Android ships a system store of root certificates that mirrors the major browser trust lists, so a certificate issued under one of those roots is trusted by Chrome, WebView, and any app that uses the system trust store, with no extra configuration.

Two caveats worth knowing if you are also installing the certificate (or a private CA root) on the device itself:

• User-installed CAs are ignored by apps on Android 7 and later. Since Android 7 (Nougat), only the system store is trusted by app traffic by default, and Google Chrome ignores user-installed CAs as well. If your app must trust a private CA, the developer has to opt in through a network security configuration that includes <certificates src="user" />. Public-CA certificates do not need this: they live in the system store already.
• Pin to a stable identifier, not to a single certificate. If you implement certificate pinning in your app, pin to the public-key SPKI hash or to the issuing CA, not to a specific leaf certificate. Otherwise the next renewal will lock users out.

Next steps

After the CA validates the CSR and issues your certificate, import the issued certificate back into the same keystore (under the same alias), then deploy the keystore to the server that Android clients will reach. See our Android SSL installation guide for the device-side install steps, or the platform-specific install guides under how to install an SSL certificate if your back end runs on Tomcat, JBoss, Nginx, or another server.