Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à mes clés
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la clé
privé
Je crypte un fichier avec ce certif via la clé publique bien sur puis je
décrypte en passant en paramètre le p12 --> Ok tout est propre. Je conserve ce
fichier crypté dans 1 coin.
Maintenant, mon problème : je me pose dans la situation de la révocation/fin de
validité de mon certif. Je souhaitais simplement regénérer une CSR puis
signature etc à partir de la même bi-clé et du même DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!
Qui pourrait me donner 1 explication du pourquoi ?
Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à mes clés
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la clé
privé
Je crypte un fichier avec ce certif via la clé publique bien sur puis je
décrypte en passant en paramètre le p12 --> Ok tout est propre. Je conserve ce
fichier crypté dans 1 coin.
Maintenant, mon problème : je me pose dans la situation de la révocation/fin de
validité de mon certif. Je souhaitais simplement regénérer une CSR puis
signature etc à partir de la même bi-clé et du même DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!
Qui pourrait me donner 1 explication du pourquoi ?
Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à mes clés
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la clé
privé
Je crypte un fichier avec ce certif via la clé publique bien sur puis je
décrypte en passant en paramètre le p12 --> Ok tout est propre. Je conserve ce
fichier crypté dans 1 coin.
Maintenant, mon problème : je me pose dans la situation de la révocation/fin de
validité de mon certif. Je souhaitais simplement regénérer une CSR puis
signature etc à partir de la même bi-clé et du même DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!
Qui pourrait me donner 1 explication du pourquoi ?
Vous avez fourni des détails sur la fabrication de votre clé, certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième certificat.
Mais tout ça est hypothétique, dans l'attente de plus d'informations de votre part.
Vous avez fourni des détails sur la fabrication de votre clé, certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième certificat.
Mais tout ça est hypothétique, dans l'attente de plus d'informations de votre part.
Vous avez fourni des détails sur la fabrication de votre clé, certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième certificat.
Mais tout ça est hypothétique, dans l'attente de plus d'informations de votre part.
Le 22/02/2010 à 15:40, Erwann Abalea a écrit :Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.
Rha, zut, je viens de tomber sur votre message, j'ai répondu pour ma
part dans fr.comp.securite, je n'avais pas fait attention au double post
(sans crosspost ni fu2)...
Mais tout ça est hypothétique, dans l'attente de plus d'informations
de votre part.
Idem. Je n'avais pas pensé que le numéro de série pourrait avoir une
influence, car j'étais parti sur l'hypothèse (a priori fausse) que
toutes les opérations, y compris celles relatives au
chiffrement/déchiffrement, avaient été faites avec openssl (en utilisant
la fonctionnalité "rsautl" pour ce cas précis). Dans un tel cas, en
effet, le déchiffrement se faisant avec la clef privée directement (et
non avec un fichier PKCS#12), il faut faire l'opération en 2 temps:
1) extraction de la clef privée du PKCS#12
2) déchiffrement du fichier avec la clef privée
Et dans ce cas, le numéro de série n'intervient absolument pas.
J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)
Le 22/02/2010 à 15:40, Erwann Abalea a écrit :
Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.
Rha, zut, je viens de tomber sur votre message, j'ai répondu pour ma
part dans fr.comp.securite, je n'avais pas fait attention au double post
(sans crosspost ni fu2)...
Mais tout ça est hypothétique, dans l'attente de plus d'informations
de votre part.
Idem. Je n'avais pas pensé que le numéro de série pourrait avoir une
influence, car j'étais parti sur l'hypothèse (a priori fausse) que
toutes les opérations, y compris celles relatives au
chiffrement/déchiffrement, avaient été faites avec openssl (en utilisant
la fonctionnalité "rsautl" pour ce cas précis). Dans un tel cas, en
effet, le déchiffrement se faisant avec la clef privée directement (et
non avec un fichier PKCS#12), il faut faire l'opération en 2 temps:
1) extraction de la clef privée du PKCS#12
2) déchiffrement du fichier avec la clef privée
Et dans ce cas, le numéro de série n'intervient absolument pas.
J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)
Le 22/02/2010 à 15:40, Erwann Abalea a écrit :Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.
Rha, zut, je viens de tomber sur votre message, j'ai répondu pour ma
part dans fr.comp.securite, je n'avais pas fait attention au double post
(sans crosspost ni fu2)...
Mais tout ça est hypothétique, dans l'attente de plus d'informations
de votre part.
Idem. Je n'avais pas pensé que le numéro de série pourrait avoir une
influence, car j'étais parti sur l'hypothèse (a priori fausse) que
toutes les opérations, y compris celles relatives au
chiffrement/déchiffrement, avaient été faites avec openssl (en utilisant
la fonctionnalité "rsautl" pour ce cas précis). Dans un tel cas, en
effet, le déchiffrement se faisant avec la clef privée directement (et
non avec un fichier PKCS#12), il faut faire l'opération en 2 temps:
1) extraction de la clef privée du PKCS#12
2) déchiffrement du fichier avec la clef privée
Et dans ce cas, le numéro de série n'intervient absolument pas.
J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)
Bonjour,
Si vous savez ajouter un le fu2, faites-le, je n'ai pas trouvé comment faire ça
avec Thunderbird (je sais, ça n'est pas exactement le meilleur lecteur de news).
Lisant que l'OP parlait de "fichiers", j'ai moi aussi pensé de cette manière
(rsautl). Mais ça aurait nécessité de savoir générer une clé de session,
chiffrer le dit fichier en symétrique, puis chiffrer la clé de session, et
évidemment l'inverse pour le déchiffrement. C'est un poil plus que simplement se
faire un certificat sur une PKI à la main avec OpenSSL, sans vouloir froisser l'OP.
J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)
Et en important le certificat seul, en tant qu'AC, en lui attribuant les droits,
puis en important le P12? Ça m'étonnerait que ça passe, mais on ne sait jamais.
Bonjour,
Si vous savez ajouter un le fu2, faites-le, je n'ai pas trouvé comment faire ça
avec Thunderbird (je sais, ça n'est pas exactement le meilleur lecteur de news).
Lisant que l'OP parlait de "fichiers", j'ai moi aussi pensé de cette manière
(rsautl). Mais ça aurait nécessité de savoir générer une clé de session,
chiffrer le dit fichier en symétrique, puis chiffrer la clé de session, et
évidemment l'inverse pour le déchiffrement. C'est un poil plus que simplement se
faire un certificat sur une PKI à la main avec OpenSSL, sans vouloir froisser l'OP.
J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)
Et en important le certificat seul, en tant qu'AC, en lui attribuant les droits,
puis en important le P12? Ça m'étonnerait que ça passe, mais on ne sait jamais.
Bonjour,
Si vous savez ajouter un le fu2, faites-le, je n'ai pas trouvé comment faire ça
avec Thunderbird (je sais, ça n'est pas exactement le meilleur lecteur de news).
Lisant que l'OP parlait de "fichiers", j'ai moi aussi pensé de cette manière
(rsautl). Mais ça aurait nécessité de savoir générer une clé de session,
chiffrer le dit fichier en symétrique, puis chiffrer la clé de session, et
évidemment l'inverse pour le déchiffrement. C'est un poil plus que simplement se
faire un certificat sur une PKI à la main avec OpenSSL, sans vouloir froisser l'OP.
J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)
Et en important le certificat seul, en tant qu'AC, en lui attribuant les droits,
puis en important le P12? Ça m'étonnerait que ça passe, mais on ne sait jamais.
Bonjour,
neopale a écrit :Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui
vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à
mes clés
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la
clé
privé
Je crypte un fichier avec ce certif via la clé publique bien sur puis
je
décrypte en passant en paramètre le p12 --> Ok tout est
propre. Je conserve ce
fichier crypté dans 1 coin.
Maintenant, mon problème : je me pose dans la situation de la
révocation/fin de
validité de mon certif. Je souhaitais simplement
regénérer une CSR puis
signature etc à partir de la même bi-clé et du même
DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec
le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!
Qui pourrait me donner 1 explication du pourquoi ?
Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.
Ce que tout ça m'évoque, c'est un chiffrement avec du PKCS#7 (ou
CMS, S/MIME,
tout ça c'est pareil). Dans ce cas, le récipiendaire de l'objet
chiffré
(l'entité capable de le déchiffrer) est identifié par un
couple:
- le nom de son émetteur (donc le nom de votre AC)
- son numéro de série
Puisque vous avez un deuxième certificat, vous avez un deuxième
numéro de série
(c'est la norme qui veut ça, un numéro de série ne doit
*pas* être réutilisé).
Et là, ça pète, comme vous dites, le logiciel vous dit
qu'il n'est pas
destinataire de ce fichier, en gros.
Mais tout ça est hypothétique, dans l'attente de plus
d'informations de votre part.
--
Erwann.
Bonjour,
neopale a écrit :
Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui
vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à
mes clés
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la
clé
privé
Je crypte un fichier avec ce certif via la clé publique bien sur puis
je
décrypte en passant en paramètre le p12 --> Ok tout est
propre. Je conserve ce
fichier crypté dans 1 coin.
Maintenant, mon problème : je me pose dans la situation de la
révocation/fin de
validité de mon certif. Je souhaitais simplement
regénérer une CSR puis
signature etc à partir de la même bi-clé et du même
DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec
le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!
Qui pourrait me donner 1 explication du pourquoi ?
Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.
Ce que tout ça m'évoque, c'est un chiffrement avec du PKCS#7 (ou
CMS, S/MIME,
tout ça c'est pareil). Dans ce cas, le récipiendaire de l'objet
chiffré
(l'entité capable de le déchiffrer) est identifié par un
couple:
- le nom de son émetteur (donc le nom de votre AC)
- son numéro de série
Puisque vous avez un deuxième certificat, vous avez un deuxième
numéro de série
(c'est la norme qui veut ça, un numéro de série ne doit
*pas* être réutilisé).
Et là, ça pète, comme vous dites, le logiciel vous dit
qu'il n'est pas
destinataire de ce fichier, en gros.
Mais tout ça est hypothétique, dans l'attente de plus
d'informations de votre part.
--
Erwann.
Bonjour,
neopale a écrit :Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui
vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à
mes clés
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la
clé
privé
Je crypte un fichier avec ce certif via la clé publique bien sur puis
je
décrypte en passant en paramètre le p12 --> Ok tout est
propre. Je conserve ce
fichier crypté dans 1 coin.
Maintenant, mon problème : je me pose dans la situation de la
révocation/fin de
validité de mon certif. Je souhaitais simplement
regénérer une CSR puis
signature etc à partir de la même bi-clé et du même
DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec
le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!
Qui pourrait me donner 1 explication du pourquoi ?
Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.
Ce que tout ça m'évoque, c'est un chiffrement avec du PKCS#7 (ou
CMS, S/MIME,
tout ça c'est pareil). Dans ce cas, le récipiendaire de l'objet
chiffré
(l'entité capable de le déchiffrer) est identifié par un
couple:
- le nom de son émetteur (donc le nom de votre AC)
- son numéro de série
Puisque vous avez un deuxième certificat, vous avez un deuxième
numéro de série
(c'est la norme qui veut ça, un numéro de série ne doit
*pas* être réutilisé).
Et là, ça pète, comme vous dites, le logiciel vous dit
qu'il n'est pas
destinataire de ce fichier, en gros.
Mais tout ça est hypothétique, dans l'attente de plus
d'informations de votre part.
--
Erwann.
- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif N°1, le
fichier est décrypté.
NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,
Enfin, cela implique qu'un certif revoqué doit etre conservé pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui me
chagrine, comment géré simplement cela :-(
Vos avis et expériences sont les bienvenues
- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif N°1, le
fichier est décrypté.
NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,
Enfin, cela implique qu'un certif revoqué doit etre conservé pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui me
chagrine, comment géré simplement cela :-(
Vos avis et expériences sont les bienvenues
- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif N°1, le
fichier est décrypté.
NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,
Enfin, cela implique qu'un certif revoqué doit etre conservé pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui me
chagrine, comment géré simplement cela :-(
Vos avis et expériences sont les bienvenues
Bonjour,
neopale a écrit :
[...]- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon
explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans
le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no
recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif
N°1, le
fichier est décrypté.
Merci pour les détails complémentaires, qui confirment ce que je
pensais, vous
faites du CMS/PKCS#7/SMIME. Et dans ce mode, le récipiendaire est
désigné par
son certificat.NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela
fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,
Enfin, cela implique qu'un certif revoqué doit etre conservé
pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés
cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui
me
chagrine, comment géré simplement cela :-(
Vos avis et expériences sont les bienvenues
Il n'y a pas de mystère, si votre environnement est un logiciel de
courrier, et
si l'échange de documents chiffrés se fait par des mails
chiffrés façon S/MIME,
alors vous devez en accepter les règles. Cela signifie que l'utilisateur
doit
conserver ses certificats, même les expirés, même les
révoqués, s'il souhaite
déchiffrer un mail.
Si vous ne pouvez pas garantir cela (trop d'utilisateurs, et qui parfois
réinstallent eux-même leur poste, sans trop faire attention),
alors vous pouvez
envisager un service de séquestre de clés, et dans ce cas, un
utilisateur aura
plusieurs certificats+clés, avec le même DN, mais pour des usages
différents.
Un tiers de séquestre peut générer la clé de
chiffrement ou la recevoir du
demandeur, il la conserve précieusement. S'il l'a
générée, il en fournit une
copie au demandeur pour qu'il effectue la demande de certificat, voire il fait
la demande lui-même, et fournit un PKCS#12 complet au demandeur. De son
côté, le
demandeur fait pour son propre compte une demande de certificat de signature
et/ou authentification, avec une clé privée qu'il est le seul
à détenir.
--
Erwann.
Bonjour,
neopale a écrit :
[...]
- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon
explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans
le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no
recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif
N°1, le
fichier est décrypté.
Merci pour les détails complémentaires, qui confirment ce que je
pensais, vous
faites du CMS/PKCS#7/SMIME. Et dans ce mode, le récipiendaire est
désigné par
son certificat.
NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela
fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,
Enfin, cela implique qu'un certif revoqué doit etre conservé
pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés
cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui
me
chagrine, comment géré simplement cela :-(
Vos avis et expériences sont les bienvenues
Il n'y a pas de mystère, si votre environnement est un logiciel de
courrier, et
si l'échange de documents chiffrés se fait par des mails
chiffrés façon S/MIME,
alors vous devez en accepter les règles. Cela signifie que l'utilisateur
doit
conserver ses certificats, même les expirés, même les
révoqués, s'il souhaite
déchiffrer un mail.
Si vous ne pouvez pas garantir cela (trop d'utilisateurs, et qui parfois
réinstallent eux-même leur poste, sans trop faire attention),
alors vous pouvez
envisager un service de séquestre de clés, et dans ce cas, un
utilisateur aura
plusieurs certificats+clés, avec le même DN, mais pour des usages
différents.
Un tiers de séquestre peut générer la clé de
chiffrement ou la recevoir du
demandeur, il la conserve précieusement. S'il l'a
générée, il en fournit une
copie au demandeur pour qu'il effectue la demande de certificat, voire il fait
la demande lui-même, et fournit un PKCS#12 complet au demandeur. De son
côté, le
demandeur fait pour son propre compte une demande de certificat de signature
et/ou authentification, avec une clé privée qu'il est le seul
à détenir.
--
Erwann.
Bonjour,
neopale a écrit :
[...]- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon
explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans
le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no
recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif
N°1, le
fichier est décrypté.
Merci pour les détails complémentaires, qui confirment ce que je
pensais, vous
faites du CMS/PKCS#7/SMIME. Et dans ce mode, le récipiendaire est
désigné par
son certificat.NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela
fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,
Enfin, cela implique qu'un certif revoqué doit etre conservé
pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés
cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui
me
chagrine, comment géré simplement cela :-(
Vos avis et expériences sont les bienvenues
Il n'y a pas de mystère, si votre environnement est un logiciel de
courrier, et
si l'échange de documents chiffrés se fait par des mails
chiffrés façon S/MIME,
alors vous devez en accepter les règles. Cela signifie que l'utilisateur
doit
conserver ses certificats, même les expirés, même les
révoqués, s'il souhaite
déchiffrer un mail.
Si vous ne pouvez pas garantir cela (trop d'utilisateurs, et qui parfois
réinstallent eux-même leur poste, sans trop faire attention),
alors vous pouvez
envisager un service de séquestre de clés, et dans ce cas, un
utilisateur aura
plusieurs certificats+clés, avec le même DN, mais pour des usages
différents.
Un tiers de séquestre peut générer la clé de
chiffrement ou la recevoir du
demandeur, il la conserve précieusement. S'il l'a
générée, il en fournit une
copie au demandeur pour qu'il effectue la demande de certificat, voire il fait
la demande lui-même, et fournit un PKCS#12 complet au demandeur. De son
côté, le
demandeur fait pour son propre compte une demande de certificat de signature
et/ou authentification, avec une clé privée qu'il est le seul
à détenir.
--
Erwann.