Comment générer une CSR sur Android

Ce tutoriel vous montre comment générer une CSR (Certificate Signing Request) pour Android avec l’utilitaire Java keytool.

Android ne génère pas de CSR TLS de CA publique directement sur le téléphone : un certificat de CA publique est émis pour un serveur (ou un appareil contrôlé par l’utilisateur), et les applications et navigateurs Android l’utilisent ensuite. Le processus keytool ci-dessous produit une requête PKCS #10 à partir d’un keystore Java, ce qui est la bonne approche lorsque vous avez besoin d’un certificat TLS auquel une application Android ou un site web ciblant les mobiles fera confiance.

Choisissez la bonne procédure pour votre cas

« CSR pour Android » peut désigner trois choses différentes. Assurez-vous d’être sur la bonne page avant d’exécuter la moindre commande :

• Un certificat TLS pour un serveur auquel les clients Android se connecteront. C’est le cas le plus courant, et le reste de cette page le couvre. Utilisez keytool (ci-dessous) ou générez la CSR hors serveur avec notre générateur de CSR, puis installez le certificat émis sur le serveur web, la passerelle API ou le broker MQTT que votre application contacte.
• Une clé de signature pour un APK ou un AAB. La signature d’applications Android utilise une clé RSA ou EC auto-signée dans un keystore Java : aucune CA publique n’est impliquée et il n’y a pas de CSR à soumettre. Générez la clé avec keytool depuis l’assistant Build > Generate Signed Bundle / APK d’Android Studio (ou exécutez keytool manuellement), puis enregistrez la clé auprès de Google Play App Signing. Ne commandez pas de certificat public pour cela.
• Un certificat d’appareil déployé par un MDM ou un EMM. Android Enterprise émet des certificats client vers les appareils gérés via SCEP, EST ou l’API Managed Configurations. La CSR est générée et le certificat installé automatiquement par le MDM. Aucune étape manuelle avec keytool n’est nécessaire.

Si votre cas correspond au premier, continuez. Le processus comporte deux parties : créer un keystore PKCS12 qui contient la clé privée, puis exporter la CSR à partir de ce keystore.

Ce dont vous aurez besoin

• Une installation Java (JDK ou JRE) pour que la commande keytool soit disponible dans votre PATH. Vérifiez avec keytool -help. Sous Windows, le dossier bin de Java doit figurer dans le PATH, ou vous pouvez exécuter keytool directement depuis le répertoire bin du JDK.
• Le nom de domaine pleinement qualifié (FQDN) exact que vous souhaitez sécuriser (par exemple www.yoursite.com), ainsi que tout autre nom d’hôte que vous souhaitez inclure sur le même certificat (pour la liste Subject Alternative Name).
• Les informations légales de votre organisation (pays, état, ville, nom de l’organisation) pour le Distinguished Name. Utilisez les valeurs exactement telles qu’elles figurent dans les registres publics de votre entreprise : la CA rejettera toute incohérence.

Étape 1 : créer le keystore et la clé privée

Si vous avez déjà généré votre CSR, passez directement à soumettre la CSR, puis aux instructions d’installation SSL pour Android.

Ouvrez un terminal (ou l’invite de commandes sous Windows) et exécutez la commande keytool ci-dessous. Elle crée un nouveau keystore au format PKCS12, génère une paire de clés RSA de 2048 bits à l’intérieur, et stocke la clé sous l’alias de votre choix. PKCS12 est le format de keystore par défaut depuis JDK 9 ; l’ancien format JKS est déprécié et doit être évité pour de nouvelles clés.

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

Sous Windows, la même commande sur une seule ligne se présente ainsi (notez le chemin absolu pour pouvoir retrouver le fichier ensuite) :

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

Ce que font les options :

• -alias myalias : le nom de l’entrée dans le keystore. Choisissez un libellé que vous reconnaîtrez et notez-le. Vous devez réutiliser exactement cet alias lorsque vous exportez la CSR, puis à nouveau lorsque vous importez le certificat signé.
• -keyalg RSA -keysize 2048 : une clé RSA de 2048 bits est le minimum public actuellement accepté par toutes les CA. Utilisez 3072 bits pour une clé à durée de vie plus longue, ou générez une clé ECDSA avec -keyalg EC -groupname secp256r1 pour une clé plus petite et plus rapide (toutes les CA modernes émettent des certificats ECDSA P-256 et P-384).
• -storetype PKCS12 : impose le keystore moderne PKCS12. L’extension correspondante est .p12 (ou .pfx).
• -keystore yoursite.p12 : le fichier keystore à créer. Remplacez le nom par quelque chose dont vous vous souviendrez, et conservez le fichier en lieu sûr : il contient votre clé privée.
• -validity 825 : la durée de validité du certificat auto-signé provisoire présent dans le keystore. Le certificat signé par la CA le remplacera plus tard, donc cette valeur n’affecte pas la durée de vie en production.

keytool vous demande ensuite un mot de passe de keystore. Choisissez un mot de passe fort et enregistrez-le dans votre gestionnaire de secrets. Vous en aurez besoin pour chaque commande keytool ultérieure et pour tout serveur qui utilisera le keystore. Avec les keystores PKCS12, le mot de passe de la clé est identique à celui du keystore, il n’y a donc qu’un seul mot de passe à retenir.

Étape 2 : saisir les informations de votre organisation (DN)

keytool demande maintenant le Distinguished Name (DN) : les champs d’identité qui apparaîtront dans la CSR. Répondez à chaque invite avec la valeur légale exacte de votre organisation. N’utilisez que des caractères ASCII standard : les lettres non latines invalident la requête. La ponctuation compte également, car la CA compare vos valeurs aux registres publics de votre entreprise.

• What is your first and last name? C’est la formulation de keytool pour le Common Name (CN). Saisissez le FQDN exact que vous souhaitez sécuriser (par exemple www.yoursite.com), ou un wildcard tel que *.yoursite.com. Ne saisissez pas le nom d’une personne.
• What is the name of your organizational unit? Le CA/Browser Forum a retiré l’attribut organizationalUnitName le 1er septembre 2022, et les CA publiques le suppriment des certificats émis. Notez qu’appuyer sur Entrée ne laisse pas le champ vide : keytool substitue sa propre valeur par défaut, si bien que le DN finit par contenir OU=Unknown, valeur qui se retrouve ensuite dans la CSR. Pour omettre réellement cet attribut, ignorez les invites et transmettez le DN directement avec -dname, en omettant OU de la chaîne.
• What is the name of your organization? Saisissez le nom légal complet de votre entreprise, exactement tel qu’il est enregistré (par exemple Your Company LLC). Requis pour les certificats OV et EV ; pour les certificats de validation de domaine (DV), la valeur est ignorée, donc tout court libellé fonctionne.
• What is the name of your city or locality? Écrivez le nom complet de la ville où votre entreprise est enregistrée (par exemple Seattle, pas SEA).
• What is the name of your state or province? Saisissez le nom complet de l’état ou de la province (par exemple California, pas CA).
• What is the two-letter country code for this unit? Saisissez le code ISO 3166-1 alpha-2 à deux lettres (par exemple US, GB, DE). Consultez la liste officielle ISO en cas de doute.

keytool affiche le DN assemblé et demande Is CN=…, OU=…, O=…, L=…, ST=…, C=… correct? Tapez yes et appuyez sur Entrée pour confirmer. Si vous repérez une faute de frappe, tapez no et keytool relance les invites.

Étape 3 : exporter la CSR avec un Subject Alternative Name

Exportez maintenant la CSR avec keytool -certreq. Chaque CA publique valide le nom d’hôte par rapport à l’extension Subject Alternative Name (SAN), et non par rapport au Common Name (les navigateurs et les bibliothèques TLS modernes ont cessé de vérifier le CN depuis des années), donc incluez un SAN même pour un seul nom d’hôte. Utilisez le même alias que celui défini à l’étape 1 :

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

Sous Windows, la même commande sur une seule ligne :

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

Ajoutez une entrée DNS: par nom d’hôte pour un certificat multi-domaines (séparez-les par des virgules, sans espaces). Pour un wildcard, utilisez DNS:*.yoursite.com. keytool demande le mot de passe du keystore, puis écrit la CSR dans certreq.csr dans votre répertoire courant.

Étape 4 : ouvrir la CSR et la soumettre à la CA

Ouvrez certreq.csr dans n’importe quel éditeur de texte (Notepad, TextEdit, nano, vim). Vous pouvez aussi l’afficher dans le terminal :

cat certreq.csr

Sous l’invite de commandes Windows :

type certreq.csr

Vous verrez un bloc qui ressemble à ceci :

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

Sélectionnez le bloc entier, y compris les lignes BEGIN NEW CERTIFICATE REQUEST et END NEW CERTIFICATE REQUEST (certaines CA les nomment BEGIN CERTIFICATE REQUEST / END CERTIFICATE REQUEST : les deux libellés sont acceptés). Copiez-le et collez-le dans le champ CSR de votre formulaire de commande.

Vérifier la CSR avant de la soumettre (facultatif)

Il est utile de vérifier le Common Name, les entrées SAN et la taille de la clé avant d’envoyer la requête à la CA. keytool affiche les mêmes informations à partir de l’entrée du keystore :

keytool -printcertreq -file certreq.csr

Vous préférez un outil en ligne ? Collez le contenu de la requête dans le décodeur de CSR de SSL Dragon pour relire le sujet, la liste SAN et les paramètres de la clé publique. Vérifiez que le Common Name correspond au nom d’hôte que les clients utiliseront et que chaque nom requis figure bien dans la liste Subject Alternative Name.

Android fera-t-il confiance au certificat émis ?

Oui, pour tout certificat signé par une CA de confiance publique. Android intègre un magasin système de certificats racine qui reflète les listes de confiance des principaux navigateurs, de sorte qu’un certificat émis sous l’une de ces racines est reconnu par Chrome, WebView et toute application utilisant le magasin de confiance du système, sans configuration supplémentaire.

Deux points à connaître si vous installez également le certificat (ou une racine de CA privée) sur l’appareil lui-même :

• Les CA installées par l’utilisateur sont ignorées par les applications sur Android 7 et ultérieur. Depuis Android 7 (Nougat), seul le magasin système est approuvé par défaut pour le trafic des applications, et Google Chrome ignore lui aussi les CA installées par l’utilisateur. Si votre application doit faire confiance à une CA privée, le développeur doit l’activer explicitement via une network security configuration incluant <certificates src="user" />. Les certificats de CA publique n’en ont pas besoin : ils sont déjà présents dans le magasin système.
• Épinglez un identifiant stable, pas un certificat unique. Si vous mettez en œuvre le certificate pinning dans votre application, épinglez le hash SPKI de la clé publique ou la CA émettrice, et non un certificat feuille spécifique. Sinon, le prochain renouvellement bloquera vos utilisateurs.

Étapes suivantes

Une fois que la CA a validé la CSR et émis votre certificat, réimportez le certificat émis dans le même keystore (sous le même alias), puis déployez le keystore sur le serveur que les clients Android atteindront. Consultez notre guide d’installation SSL pour Android pour les étapes d’installation côté appareil, ou les guides d’installation spécifiques à chaque plateforme sous comment installer un certificat SSL si votre back-end fonctionne sous Tomcat, JBoss, Nginx, ou un autre serveur.