On Mon, Nov 29, 2004, Manfred Faulandt wrote:
> Dear group,
>
> I have a server certificate signed by a local CA company and the root
> certificate that signed it expires very soon. The CA company gave us a
> new root certificate but with the new root certificate OpenSSL is no
> longer able to successfully verify the server certificate.
>
> The working chain is: trust.pem --- a-sign.pem --- server.pem
>
> The no longer working chain is: trust_new.pem --- a-sign.pem --- server.pem
>
> OpenSSL successfully verifies server.pem when using trust.pem and
> a-sign.pem in the CAfile but it fails to verify server.pem with
> trust_new.pem instead of trust.pem in the CAfile:
>
> server.pem: /C=AT/O=A-Trust Ges. f. Sicherheitssysteme im elektr.
> Datenverkehr GmbH/OU=a-sign-corporate-light-01/CN=a-sign-corporate-light-01
> error 2 at 1 depth lookup:unable to get issuer certificate
>
> Verifying a-sign.pem when using trust.pem gives OK but when using
> trust_new.pem instead it gives:
>
> a-sign.pem: /C=AT/O=A-Trust Ges. f. Sicherheitssysteme im elektr.
> Datenverkehr GmbH/OU=a-sign-corporate-light-01/CN=a-sign-corporate-light-01
> error 20 at 0 depth lookup:unable to get local issuer certificate
>
> It looks like OpenSSL does not recognize trust_new.pem as the signer of
> a-sign.pem but the question is why? Trust_new.pem looks - at least for
> me - pretty like trust.pem except the changed validity dates and the
> signature.
>
> Does anyone know what's wrong with the cerificates and how to make
> OpenSSL again successfully validate the certificate chain? (the
> certificates follow below:)
>
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.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
