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
