Le type de verrou acceptable peut être prédéterminé par votre administrateur système.
Où puis-je définir ce qui est acceptable ? Je peux régénérer le certificat si nécessaire.
Donc je peux à nouveau utiliser le verrouillage par glissement.
(Je suis sous CM9 RC1, Android 4.0.4)
J'ai décrit comment faire exactement cela sur ma page, "Installation de certificats CAcert sur Android en tant que credentials 'system' sans écran de verrouillage - instructions" sur http://wiki.pcprobleemloos.nl/android/cacert
Je l'ai également posté sur le forum cyanogenmod : http://forum.cyanogenmod.com/topic/82875-installing-cacert-certificates-on-android-as-system-credentials-without-lockscreen/
Essentiellement, les commandes sont :
openssl x509 -inform PEM -subject_hash_old -in root.crt | head -1Pour obtenir le nom de fichier correct, puis convertir le certificat :
cat root.crt > 5ed36f99.0
openssl x509 -inform PEM -text -in root.crt -out /dev/null >> 5ed36f99.0Les copier dans /system/etc/security/cacerts/ et chmod les nouveaux fichiers .0 en '644'. Redémarrez et vérifiez. Sur votre appareil android, sélectionnez 'Effacer les certificats' et vous pourrez supprimer le code PIN (en entrant le code PIN et en changeant l'écran de verrouillage en 'aucun' ou 'effacer').
Ici j'ai utilisé le certificat racine CAcert, mais vous voudrez probablement aussi le certificat class3.crt, ou utilisez vos propres certificats.
Vous mentionnez "vos propres certificats". J'ai essayé avec mon "CA" (créé avec TinyCA), et dans la dernière étape ("inform"), je reçois une erreur : 140342119224992:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:696:Expecting: TRUSTED CERTIFICATE. En consultant Unable to load certificate in openssl, le fichier .pem devrait correspondre. Mais ensuite, votre dernière commande ne change rien. Est-ce normal pour un CA auto-signé/créé, ou est-ce qu'il y a quelque chose qui ne va pas? Avant de commencer à bidouiller : est-ce que cela devrait fonctionner malgré tout?
D'accord, cela a fonctionné et a été accepté avec mon CA TinyCA que j'ai créé moi-même : openssl x509 -inform PEM -text -fingerprint -in cacert.pem > d6a2705a.0, puis en déplaçant le bloc base64 vers le haut en utilisant un éditeur de texte, en plaçant le fichier dans /system/etc/security/cacerts/, en exécutant chown root:root d6a2705a.0 et chmod 0644 d6a2705a.0 à partir du répertoire - et voilà, il apparaît comme un certificat système de confiance. Yeehaa!
@sgiebels Auriez-vous par hasard également une solution pour utiliser des identifiants (des identifiants système ou autres) dans une connexion WLAN 802.1X? Il semble que le trousseau de clés sur l'appareil (/data/misc/key...) utilise le mot de passe pour le chiffrement, donc : chaque fois que les identifiants sont nécessaires (connexion au WLAN), le NIP/mot de passe est de nouveau demandé et (dans mon système) le verrouillage est à nouveau activé.
J'ai découvert une solution qui fonctionne sans logiciel supplémentaire ni copie manuelle de fichiers :
Le système est désormais réglé sur "Déverrouillage par balayage", mais le certificat d'utilisateur est toujours utilisable (testé avec le navigateur web et une application personnalisée utilisant DefaultHttpClient).
Testé sur un Android 4.1.2 sur une Galaxy Tab 2 10.1.
Le problème avec la désactivation de la sécurité de l'écran de verrouillage en utilisant le basculement du profil est que les widgets de l'écran de verrouillage n'apparaissent pas non plus, donc vous ne pouvez pas faire glisser pour déverrouiller. De plus, lorsque vous redémarrez votre téléphone, les boutons ne fonctionnent pas tant que vous n'avez pas basculé à nouveau le paramètre.
Une autre solution consiste à installer le certificat comme d'habitude, puis à sauvegarder les répertoires /data/misc/keychain et keystore à l'aide d'un outil conservant les ACL comme Root Explorer dans un emplacement prenant en charge les ACL. Je suggère de les copier dans /tmp. Ensuite, effacez les informations d'identification dans les paramètres et activez le glisser pour déverrouiller. Ensuite, copiez à nouveau les dossiers depuis /tmp. Le certificat sera installé.
Cela ne fonctionne plus. Dès que vous essayez d'utiliser le certificat quelque part (comme pour vous connecter à un réseau wifi), le système d'exploitation vous demande de verrouiller à nouveau l'écran.
@CoryKlein Si vous cliquez sur Annuler, il vous sera demandé d'entrer un NIP et vous pouvez entrer le dernier que vous avez défini. Il est nécessaire pour décrypter les données.
@Kurian - Alors j'ai suivi les instructions ci-dessus, et quand j'essaie de me connecter à un réseau wifi, il me dit "Vous devez définir un code PIN de verrouillage de l'écran", je clique sur "Annuler", et rien ne se passe. Si je clique sur "Ok" puis j'annule à partir de là, il ne demande toujours pas le code PIN.
Je voulais simplement ajouter une réponse qui est une variante de celle de guttermonk pour un cas d'utilisation particulier : installer un certificat sur une instance Bluestacks. Au moment de l'écriture, l'application de configuration de Bluestacks a été modifiée de sorte qu'il est impossible de définir un code PIN ou un mot de passe, et donc impossible d'ajouter un certificat utilisateur. Mais nous pouvons obtenir un certificat racine dans le système avec l'approche de guttermonk ainsi que quelques autres étapes. J'ai pu installer un certificat sans code PIN ni mot de passe et sans jamais l'installer dans le magasin de certificats de l'utilisateur.
Prérequis :
Dans mon cas, j'avais téléchargé le fichier de certificat à l'intérieur de Bluestacks et je n'avais pas openssl disponible là-bas. Nous pouvons copier le fichier dans le répertoire partagé avec Windows :
cp /sdcard/Download/mycert.cer /sdcard/windows/BstSharedFolder
Sous Windows, nous pouvons utiliser openssl pour obtenir le hachage du certificat (je suppose que c'est ce que c'est).
cd C:\ProgramData\BlueStacks\Engine\UserData\SharedFolder # dans CMD
cd /c/ProgramData/BlueStacks/Engine/UserData/SharedFolder # dans Bash
openssl x509 -inform PEM -subject_hash_old -in mycert.cer | head -1
# par exemple abcd1234De retour sur Android, nous pouvons rendre la partition système inscriptible, copier le certificat dans le répertoire des certificats système, et corriger ses permissions et sa propriété. Remonter la partition système en lecture seule par la suite, pour des raisons de sécurité.
mount -o rw,remount /system
cd /system/etc/security/cacerts/
cp /sdcard/Download/mycert.cer ./abcd1234.0
chmod 644 abcd1234.0
chown system:system abcd1234.0
mount -o ro,remount /system
Vous pouvez utiliser les profils de CyanogenMod.
(Pour les autres lecteurs : cela nécessite la version personnalisée du Rom CyanogenMod 9+)
Il suffit de créer ou de modifier un profil existant et de désactiver "verrouillage de l'écran".
C'est : Paramètres du système -> Profils -> Par défaut -> Mode de verrouillage de l'écran -> Désactivé
Intégrez votre certificat dans le fichier de trousseau de clés Android standard
Voir l'excellent tutoriel de CAcert ici
Cependant, je ne suis pas sûr si vous pouvez le faire avec un certificat auto-signé (vous devrez peut-être passer à un CA fait maison peut-être (utilisez tinyca pour un bel outil gui sur *nix)).
AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
1 votes
Je vais accepter une solution qui installe directement le certificat dans le système, contournant ainsi l'exigence du code PIN.
1 votes
Pour sécuriser vos identifiants, il est nécessaire d'utiliser l'un des types d'écrans de verrouillage qui possède un code secret (motif, NIP ou mot de passe). Ce que cette ligne vous dit, c'est que votre administrateur peut (normalement via une politique Exchange ActiveSync) verrouiller votre téléphone pour n'accepter que certains types de ces codes, par exemple ils peuvent ne pas faire confiance aux verrous à motif, et peuvent penser que les NIP à 4 chiffres n'ont pas assez de combinaisons. Ce n'est pas dire que vous pouvez désactiver cette exigence de sécurité.
2 votes
@GAThrawn Je trouve cela inacceptable si je viens d'installer un AC pour authentifier mes serveurs web via SSL (en utilisant des certificats auto-signés). Je comprendrais si cela concernait la signature des clés sur l'appareil, ou l'authentification de l'utilisateur - mais les deux vont dans l'autre sens. Heureusement, la solution de sgiebels semble fonctionner pour moi, avec quelques ajustements mineurs que j'ai décrits dans les commentaires là-bas. Seul inconvénient jusqu'à présent: cela nécessite des droits root.