Jakob, All, Glad this is coming up again, as we are having similar problems. Like you, have string_mask = utf8only in config, and have never been able to embed UTF8 chars into certs.
We're using the OS X Terminal Program, which is (purports to be?) UTF8-capable. We can enter the subject line of the CSR with either UTF8 codes, or with the 'actual' characters, and get the same mileage: openssl req -new -sha1 -nodes \ -nameopt multiline,show_type \ -keyout private/THORSTROM.key \ -out csrs/THORSTROM.csr \ -subj "/O=ESBJÖRN.com/OU=Esbjörn-Thörstrom Group/CN=Áki Thörstrom" ==== Have also tried this with Stephen's suggested: # -nameopt oneline,-esc_msb \ In either case, signing the cert attempts to output the escaped UTF8 codes, not the actual coded characters, into the respective fields. The 'sign the certificate?' prompt reports: Subject: organizationName = ESBJ\C3\96RN.com organizationalUnitName = Esbj\C3\B6rn-Th\C3\B6rstrom Group commonName = \C3\81ki Th\C3\B6rstrom Thanks, Lou Picciano ----- Original Message ----- From: "Jakob Bohm" <jb-open...@wisemo.com> To: openssl-users@openssl.org Sent: Friday, December 16, 2011 9:07:10 AM Subject: Re: stateOrProvinceName field problem when signing CSR I think we may have a bug here, anyone from the core team wish to comment on this. The apparent bug: When enforcing the "match" policy for a DN part, openssl reports an error if the CSR has used a different string type for the field, but the correct value (The naively expected behavior is to realize the strings are identical and use the configured encoding for the resulting cert). Related to this is to check what the behavior is for the following similar operations: 2. Generating a cert from a CSR that uses a non-preferred string type in its DN, here it should be explicit if the DN will be converted to an enabled string type (e.g. from PrintableString to UTF8String or from UTF8String to BMPString or from UTF8StringWithOnlyBasicCharsPresent to PrintableString). 3. Validating a certificate whose issuing CA certificate specifies path constraints where the issued certificate satisfies the path constraint except for the exact choice of string type. Technical note: All the defined string types have a well defined mapping to and from 32 bit Unicode code points, with the following one-way limitations: BMPStrings can only represent U+0000 to U+10FFFF (using UTF-16) UTF8Strings can only represent U+0000 to U+7FFFFFFF (allowing the possibility that some codepoints above U+10FFFF may be assigned in the future, contrary to current policy). (OpenSSL may or may not accept the CESU-8 and Java Modified UTF-8 encoding variants and may or may not normalize those to real UTF-8 before further processing). PrintableString can only represent a specific small set of Unicode code points T61String can only represent a different specific small set. On 12/16/2011 1:45 PM, Mick wrote: > On Friday 16 Dec 2011 11:31:59 you wrote: >> (Sorry, accidentally hit send, ignore previous mail) >> >> On 12/15/2011 11:01 PM, Mick wrote: >>> Hi All, >>> >>> I've generated a cakey.pem and cacert.pem on my PC. Uploaded the >>> cacert.pem to my router and used its gui to generate a CSR. >>> >>> When I try to sign this CSR file back on my PC I'm getting this error: >>> ===================================== >>> $ openssl ca -config ./openssl_VPN.cnf -days 1095 -cert cacert_VPN.pem >>> -keyfile VPN_CA/private/cakey_VPN.pem -infiles >>> certificate-router-request Using configuration from ./openssl_VPN.cnf >>> Enter pass phrase for VPN_CA/private/cakey_VPN.pem: >>> Check that the request matches the signature >>> Signature ok >>> The stateOrProvinceName field needed to be the same in the >>> CA certificate (Buckinghamshire) and the request (Buckinghamshire) >>> ===================================== >>> >>> I don't understand why I get this error. Both cacert and >>> certificate-router- >>> >>> request files contain exactly the same ST= field. The cacert_VPN.pem shows: >>> Issuer: C=GB, ST=Buckinghamshire, L= [snip ...] >>> Subject: C=GB, ST=Buckinghamshire, L= [snip ...] >>> >>> and the CSR shows: >>> Subject: C=GB, ST=Buckinghamshire, L= [snip ...] >> Try repeating those output commands with the option >> >> -nameopt multiline,show_type > Bingo! :-) > > The problem seems to be that the router CSR shows: > > stateOrProvinceName = PRINTABLESTRING:Buckinghamshire > > while the cacert_VPN.pem shows: > > stateOrProvinceName = UTF8STRING:Buckinghamshire > > The whole router Subject content is: > > Subject: > countryName = PRINTABLESTRING:blah > stateOrProvinceName = PRINTABLESTRING:Buckinghamshire > localityName = PRINTABLESTRING:blah > organizationName = PRINTABLESTRING:blah > organizationalUnitName = PRINTABLESTRING:blah > commonName = T61STRING:blah > > while the cacert is: > > Subject: > countryName = PRINTABLESTRING:blah > stateOrProvinceName = UTF8STRING:Buckinghamshire > organizationName = UTF8STRING:blah > organizationalUnitName = UTF8STRING:blah > commonName = UTF8STRING:blah > >> to determine if the two disagree on the character encoding, >> spacing or other subtle aspect of the ST= part of the name. >> >> If it turns out to be such a subtle difference, please report >> it back to the list as a bug in the openssl code that handles >> the "match" option, and as a workaround change the field to >> "supplied" in the policy but manually inspect each CSR before >> deciding to sign it (This would not work if the match is also >> enforced by a path constraint in the CA cert). > Before I read your message I changed the "match" option to "optional" for the > ST field. Then openssl complained about the organizationName and I changed > that to "optional too. It helped me to issue the certificates - but wasn't > sure if I was doing the right thing. > > > I have this in the openssl.cnf: > > ############################################## > [ req ] > default_bits = 2048 > default_keyfile = privkey.pem > distinguished_name = req_distinguished_name > attributes = req_attributes > x509_extensions = v3_ca # The extentions to add to the self signed cert > > # Passwords for private keys if not present they will be prompted for > # input_password = secret > # output_password = secret > > # This sets a mask for permitted string types. There are several options. > # default: PrintableString, T61String, BMPString. > # pkix : PrintableString, BMPString (PKIX recommendation before 2004) > # utf8only: only UTF8Strings (PKIX recommendation after 2004). > # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). > # MASK:XXXX a literal mask value. > # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings. > string_mask = utf8only > ############################################## > > but even when I replaced it with > > string_mask = default > > I got the same error. So eventually I left it as utf8only. What should this > option be? > > > Thank you for your help! :-) > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
