Vous ne pouvez pas faire ça avec keytool. Tout d'abord, keytool
ne prend pas en charge DH du tout. Deuxièmement, keytool
ne génère pas de paramètres par lui-même pour aucun algorithme, uniquement une clé privée / paire de clés. Troisièmement, lorsqu'il keytool
génère une paire de clés, il génère également un certificat auto-signé (qui est parfois remplacé par la suite par un "vrai" certificat émis par l'autorité de certification) et il est impossible de générer un certificat auto-signé pour DH car DH ne signe pas. Vous pouvez écrire un programme Java très simple (environ 10 lignes) pour générer des paramètres DH. Mais cela ne vous ferait probablement aucun bien car:
De toute façon, Java n'accepte pas les paramètres DHE ici. JbossWS (le serveur Web Jboss, plus tard Wildfly) est un fork de Tomcat, et utilise normalement l'implémentation Java de SSL / TLS, JSSE. Jusqu'à Java 7, JSSE utilise ses propres paramètres DHE qui sont de 768 bits, ce qui est trop faible. (Sauf pour les suites EXPORT où JSSE obéit à l'exigence RFC pour DH-512, qui est totalement cassée, mais les suites EXPORT sont de toute façon totalement cassées par conception, et désactivées par défaut dans Java 7 et versions ultérieures.) Java 8 JSSE vous permet de contrôler la taille des paramètres DHE, mais pas la valeur réelle.
Vos options (qui se chevauchent) sont:
Utilisez Java 8. JSSE dans Java 8, mais pas avant, par défaut DHE à 1024 bits, ce que la plupart des autorités considèrent comme assez fort même si faiblessedh.org ne le fait pas, et vous permet de spécifier plus, voir https://docs.oracle.com /javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#customizing_dh_keys et pour le fond /programming/30352105/how-to-set-custom-dh-group-in-java -sslengine-to-prevent-logjam-attack . Notez que si vous avez des clients Java avant Java 8, ils échoueront si le serveur utilise DHE sur 1024 bits. Je ne connais aucun autre client qui a ce problème, mais testez le vôtre avant de vous engager dans ce changement.
Activez ECDHE. JSSE dans Java 7 et versions ultérieures implémente ECDHE, qui n'est pas soumis à un pré-calcul comme DHE, (normalement) en utilisant P-256, qui est plus que suffisamment puissant. (Bien que certaines personnes ne fassent confiance à aucune des courbes ECC du NIST parce que le NIST en général est influencé par la NSA, bien qu'aucune source ouverte que je connaisse n'a montré de problème dans les courbes ECC en particulier.) Java 6 a en fait la partie JSSE pour ECDHE mais il n'est activé que si la JVM a un "fournisseur" de crypto pour les primitives ECC, ce que Java 6 n'a pas. bcprov - * - jdk15on de http://www.bouncycastle.org/ est un fournisseur JCE pour une gamme de primitives de chiffrement Java, y compris ECC, donc si vous ajoutez le pot à votre JRE/lib/ext
et ajoutez org.bouncycastle.jce.provider.BouncyCastleProvider
à la liste dans JRE/lib/security/java.security
(ou faites unSecurity.add/insertProvider()
quelque part au début de votre code) Java 6 peut faire ECDHE. Bien sûr, si vous devriez avoir un Java 6 encore utilisé, c'est une question en soi.
Il y a quelques années, la prise en charge d'ECDHE dans les navigateurs et autres clients était incertaine, mais aujourd'hui, AFAIK tous les navigateurs à jour la prennent en charge et la préfèrent à DHE - c'est-à-dire que le navigateur répertorie les suites ECDHE avant les suites DHE afin que si le serveur implémente les deux, il doit choisir ECDHE. Les clients sans navigateur peuvent ne pas l'être; test pour être certain.
Désactivez DHE. Vous pouvez configurer la liste des chiffres dans l'attribut Connector pour exclure les chiffres DHE; pendant que vous y êtes, excluez également staticDH et staticECDH qui sont inutiles, et (unique) DES et (tous) "EXPORT" s'ils sont présents (Java 6). Cela signifie que les navigateurs et les clients qui ne font pas ECHDE seront bloqués avec plain-RSA et pas de secret en amont, mais au moins ils ont un secret "actuel". Je ne me souviens pas avec certitude, mais je pense que la configuration du connecteur 5.1 était encore quelque part $server/deploy/jbossweb/server.xml
.
Essayez natif. Tomcat, qui, comme je l'ai dit, a commencé avec JbossWS, a une option pour implémenter HTTPS (SSL / TLS) en utilisant "native" aka "APR" qui est en fait OpenSSL à l'intérieur plutôt que JSSE. J'ai eu un succès mitigé à faire fonctionner cette option sur JbossWS, et je ne me souviens pas de la 5.1. Si votre JbossWS dispose d'une option native compatible TC et s'il peut gérer la configuration des paramètres DH, utilisez openssl pour générer les paramètres DH et les instructions natives JbossWS pour les configurer.