When s_client is well configured, meaning the library user has placed
something like cacerts.cpem (http://curl.haxx.se/docs/caextract.html)
in the proper place so s_client has them available by default, then...
The following produces unexpected results:
#!/bin/bash
wget -O Google-CA.der --no-check-certificate
https://pki.google.com/GIAG2.crt
openssl x509 -in Google-CA.der -inform DER -out Google-CA.pem -outform PEM
# Intuitively, this should fail, but it does not.
openssl s_client -connect www.microsoft.com:443 -tls1 -servername
www.microsoft.com -CAfile Google-CA.pem
The oddity above is it appears Google is certifying Microsoft sites.
**********
This also does not produce a failure:
openssl s_client -connect www.microsoft.com:443 -tls1 -servername
www.microsoft.com -CAfile Google-CA.pem -CApath /dev/null
**********
I like the default behavior of "use a list of CAs in the absence of
-CAfile and -CApath".
But I'm not sure the strategy taken is the best one. In fact, the
strategy kind on nullifies s_client's usefulness as a debug tool.
*If* the user specifies -CAfile or -CApath, then I would expect either:
(1) disable all default, available certificates
(2) disable the self-signed Root CAs (so only intermediates are available)
In either case, I can use s_client as a debug tool to verify a server
configuration.
_______________________________________________
openssl-bugs-mod mailing list
[email protected]
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
