Comment charger des certificates de nouvelle génération à partir du magasin de clés Microsoft à l’aide de Java 8?

J’essaie de charger des certificates directement à partir du magasin Microsoft afin d’éviter d’exporter des certificates à partir du magasin MS puis de les importer dans un magasin JKS.

J’ai réussi à obtenir des certificates créés à partir d’un modèle de serveur Web AD CS typique à l’aide de la technologie de chiffrement héritée directement à partir des magasins MS à l’aide de SunMSCAPI.

Cependant, SunMSCAPI ne prend pas en charge les chiffrements CNG modernes que j’utilise, en particulier le chiffrement asymésortingque RSA-2048, le hachage SHA-384 et la signature numérique ECDSA-384.

Est-il possible de charger des certificates Next Generation à partir de magasins MS en utilisant Java? Je suis sur jdk1.8.0_45. Existe-t-il une alternative au fournisseur JCE standard de SunMSCAPI capable de gérer le GNC? Je pense qu’il faudrait utiliser JNI ou JNA pour accéder à l’API Windows CNG native.

J’ai essayé Pheox JCAPI sans succès. Il prend en charge RSA et DSA, mais pas ECDSA. Je n’ai pas essayé Bouncy Castle, mais d’après ce que je comprends, il n’offre pas une telle capacité.

Existe-t-il d’autres solutions de remplacement du fournisseur JCE sur le marché que SunMSCAPI pouvant gérer le GNC que je pourrais essayer?

Mise à jour: JCAPI v2 ne prend en charge que le support RSA, ECDH prévu pour la v3 l’année prochaine.

Mise à jour: Certains ont suggéré que l’installation des fichiers de règles de juridiction JCE (Java Cryptography Extension) pour Java 8 pourrait résoudre ce problème, mais non, cela n’aide pas, puisque le problème est que SunMSCAPI ne prend en charge que les chiffrements RSA. en regardant le code source .

Comme déjà mentionné, ce n’est pas (encore) possible avec SunMSCAPI. En fait, il y a une demande d’amélioration ouverte, où l’on peut voter pour que le problème soit résolu.

Issue here: https://bugs.openjdk.java.net/browse/JDK-8026953

La spécification indique

En raison des réglementations d’importation de certains pays, l’implémentation Oracle fournit un fichier de stratégie de juridiction cryptographique par défaut qui limite la force des algorithmes cryptographiques.

Si des algorithmes plus puissants sont nécessaires (par exemple, AES avec des clés de 256 bits), les fichiers de règles de juridiction JCE Unlimited Strength doivent être obtenus et installés dans le JDK / JRE.

Il est de la responsabilité de l’utilisateur de vérifier que cette action est autorisée par les réglementations locales.

Téléchargez les fichiers de politique juridictionnelle JCE Unlimited Strength et placez-les dans votre dossier de sécurité jre.

La prochaine génération d’API n’est pas implémentée dans le code sunmscapi c ++ – le fichier security.cpp -, qui interagit avec windows crypto api. EC n’est pas implémenté dans le code java de sunmscapi également.

Vous pouvez afficher la source à partir de openJDK ici: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/556b17038b5c/src/windows/native/sun/security/mscapi/security.cpp

Lorsque vous appelez keystore.load (null, null) à partir de votre code java, il finit par se retrouver dans la fonction de code c ++ Java_sun_security_mscapi_KeyStore_loadKeysOrCertificateChains. La ligne 383 CryptAcquireCertificatePrivateKey renvoie false, car elle n’utilise pas l’indicateur CRYPT_ACQUIRE_ALLOW_NCRYPT_KEY_FLAG. Même lorsque vous corrigez cette ligne, elle finit par tomber en panne. Comme il utilise les anciennes fonctions d’API crypto.

Le faire fonctionner signifie réécrire vous-même tous les sunmscapi, en utilisant la nouvelle génération d’API crypto.