I am positive that I am installing the ca in the correct spot because connections to server B correctly show the CA cert as the trusted root when I view the certificate for the connection in the web browser.
To be clear, openssl verify says that both certificates A and B are ok when I provide my ca certificate as the CAfile argument. It is web browsers that do not find the issuer for certificate A. Ie, it seems to me like the browsers are MORE stringent in their checks than openssl verify. I will ask my management if I can attach the certs tomorrow... You and I know there is no risk attaching them but i still need the approval. Thanks for responding! CHAD On Jul 7, 2014, at 4:03 PM, "Dave Thompson" <dthomp...@prinpay.com> wrote: >> From: owner-openssl-us...@openssl.org On Behalf Of Barbe, Charles >> Sent: Sunday, July 06, 2014 22:42 > >> I have the following certificates and associated private keys: >> >> A - certificate A generated with one version of my software not using > openssl >> B - certificate B generated with a new version of my software that does > use >> openssl >> CA - a local certificate authority whose private key is used to sign both > A and >> B >> >> I can verify both A and B using openssl verify using CA as the cafile > argument. >> >> However, when I install CA on a client and try to connect a web browser to >> my server running the two different versions of software, they complain > that >> they cannot find the issuer with A but not with B. >> >> I have examined both certificates and cannot find anything different about >> them. As far as I can tell, the only difference is that B used openssl to >> generate the certificate and A used our own custom software. The odd thing >> to me is that openssl verify can verify both just fine. What are the web >> browsers doing different? I've tried chrome, Firefox and opera and all >> behave the same... Accepting B and rejecting A. >> >> Does anybody have any suggestions on where to look to figure this out? A >> tool to use? > You are installing in the correct placeS which can be different per browser, > right? > > The only thing that springs to mind that could be invisible is string types > and > some options of the cert Issuer fields vs the CA Subject. RFC 5280 requires > a > fairly complicated Unicode-aware comparison algorithm which I believe > openssl > does (it definitely canonicalizes before comparison, but I haven't gone > through > the canonicalization to make sure it exactly matches the RFC); browsers > might > not do the same (perhaps indirectly) although I'd be surprised if NONE do. > > I would first try x509 -noout -subject|issuer -nameopt multiline,show_type > and see if that helps. > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
