Champs X509 illisibles sous IE
Le
db
Bonsoir,
je fais face à un problème étrange pour lequel je n'ai pas trouvé de réponse
sur le Net (avec des mots-clé comme garbage, IE, openSSL).
Cela fait plusieurs années que je génère des certif mais jusqu'à une époque
récente c'était à l'intention de logiciels de VPN. Non pas qu'ils soient
moins regardants mais cela ne semblait pas les géner, non plus que cela ne
gène Firefox (Mozilla) ou Lynx.
En fait, j'avais déjà aperçu ce phénomène l'année dernière mais cela ne me
dérangeait pas alors donc
Désormais cela devient pénible car cela interdit l'accès à mon webmail si le
navigateur du client est IE sur MacIntosh par exemple (plus restricitif que
IE sous Windows).
Bref, il se trouve que IE << voit >> certains champs sous une forme binaire
au lieu d'un format texte : le sujet, l'émetteur, le sujet alternatif, etc.
En clair, si j'ai :
CN=mail.toot.com, OU=toot, O=toot, C=FR
il voit :
CN 0D 6D61 696C 2C74 6F6F 742C 636F 6D
OU 04 746F 6F74
O 04 746F 6F74
C=FR
C'est à dire qu'il ajoute aux chaines le caractère 12 (0xC) suivi de la
longueur de la chaine.
Après tout on pourrait se dire qu'il fait bien ce qu'il veut mais le
handicap est que le navigateur ne reconnaît pas, partant, le site (dont
l'URL figure dans le CN) car il ne conserve que ce qui représente une
chaine de caractères soit le 'C=FR' et FR est forcément différent de
mail.toot.com.
J'ai essayé plusieurs trucs comme changer l'algorithme de résumé (md5 en
sha1), modifier le DN, rien n'y fait dans ce cas.
Alors que j'ai d'autres certifs pour lesquels IE << voit >>correctement les
choses mais quant à trouver la différence légitime c'est une autre paire de
manches.
Le même certif vu sous openssl est correct ainsi que sous Firefox (Mozilla).
Toutefois sous ce dernier, des champs qui apparaissent bien sous IE (les
URL, l'adresse de révocation) et sous openSSL apparaissent sous une forme
héxadécimale sous Firefox (sans OCn devant).
Si quelqu'un a une idée, elle est la bienvenue,
Merci,
db
--
email : usenet blas net
je fais face à un problème étrange pour lequel je n'ai pas trouvé de réponse
sur le Net (avec des mots-clé comme garbage, IE, openSSL).
Cela fait plusieurs années que je génère des certif mais jusqu'à une époque
récente c'était à l'intention de logiciels de VPN. Non pas qu'ils soient
moins regardants mais cela ne semblait pas les géner, non plus que cela ne
gène Firefox (Mozilla) ou Lynx.
En fait, j'avais déjà aperçu ce phénomène l'année dernière mais cela ne me
dérangeait pas alors donc
Désormais cela devient pénible car cela interdit l'accès à mon webmail si le
navigateur du client est IE sur MacIntosh par exemple (plus restricitif que
IE sous Windows).
Bref, il se trouve que IE << voit >> certains champs sous une forme binaire
au lieu d'un format texte : le sujet, l'émetteur, le sujet alternatif, etc.
En clair, si j'ai :
CN=mail.toot.com, OU=toot, O=toot, C=FR
il voit :
CN 0D 6D61 696C 2C74 6F6F 742C 636F 6D
OU 04 746F 6F74
O 04 746F 6F74
C=FR
C'est à dire qu'il ajoute aux chaines le caractère 12 (0xC) suivi de la
longueur de la chaine.
Après tout on pourrait se dire qu'il fait bien ce qu'il veut mais le
handicap est que le navigateur ne reconnaît pas, partant, le site (dont
l'URL figure dans le CN) car il ne conserve que ce qui représente une
chaine de caractères soit le 'C=FR' et FR est forcément différent de
mail.toot.com.
J'ai essayé plusieurs trucs comme changer l'algorithme de résumé (md5 en
sha1), modifier le DN, rien n'y fait dans ce cas.
Alors que j'ai d'autres certifs pour lesquels IE << voit >>correctement les
choses mais quant à trouver la différence légitime c'est une autre paire de
manches.
Le même certif vu sous openssl est correct ainsi que sous Firefox (Mozilla).
Toutefois sous ce dernier, des champs qui apparaissent bien sous IE (les
URL, l'adresse de révocation) et sous openSSL apparaissent sous une forme
héxadécimale sous Firefox (sans OCn devant).
Si quelqu'un a une idée, elle est la bienvenue,
Merci,
db
--
email : usenet blas net
Poser une question
Trouvé : il s'agissait de l'encodade, UTF-8 au lieu de PrintableString.
Merci,
db
--
email : usenet blas net
Euh, peut-être trouvé mais quand même assez génant car l'encodage UTF-8
pour les certificats est impératif depuis la fin de l'année dernière si
l'on souhaite respecter la RFC 3280.
Son ancêtre la RFC 2459 disait de toute façon la même chose sur ce point.
Netscape 4 est réputé avoir la même restriction, même pire car il
planterait face à ce type de certificat, tu n'as jamais vu le problème ?
Tu parle de champs présents où ? Dans les extensions ?
Malheureusement FF/Mz ne décodent pas le contenu de toutes les
extensions, même quand elles sont tout à fait standard ...