Created attachment 413473 [details] reproducer files Description of problem: If openssl is configured to match the organizationName when signing a CSR generated by Windows 2003 Server or Windows 7, it complains that the organizationName is not the same between the CA and the CSR even though they are identical: # openssl ca -config /etc/pki/ExampleInc-CA/openssl.cnf -in /tmp/ExampleInc-win7.csr Using configuration from /etc/pki/ExampleInc-CA/openssl.cnf Check that the request matches the signature Signature ok The organizationName field needed to be the same in the CA certificate (ExampleInc) and the request (ExampleInc) Why does it think "ExampleInc" != "ExampleInc"? Version-Release number of selected component (if applicable): openssl-0.9.8e-12.el5 How reproducible: every time Steps to Reproduce: 1. download attached exampleinc.tar.gz which includes a Windows 7 CSR (/tmp/ExampleInc-win7.csr) and a CA configuration (/etc/pki/ExampleInc-CA/*) 2. cd / 3. tar xzf /tmp/exampleinc.tar.gz 4. openssl ca -config /etc/pki/ExampleInc-CA/openssl.cnf -in /tmp/ExampleInc-win7.csr Actual results: The organizationName field needed to be the same in the CA certificate (ExampleInc) and the request (ExampleInc) Expected results: the csr is signed Additional info:
Changing openssl.cnf to use 'supplied' or 'optional' instead of 'match': [ policy_match ] ... #organizationName = match organizationName = supplied fixes the problem: # openssl ca -config /etc/pki/ExampleInc-CA/openssl.cnf -in /tmp/ExampleInc-win7.csr Using configuration from /etc/pki/ExampleInc-CA/openssl.cnf Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: May 12 16:13:37 2010 GMT Not After : May 15 16:13:37 2015 GMT Subject: countryName = US stateOrProvinceName = Florida organizationName = ExampleInc organizationalUnitName = IT commonName = servernamehere X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: ExampleInc Generated Certificate X509v3 Subject Key Identifier: C7:B7:8D:8C:F8:9C:22:94:22:9A:C2:CA:87:36:85:8B:FF:6F:87:4D X509v3 Authority Key Identifier: keyid:35:BB:6A:8A:8C:F9:09:3D:4A:E3:95:E0:11:13:D4:B0:87:3C:7E:2B DirName:/C=US/ST=Florida/L=Miami/O=ExampleInc/OU=IT/CN=hostname/emailAddress=admin serial:CA:E7:ED:2D:94:67:12:D4 Netscape CA Revocation Url: http://www.example.com/ca-crl.pem Netscape Base Url: http://www.example.com/ Netscape Revocation Url: http://www.example.com/crl.pem Certificate is to be certified until May 15 16:13:37 2015 GMT (1829 days) Sign the certificate? [y/n]:
Likewise, changing stateOrProvinceName to 'match' breaks it: # openssl ca -config /etc/pki/ExampleInc-CA/openssl.cnf -in /tmp/ExampleInc-win7.csr Using configuration from /etc/pki/ExampleInc-CA/openssl.cnf Check that the request matches the signature Signature ok The stateOrProvinceName field needed to be the same in the CA certificate (Florida) and the request (Florida) Curiously, the countryName of US does match on both.
The problem here is the encoding of the strings inside the ASN.1 structure of the request. This is not a bug the fields with different encoding really mean a different strings although when converted to a printable form they look the same. They have to create the CA certificate so that the encoding of the strings matches that of the Windows csr - the string_mask option in openssl.cnf can be used for that. openssl asn1parse will tell you what encoding is used for the strings in the Windows csr.