seeking clarification of how to use 'verify'
Brian Reichert
to verify server certificates.
Om my CentOS host, I can direct 's_client' to use the default
CA certificate store to to collect a Google SSL certificate, and this
passes a verify check:
# openssl s_client -CApath /etc/pki/tls/cert.pem \
-connect www.google.com:443 < /dev/null > out.google.pem
depth=2 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
verify return:1
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
verify return:1
DONE
If I try to re-verify this certificate, though, it fails:
# openssl verify -verbose -CAfile /etc/pki/tls/cert.pem \
-purpose sslserver -issuer_checks out.google.pem
out.google.pem: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
error 29 at 0 depth lookup:subject issuer mismatch
/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com error 29 at 0 depth lookup:subject issuer mismatch
/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com error 29 at 0 depth lookup:subject issuer mismatch
/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com error 29 at 0 depth lookup:subject issuer mismatch
/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com error 20 at 0 depth lookup:unable to get local issuer certificate
Clearly, I'm doing something wrong here. Am I misunderstanding what
'verify' is for? Am I mis-invoking it?
FWIW, my environment:
# cat /etc/redhat-release
CentOS release 5.4 (Final)
# rpm -qf /etc/pki/tls/cert.pem
openssl-0.9.8e-12.el5_4.6
Thanks for any feedback...
--
Brian Reichert <reic...@numachi.com>
BSD admin/developer at large
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Dave Thompson
> Sent: Monday, 11 April, 2011 11:03
> I was hoping to get a better understanding of how to use 'verify'
> to verify server certificates.
>
> Om my CentOS host, I can direct 's_client' to use the default
> CA certificate store to to collect a Google SSL certificate, and this
> passes a verify check:
>
> # openssl s_client -CApath /etc/pki/tls/cert.pem \
> -connect www.google.com:443 < /dev/null > out.google.pem
<snip>
> If I try to re-verify this certificate, though, it fails:
>
> # openssl verify -verbose -CAfile /etc/pki/tls/cert.pem \
> -purpose sslserver -issuer_checks out.google.pem
>
Is /etc/pki/tls/cert.pem a file or a directory?
-CApath and -CAfile are different. Use the right one.
Also note that the output from -issuer_checks is very likely
to be misleading, so generally it's better not to use it.
But your likely problem is this cert uses an intermediate cert
/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA .
If that intermediate cert is not in your (packaged) truststore,
s_client can verify because google sent it, but verify can't
because verify gets only the entity cert you give it
unless you also specify -untrusted.
Do s_client with -showcerts and you'll see you get both
the entity cert for google and this intermediate cert.
Either: put the intermediate cert in a file and give it
to -untrusted; or put it in the truststore you use.
If your /etc/pki/blah is managed by a package manager
you probably shouldn't modify it, so you would need to
make a copy of the relevant part, at minimum just a file
containing the Verisign root and the intermediate.
Brian Reichert
> Is /etc/pki/tls/cert.pem a file or a directory?
> -CApath and -CAfile are different. Use the right one.
That was a typo on my end; I've been messing with both a concatenated
set of PEM certificates, and a directory. Once the typo is corrected,
I get the same symptom. :)
> Also note that the output from -issuer_checks is very likely
> to be misleading, so generally it's better not to use it.
Noted; thanks.
> But your likely problem is this cert uses an intermediate cert
> /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA .
> If that intermediate cert is not in your (packaged) truststore,
> s_client can verify because google sent it, but verify can't
> because verify gets only the entity cert you give it
> unless you also specify -untrusted.
I have to admit; I completely failed to understand the role of
'untrusted' certificates in this context.
I think I still want a high-level treatment of how 'openssl verify' is
different than the verification that 'openssl s_client' undergoes.
Is there some write-up of that on-line anywhere?
> Do s_client with -showcerts and you'll see you get both
> the entity cert for google and this intermediate cert.
> Either: put the intermediate cert in a file and give it
> to -untrusted; or put it in the truststore you use.
How is 'the truststore I use' different than the /etc/pki/tls/cert.pem
file dropped in by RedHat/CentOS?
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openss...@openssl.org
> Automated List Manager majo...@openssl.org
--
Brian Reichert <reic...@numachi.com>
BSD admin/developer at large
Dave Thompson
> On Mon, Apr 11, 2011 at 05:53:45PM -0400, Dave Thompson wrote:
<snip other points>
> > But your likely problem is this cert uses an intermediate cert
> > /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA .
> > If that intermediate cert is not in your (packaged) truststore,
> > s_client can verify because google sent it, but verify can't
> > because verify gets only the entity cert you give it
> > unless you also specify -untrusted.
>
> I have to admit; I completely failed to understand the role of
> 'untrusted' certificates in this context.
>
> I think I still want a high-level treatment of how 'openssl verify' is
> different than the verification that 'openssl s_client' undergoes.
>
> Is there some write-up of that on-line anywhere?
>
On Linux you should have man pages including verify(ssl1), which
describes chain verification (although it doesn't cover revocation
checks, which can now be included) which is the same for both
SSL ('s_client' etc.) and 'verify', and some other things too.
If you really want online, try the usual suspects.
The difference is that 's_client' has available the cert(s) sent
by the server, which can choose to send just the entity cert,
the full chain, or anywhere in between. www.google.com:443
in particular sends the entity cert and the one intermediate
cert (Thawte SGC) which together with a Verisign root (obviously
in your truststore, see below) makes a complete chain.
'verify' only has available the entity cert in the file you give
as an argument (or stdin), and optionally any cert(s) you give it
in -untrusted, as well as the truststore. Thus my suggestion next:
> > Do s_client with -showcerts and you'll see you get both
> > the entity cert for google and this intermediate cert.
> > Either: put the intermediate cert in a file and give it
> > to -untrusted; or put it in the truststore you use.
>
> How is 'the truststore I use' different than the /etc/pki/tls/cert.pem
> file dropped in by RedHat/CentOS?
>
For OpenSSL utilities the truststore is -CAfile and/or -CApath;
other apps are different. I didn't think you were modifying that
package -- people typically don't -- so 'the truststore you use'
allows for creating a different file/dir. If you want to modify
the /etc/pki one that works as far as OpenSSL is concerned, but
I don't know if it causes trouble with your package manager.
In theory whether you call Thawte SGC 'trusted' or 'untrusted'
could reflect an actual policy analysis. In practice you are
trusting it based solely on being issued by Verisign, so it's
semantically right to supply it as -untrusted. On the other hand,
it's often simpler to just have one file or directory of 'certs
I trust' and you do trust this one. So, either is reasonable.
Brian Reichert
> The difference is that 's_client' has available the cert(s) sent
> by the server, which can choose to send just the entity cert,
> the full chain, or anywhere in between. www.google.com:443
> in particular sends the entity cert and the one intermediate
> cert (Thawte SGC) which together with a Verisign root (obviously
> in your truststore, see below) makes a complete chain.
Thanks for all your feedback. Lots of good details, thanks.
Off to do more research...
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openss...@openssl.org
> Automated List Manager majo...@openssl.org
--
Brian Reichert <reic...@numachi.com>
BSD admin/developer at large