Look at this example: $openssl x509 -subject -nameopt oneline,-esc_msb,utf8 -noout -in 13/13_cert.pem ... CN = 13#ტესტერიN13 $openssl x509 -subject -noout -in 13/13_cert.pem ... CN=13#\xE1\x83\xA2\xE1\x83\x94\xE1\x83\xA1\xE1\x83\xA2\xE1\x83\x94\xE1\x83\xA0\xE1\x83\x98N13
This certificate was signed by "openssl ca" without changing subject, and "openssl req" did not use BMPString and UCS-2 in this case. CN string contains Georgian letters but numbers are in ASCII so it is UTF-8 in fact. So why "openssl ca" decides to use BMPString format? Looks like 1-byte code strings can be used without violating ASN.1 standard ----- Original Message ----- From: Dave Thompson <dthomp...@prinpay.com> To: openssl-users@openssl.org Cc: Sent: Monday, July 30, 2012 6:47 AM Subject: RE: strange results after setting utf8 -subj in "openssl ca" command > From: owner-openssl-us...@openssl.org On Behalf Of Pica Pica Contact > Sent: Saturday, 28 July, 2012 14:41 Note that X.509 certs (and ASN.1 generally) don't actually support UTF8. They support several 1-byte codes (some now obsolete), BMPString which is 2-byte UCS-2, and UniversalString which is 4-byte UCS-4. I believe OpenSSL selects the smallest of these into which the specified (Unicode) codepoints fit, which in this case is UCS-2. > After adding -nameopt oneline,-esc_msb,utf8 result looks fine > That should translate the Unicode to UTF8 and output it, and assuming your terminal handles UTF8 then yes it will be good > I call X509_NAME_oneline() function inside my application to > get CN string, and application fails to convert number from > CN field to integer, because X509_NAME_oneline() returns > "/CN=\x003\x000\x000\x000\x000\x00#" instead of "CN=30000#...". > I'm pretty sure _oneline is what x509 -text without -nameopt uses. > Probably I should use X509_NAME_print_ex(), > Or if you only want CN, you could get the raw CN item and its value out of the name structure which in OpenSSL is STACK_OF(X509_NAME_ENTRY). > but I have doubts if this string encoding is correct and how > it would work with other software. For example, certtool from > GnuTLS outputs subject string in this way: > $ certtool -i --infile 30000.pem > > ...skipped... > > Subject: > CN=#003300300030003000300023044204350441044210e210d410e110e24e2d56fd > ...skipped... > That apparently is dumping the UCS-2 bytes. Compare to above. > There are no such problems in "openssl req", I can set UTF8 > strings with numbers in certificate requests and resulting > certificate is ok for me, but I need to ignore subject from > certificate requests and set my own value > > > Is it possible to fix "openssl ca" command somehow to encode > numbers in UTF8 strings as strings, not numbers? 'ca' can only encode ASN.1 strings in the ways defined by ASN.1. You must decode them accordingly. 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
