Discussion :

[Yann39]

J'avais déjà essayé avec OraclePKI, mais je n'ai pas les droits dans la base :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ORA-29532: Java call terminated by uncaught Java exception: org.apache.commons.httpclient.HttpClientError: java.security.AccessControlException: the Permission (java.security.SecurityPermission putProviderProperty.OraclePKI) has not been granted to SURVEY. The PL/SQL to grant this is dbms_java.grant_permission( 'SURVEY', 'SYS:java.security.SecurityPermission', 'putProviderProperty.OraclePKI', '' )
ORA-06512: at "SURVEY.CREER_DOSSIER_DFS", line 1
ORA-06512: at line 9

Et quand j'ai demandé à l'admin si je pouvais avoir ce privilège, il m'a répondu :

Is this going to work ? We do not have anything to support PKI in the oracle databases at cern..

Bien tenté !

[tchize_]

bon ben reste avec ton code p12, et fourni aux admin le fichier p12 que tu ouvrira. Avoir accès en lecture à un fichier que tu as fournis sur le filesystem ne devrais pas lui causer de problèmes outre mesure

[Yann39]

J'ai déjà un fichier ewallet.p12, mais il requiert un mot de passe par rapport au sso, et je n'ai pas ce mot de passe.

Tu penses que utiliser le p12 au lieu du sso peut résoudre le problème ?

[tchize_]

en reprenant ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
     private static SSLContext createEasySSLContext() {
          try {
            Provider provider = Security.getProvider("SUN");
            KeyStore keyStore = KeyStore.getInstance("jks",provider);
            FileInputStream walletFile = new FileInputStream(leFichierJKS);
            keyStore.load(walletFile,"".toCharArray());
            walletFile.close();
            SSLContext context = SSLContext.getInstance("SSL");
            context.init(null, new TrustManager[] { new EasyX509TrustManager(keyStore) }, null);
            return context;
          } catch (Exception e) {
               throw new HttpClientError(e.toString());
          }
     }

et en ayant leFichierJKS qui pointe vers une copie du fichier lib/security/cacerts d'une java 6, je pense que tu devrais t'en sortir. Le fichier cacerts contient les certificats racines reconnus par java. En prenant une version java6 t'as un fichier récent. Ce fichier n'a pas de mot de passe (il ne contient rien de privé), le security provider jks est reconnu en base par java donc aucun droit particulier à faitre entrer en ligne de compte.

voilà, bonne chance (n'hésite pas à installer une vieille java 4 sur ton poste de travail pour faire tes tests avant d'emmm. l'admin DB )

[Yann39]

Je n'ai aucun droit de mettre un fichier sur le filesystem du serveur. Ce n'est pas toléré par les admins, même si c'est une question de vie ou de mort. (vivement que je soit admin ! ).

Tout se mélange un peu dans ma tête là, cacerts, sso, p12, pki, etc... à l'origine je pensais juste qu'en me connectant à https://... le serveur m'envoyait son certificat (avec sa clé publique) que j'avais simplement à vérifier. Mais apparement il y a un beau bordel qui va avec...
L'application étant intranet, et les utilisateurs connus, je pensais aussi que des certificats auto-signés suffiraient.

Bref ma collègue est revenue de vacances, elle à l'air de toucher un peu en services web, je vais voir si elle a une idée.

Merci de prendre de ton temps pour m'aider

[tchize_]

Tout se mélange un peu dans ma tête là, cacerts, sso, p12, pki, etc

cacerts: fichier jks contenant les autorité de certificatsion reconnues par java
p12: fichier contenant des certificat en principe privés, format java, protégé normalement par un mot de passe
pki: infrastructure à clé publique. Le SSL repose dessus, mais c'est pas ton soucis, ce sont les autorités de certifications qui gèrent ça
sso: manifestement un autre format pour les même choses que p12.

... à l'origine je pensais juste qu'en me connectant à https://... le serveur m'envoyait son certificat (avec sa clé publique) que j'avais simplement à vérifier. Mais apparement il y a un beau bordel qui va avec...

En général avec une version java a jour c'est effectivement comme ça que ça se passe, mais tes admin tournent avec un truc de matusalem qui a pas été tenu a jour. Ton serveur il va envoyer son certificat (clé publique) signée par une autorité de certification. Hors dans ton cas, l'autorité de certification en question n'est pas reconnue par java car trop récente, donc refusée.
Le fichier cacerts contient la liste des autorité de certifications, d'où ma suggestion de le copier! Puisque t'as pas d'accès physique, l'autre option gros bourrin c'est de l'embarquer dans ton code comme array de byte + bytearrayinpustream, mais c'est moche moche moche

L'application étant intranet, et les utilisateurs connus, je pensais aussi que des certificats auto-signés suffiraient.

Pour le lien que t'as donné, ce n'est pas un certificat autosigné, mais un certificat officiel. Un certificat autosigné ne sert normalement qu'en développement, il ne peut apporter aucune garantie.[/QUOTE]

[Yann39]

OK et bien merci tchize_ pour ces explications, je vais pas t'embêter plus longtemps !

Même si je n'ai pas résolu le problème je pense qu'on a bien identifié la cause et au moins je sais à quoi m'en tenir.

Je ne pense pas m'enmerder à embarqué le fichier en tant que array de byte dans le code car je sens bien la perte de temps encore !, ou bien peut-être que je peux embarquer le fichier dans la base de données (BLOB) comme je fais actuellement pour les fichiers images css et javascript utilisés par l'application.

Là j'ai d'autres choses importantes à faire, puis c'est férié jeudi, alors je testerai ça vendredi ou plus tard. Je tiendrai à jour ce topic si je trouve une solution.

Merci

[tchize_]

puis c'est férié jeudi,

pas ici

[Yann39]

[Yann39]

Bon j'ai essayé de charger le fichier cacerts que j'ai uploadé dans la base, mais évidement je n'ai pas les droits d'accès (FilePermission) au fichier depuis la base.

Enfin bon tant pi je ne vais même pas demander à l'admin. Je laisse tombé, merci de m'avoir aidé

Au pire je testerai avec une install perso de la 11g pour voir si ça vient vraiment de la version de la JVM interne, histoire de connaître la cause quand même.

[tchize_]

d'façons java 4 n'est plus supporté par sun, les certificat SSL ne sont qu'un des nombreux éléments qui se périment avec le temps dans un JVM. Si il restent sur la politique du pas d'upgrade ca finira par être joyeux

[Yann39]

Je crois qu'il n'est pas possible (ou très difficile) d'upgrader la JVM embarquée.

Il faudra attendre la migration vers Oracle 11g (ou 12g !) et c'est pas prévu pour bientôt apparement

Bref on va se mettre en place un petit serveur d'appli et voilà, ça nous évitera sûrement d'autres soucis comme tu dis Quoi que je vais sûrement en baver de ce côté là aussi