UTF-8 *is* *Unicode*. You're trying to embed UTF-16, which does not include a ideogram counter at the beginning of the string, and which (as you have seen) embeds \x00 characters into the string in such a way that the standard C string library cannot parse it.
UTF-8 is the universal preferred encoding, and in fact RFCs 3280 and 5280 both specify UTF-8 and not UTF-16. The reasons are several: 1) You can tell, just from the first byte of a character, how many additional bytes there are to the Unicode code point serialized into the string. 2) You never receive \x00. 3) You never receive \xff. To be fair: that's for the Internet profile. If you're working with a non-Internet profile, you need to get a copy of the profile that you're working with. If you can't get that from your customer, get it from your customer's CA. For your information, most CA implementations nowadays view embedded NUL characters as attempts at postfix-injection attacks, and most browsers and email clients do as well. You should tell your customer to get a certificate from a CA that actually adheres to the Internet PKIX profile standards, such as StartSSL.com, if you're going to be using it with S/MIME (which specifies that it uses the Internet Profile). -Kyle H On Thu, Nov 19, 2009 at 5:59 AM, Shaw Graham George <gs...@axway.com> wrote: > Thanks Steve, > >>> OpenSSL will *NOT* however do what happens above with the C (Country) > field. >>> That is a two character code and only PrintableString (a restricted > version of >>> ASCII) characters are permitted. Doing anything else violates several > standards. > > That's interesting, considering that this example certificate was sent > to us by one of our customers, and appears to be issued by the Guandong > Certificate Authority (GDCA), which is presumably a live CA ... > > Is that possible - that a real CA can violate the standards like this? > Or is this just like Microsoft breaking standards - you just have to > live with it? > > BTW, the "rogue" example certificate seems OK when used as an input to > other openssl functions ... E.g. openssl smime. > > But putting the country name to one side, what about the other data > elements? I understand the UTF-8 input is possible in openssl. Is what > you're saying that it's only UTF-8 that is possible, so if I want > Unicode input, then I have to find another solution. > > G. > > > -----Original Message----- > From: owner-openssl-us...@openssl.org > [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson > Sent: 19 November 2009 13:24 > To: openssl-users@openssl.org > Subject: Re: Creating a certificate with Unicode characters in Issuer > andSubject > > On Thu, Nov 19, 2009, Shaw Graham George wrote: > >> Hi, >> >> I have a requirement to make some test keys/certificates that contain >> Unicode (Chinese) data in the Issuer and Subject fields. Print-out >> from an example certificate using "openssl x509" is: >> >> Issuer: C=\x00C\x00N, >> ST=\x00G\x00u\x00a\x00n\x00g\x00d\x00o\x00n\x00g, >> L=\x00G\x00u\x00a\x00n\x00g\x00z\x00h\x00o\x00u, >> O=\x00G\x00D\x00C\x00A\x00 >> \x00C\x00e\x00r\x00t\x00i\x00f\x00i\x00c\x00a\x00t\x00e\x00 >> \x00A\x00u\x00t\x00h\x00o\x00r\x00i\x00t\x00y >> Subject: C=\x00C\x00N, ST=^\x7FN\x1Cw\x01, L=^\x7F]\xDE^\x02, >> ... >> >> Is this at all possible using the openssl tool? From the manual pages > >> it seems that UTF-8 is supported, but not Unicode - for example the >> config man page says that null characters in strings is not allowed. >> >> If not, then does anybody know of any other tools that I could use to >> make my test keys/certificates. >> > > Characters are passed to OpenSSL using UTF8, then depending on the > configuration options it gets translated into either a BMPString or a > UTF8String. From an application point of view it shouldn't matter which > (RFC3280 and later mandate UTF8Strings). > > OpenSSL will *NOT* however do what happens above with the C (Country) > field. > That is a two character code and only PrintableString (a restricted > version of > ASCII) characters are permitted. Doing anything else violates several > standards. > > BTW if you pick appropriate values for the -nameopt option and if your > terminal supports it you should be able to get that certificate to > display correctly. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
