Cómo generar un CSR en Android

Este tutorial te muestra cómo generar un CSR (Certificate Signing Request) para Android con la utilidad keytool de Java.

Android no genera CSRs de TLS de CA pública en el propio teléfono: un certificado de CA pública se emite para un servidor (o un dispositivo que el usuario controla), y las aplicaciones y navegadores de Android lo consumen. El flujo de keytool que se describe a continuación produce una solicitud PKCS #10 a partir de un almacén de claves Java, que es el camino correcto cuando necesitas un certificado TLS que una aplicación de Android o un sitio web orientado a móviles pueda confiar.

Elige el procedimiento correcto para tu caso

«CSR para Android» puede significar tres cosas diferentes. Asegúrate de estar en la página correcta antes de ejecutar cualquier comando:

• Un certificado TLS para un servidor con el que se comunicarán los clientes de Android. Este es el caso más común, y el resto de esta página lo cubre. Usa keytool (a continuación) o genera el CSR fuera del servidor con nuestro Generador de CSR, y luego instala el certificado emitido en el servidor web, la puerta de enlace API o el broker MQTT al que se conecta tu aplicación.
• Una clave de firma para un APK o AAB. La firma de aplicaciones de Android utiliza una clave RSA o EC autofirmada en un almacén de claves Java: no interviene ninguna CA pública ni hay ningún CSR que enviar. Genera la clave con keytool desde el asistente Build > Generate Signed Bundle / APK de Android Studio (o ejecuta keytool manualmente), y luego registra la clave con Google Play App Signing. No solicites un certificado público para esto.
• Un certificado de dispositivo provisto por un MDM o EMM. Android Enterprise emite certificados de cliente a dispositivos gestionados a través de SCEP, EST o la Managed Configurations API. El CSR se genera y el certificado se instala automáticamente mediante el MDM. No hay ningún paso manual con keytool.

Si tu caso es el primero, continúa. El flujo tiene dos partes: crear un almacén de claves PKCS12 que contenga la clave privada, y luego exportar el CSR desde ese almacén de claves.

Lo que necesitarás

• Una instalación de Java (JDK o JRE) para que el comando keytool esté disponible en tu PATH. Confírmalo con keytool -help. En Windows, la carpeta bin de Java debe estar en el PATH, o puedes ejecutar keytool directamente desde el directorio bin del JDK.
• El nombre de dominio completamente calificado (FQDN) exacto que deseas proteger (por ejemplo, www.yoursite.com), además de cualquier otro nombre de host que quieras incluir en el mismo certificado (para la lista de Subject Alternative Name).
• Los datos legales de tu organización (país, estado, ciudad, nombre de la organización) para el Distinguished Name. Usa los valores exactamente como aparecen en los registros comerciales públicos: la CA rechazará las discrepancias.

Paso 1: Crea el almacén de claves y la clave privada

Si ya generaste tu CSR, salta directamente a enviar el CSR y luego a las instrucciones de instalación de SSL para Android.

Abre una terminal (o el Símbolo del sistema en Windows) y ejecuta el comando keytool que se muestra a continuación. Este crea un nuevo almacén de claves en formato PKCS12, genera un par de claves RSA de 2048 bits dentro de él, y almacena la clave bajo el alias que elijas. PKCS12 ha sido el formato de almacén de claves predeterminado desde JDK 9; el formato JKS, más antiguo, está obsoleto y debe evitarse para claves nuevas.

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

En Windows, el mismo comando en una sola línea se ve así (ten en cuenta la ruta absoluta para poder encontrar el archivo de nuevo):

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

Qué hacen los parámetros:

• -alias myalias: el nombre de la entrada dentro del almacén de claves. Elige una etiqueta que reconozcas y anótala. Debes reutilizar este alias exacto cuando exportes el CSR y de nuevo cuando importes el certificado firmado.
• -keyalg RSA -keysize 2048: una clave RSA de 2048 bits es el mínimo público actual que aceptan todas las CA. Usa 3072 bits para una clave de vida más larga, o genera una clave ECDSA con -keyalg EC -groupname secp256r1 para obtener una clave más pequeña y rápida (todas las CA modernas emiten certificados con ECDSA P-256 y P-384).
• -storetype PKCS12: fuerza el uso del moderno almacén de claves PKCS12. La extensión correspondiente es .p12 (o .pfx).
• -keystore yoursite.p12: el archivo de almacén de claves que se creará. Reemplaza el nombre por algo que recuerdes, y mantén el archivo a salvo: contiene tu clave privada.
• -validity 825: cuánto tiempo es válido el certificado autofirmado de marcador de posición dentro del almacén de claves. El certificado firmado de la CA lo reemplaza más adelante, por lo que este valor no afecta la vida útil en producción.

keytool solicitará entonces una contraseña del almacén de claves. Elige una contraseña segura y guárdala en tu gestor de secretos. La necesitarás para cada comando keytool posterior y para cualquier servidor que consuma el almacén de claves. Con los almacenes de claves PKCS12, la contraseña de la clave es igual a la contraseña del almacén de claves, por lo que solo hay una contraseña que recordar.

Paso 2: Introduce los datos de tu organización (DN)

keytool ahora solicita el Distinguished Name (DN): los campos de identidad que aparecerán en el CSR. Responde a cada solicitud con el valor legal exacto de tu organización. Usa solo caracteres ASCII estándar: las letras no latinas rompen la solicitud. La puntuación también importa, ya que la CA compara tus valores con los registros comerciales públicos.

• ¿Cuáles son su nombre y apellido? Así es como keytool denomina al Common Name (CN). Introduce el FQDN exacto que deseas proteger (por ejemplo, www.yoursite.com), o un comodín como *.yoursite.com. No introduzcas el nombre de una persona.
• ¿Cuál es el nombre de su unidad organizativa? El CA/Browser Forum retiró el atributo organizationalUnitName el 01/09/2022, y las CA públicas lo eliminan de los certificados emitidos. Ten en cuenta que pulsar Enter no deja el campo vacío: keytool sustituye su propio valor predeterminado, por lo que el DN termina llevando OU=Unknown y ese valor pasa al CSR. Para omitir el atributo de verdad, salta las solicitudes y pasa el DN en línea con -dname, dejando el OU fuera de la cadena.
• ¿Cuál es el nombre de su organización? Introduce el nombre legal completo de tu empresa, exactamente como está registrado (por ejemplo, Your Company LLC). Es obligatorio para los certificados OV y EV; para los certificados de Validación de Dominio (DV) el valor se ignora, por lo que sirve cualquier marcador de posición corto.
• ¿Cuál es el nombre de su ciudad o localidad? Escribe el nombre completo de la ciudad donde está registrada tu empresa (por ejemplo, Seattle, no SEA).
• ¿Cuál es el nombre de su estado o provincia? Introduce el nombre completo del estado o provincia (por ejemplo, California, no CA).
• ¿Cuál es el código de país de dos letras para esta unidad? Introduce el código ISO 3166-1 alpha-2 de dos letras (por ejemplo, US, GB, DE). Consulta la lista oficial de ISO si tienes dudas.

keytool imprime el DN ensamblado y pregunta ¿Es correcto CN=…, OU=…, O=…, L=…, ST=…, C=…? Escribe yes y pulsa Enter para confirmar. Si detectas un error tipográfico, escribe no y keytool reinicia las solicitudes.

Paso 3: Exporta el CSR con un Subject Alternative Name

Ahora exporta el CSR con keytool -certreq. Todas las CA públicas validan el nombre de host contra la extensión Subject Alternative Name (SAN), no contra el Common Name (los navegadores y las bibliotecas TLS modernas dejaron de verificar el CN hace años), así que incluye un SAN incluso para un solo nombre de host. Usa el mismo alias que estableciste en el Paso 1:

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

En Windows, el mismo comando en una sola línea:

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

Añade una entrada DNS: por cada nombre de host para un certificado multidominio (sepáralos con comas, sin espacios). Para un comodín, usa DNS:*.yoursite.com. keytool solicitará la contraseña del almacén de claves y luego escribirá el CSR en certreq.csr en tu directorio actual.

Paso 4: Abre el CSR y envíalo a la CA

Abre certreq.csr en cualquier editor de texto (Bloc de notas, TextEdit, nano, vim). También puedes imprimirlo en la terminal:

cat certreq.csr

En el Símbolo del sistema de Windows:

type certreq.csr

Verás un bloque similar a este:

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

Selecciona el bloque completo, incluidas las líneas BEGIN NEW CERTIFICATE REQUEST y END NEW CERTIFICATE REQUEST (algunas CA las etiquetan como BEGIN CERTIFICATE REQUEST / END CERTIFICATE REQUEST: ambas etiquetas son aceptadas). Cópialo y pégalo en el campo de CSR de tu formulario de pedido.

Verifica el CSR antes de enviarlo (opcional)

Vale la pena confirmar el Common Name, las entradas SAN y el tamaño de clave antes de enviar la solicitud a la CA. keytool imprime la misma información a partir de la entrada del almacén de claves:

keytool -printcertreq -file certreq.csr

¿Prefieres una herramienta en línea? Pega el contenido de la solicitud en el Decodificador de CSR de SSL Dragon para leer el asunto, la lista SAN y los parámetros de la clave pública. Confirma que el Common Name coincida con el nombre de host que usarán los clientes y que todos los nombres necesarios aparezcan en la lista Subject Alternative Name.

¿Confiará Android en el certificado emitido?

Sí, para cualquier certificado firmado por una CA de confianza pública. Android incluye un almacén del sistema de certificados raíz que refleja las principales listas de confianza de los navegadores, por lo que un certificado emitido bajo una de esas raíces es de confianza para Chrome, WebView y cualquier aplicación que use el almacén de confianza del sistema, sin necesidad de configuración adicional.

Vale la pena tener en cuenta dos advertencias si también estás instalando el certificado (o una raíz de CA privada) en el propio dispositivo:

• Las CA instaladas por el usuario son ignoradas por las aplicaciones en Android 7 y versiones posteriores. Desde Android 7 (Nougat), solo se confía por defecto en el almacén del sistema para el tráfico de las aplicaciones, y Google Chrome también ignora las CA instaladas por el usuario. Si tu aplicación necesita confiar en una CA privada, el desarrollador debe habilitarlo mediante una configuración de seguridad de red que incluya <certificates src="user" />. Los certificados de CA pública no necesitan esto: ya residen en el almacén del sistema.
• Fija un identificador estable, no un único certificado. Si implementas certificate pinning en tu aplicación, fija el hash SPKI de la clave pública o la CA emisora, no un certificado hoja específico. De lo contrario, la próxima renovación bloqueará a los usuarios.

Próximos pasos

Después de que la CA valide el CSR y emita tu certificado, importa el certificado emitido de vuelta al mismo almacén de claves (bajo el mismo alias), y luego despliega el almacén de claves en el servidor al que se conectarán los clientes de Android. Consulta nuestra guía de instalación de SSL para Android para conocer los pasos de instalación en el dispositivo, o las guías de instalación específicas de cada plataforma en cómo instalar un certificado SSL si tu back end se ejecuta en Tomcat, JBoss, Nginx u otro servidor.