Steve,
Many thanks for the very competent answer. We noticed the UTF8 encoding but thought about it as a "why not?" matter (and we didn't look into a RFC neither).
The CA is a Microsoft Shop and Internet Explorer is happy with the certificates they issue. I'll check their site again for somthing like a "name rollover" certificate but as far as I remember they offer nothing - at least not yet - in this direction.
Manfred
The cause of this is rather subtle. It looks like they've used the same key the same keyID, same DN values and got most things right.
However they've changed the character types in trust_new.pem. If you do something like:
openssl x509 -in xxx.pem -noout -subject -nameopt multiline,show_type
with the two certificates you'll see the difference. Now the problem is due to how software compares distinguished names.
OpenSSL follows the requirements of RFC3280 which only requires a subset of the full comparison rules. This does not require it to match DNs using different character types. In particular RFC3280 says:
(a) attribute values encoded in different types (e.g., PrintableString and BMPString) MAY be assumed to represent different strings;
Also in RFC3280 it says:
CAs MUST encode the distinguished name in the subject field of a CA
certificate identically to the distinguished name in the issuer field
in certificates issued by that CA.
so if they only have these certificates then they are violating RFC3280.
*However* they may have something called a "name rollover" certificate which
includes the old and new encodings in what is effectively a new intermediate
CA. If you can obtain that certifiate and include it then OpenSSL should have
no problems verifying it.
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
