Tickets :: [#10956] Common Name is 0 while using S/MIME certificates with non-ASCII characters

Summary	Common Name is 0 while using S/MIME certificates with non-ASCII characters
Queue	Horde Groupware Webmail Edition
Queue Version	4.0.6
Type	Bug
State	Resolved
Priority	1. Low
Owners	Michael Slusarz <slusarz (at) horde (dot) org>
Requester	maciej (dot) uhlig (at) us (dot) edu (dot) pl
Created	02/02/2012 (475 days ago)
Due
Updated	02/07/2012 (470 days ago)
Assigned	02/02/2012 (475 days ago)
Resolved	02/07/2012 (470 days ago)
Attachments
Milestone
Patch	No

02/07/2012 06:08:46 PM	Michael Slusarz	Comment #10 State ⇒ Resolved	Reply to this comment
OR reports the ticket can be closed.

02/06/2012 08:02:11 AM	maciej (dot) uhlig (at) us (dot) edu (dot) pl	Comment #9	Reply to this comment
I cannot reproduce. The certificate imports fine - I see the correct first and last name in Turba. So I'll send you xdebug output soon which shows how Turba driver damages the name here.

02/06/2012 03:31:32 AM	Michael Slusarz	Comment #8	Reply to this comment
Can you provide an example signed message where the certificate does not send correctly? The message has been redirected to your address. I cannot reproduce. The certificate imports fine - I see the correct first and last name in Turba.

02/04/2012 08:19:32 AM	maciej (dot) uhlig (at) us (dot) edu (dot) pl	Comment #7	Reply to this comment
Can you provide an example signed message where the certificate does not send correctly? The message has been redirected to your address.

02/03/2012 10:54:31 PM	Michael Slusarz	Comment #6	Reply to this comment
"Sender" is now displayed correctly. Thanks. However the side effect remains: new Turba contact name!surname are malformed after certificate save.. Can you provide an example signed message where the certificate does not send correctly?

02/03/2012 08:17:59 AM	maciej (dot) uhlig (at) us (dot) edu (dot) pl	Comment #5	Reply to this comment
"Sender" is now displayed correctly. Thanks. However the side effect remains: new Turba contact name!surname are malformed after certificate save..

02/03/2012 07:36:38 AM	Git Commit	Comment #4	Reply to this comment
Changes have been made in Git (develop): commit b43b04882a077b644733ba62f1a593c2fceaad04 Author: Michael M Slusarz <slusarz@horde.org> Date: Thu Feb 2 15:03:38 2012 -0700 [mms] Improved parsing of S/MIME certificate information (~~Bug #10956~~). framework/Crypt/lib/Horde/Crypt/Smime.php \| 733 ++++------------------------- framework/Crypt/package.xml \| 7 +- 2 files changed, 89 insertions(+), 651 deletions(-) http://git.horde.org/horde-git/-/commit/b43b04882a077b644733ba62f1a593c2fceaad04

02/02/2012 10:08:47 PM	Michael Slusarz	Comment #3 Priority ⇒ 1. Low State ⇒ Feedback Assigned to Michael Slusarz	Reply to this comment
I noticed this a few weeks back. The ASN.1 parsing algorithm hasn't been touched in probably 10 years. And most of the work it is doing is to grab completely esoteric information that we don't need (the modulus for the public key? do I care?). The important info is probably validity dates and personal information (name, email), so that's all we should really care about. So switch you using openssl_x509_parse() to parse the certs. I realize it says the API may change, but it has been this way for 10 years so at some point we should use it. So try this and see if it fixes things.

02/02/2012 10:06:04 PM	Git Commit	Comment #2	Reply to this comment
Changes have been made in Git (master): commit b43b04882a077b644733ba62f1a593c2fceaad04 Author: Michael M Slusarz <slusarz@horde.org> Date: Thu Feb 2 15:03:38 2012 -0700 [mms] Improved parsing of S/MIME certificate information (~~Bug #10956~~). framework/Crypt/lib/Horde/Crypt/Smime.php \| 733 ++++------------------------- framework/Crypt/package.xml \| 7 +- 2 files changed, 89 insertions(+), 651 deletions(-) http://git.horde.org/horde-git/-/commit/b43b04882a077b644733ba62f1a593c2fceaad04

02/02/2012 02:31:39 PM	maciej (dot) uhlig (at) us (dot) edu (dot) pl	Comment #1 State ⇒ Unconfirmed Patch ⇒ No Milestone ⇒ Queue ⇒ Horde Groupware Webmail Edition Due ⇒ 02/29/2012 Summary ⇒ Common Name is 0 while using S/MIME certificates with non-ASCII characters Type ⇒ Bug Priority ⇒ 2. Medium	Reply to this comment
Looking at S/MIME message one can see: The data in this part has been digitally signed via S/MIME. Message verified successfully. Sender: 0 (user.name@example.pl) [View Certificate] The issue is "Sender:0" instead of "Sender: User Name". This is due to Polish diacritic marks in user name or surname which can be found in Common Name of Certificate Owner. 'View Certificate' shows "Common Name: 0". The certificate CA is Comodo/TERENA. The side effect of this is incorrect import of the certificate into Turba addressbook where name or surname are truncated. The certificate with Polish diacritic marks is available upon request.