Please note that s_client is used for debugging connections not certs and might connect EVEN IF the server certificate is not good.
http://www.openssl.org/docs/apps/s_client.html#item__verify "Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. As a side effect the connection will never fail due to a server certificate verify failure." For checking your certificate chains I recommend OpenSSL's "verify" command. http://www.openssl.org/docs/apps/verify.html P On 22 May 2013 03:06, Somesh Chakrabarti <itsmesom...@gmail.com> wrote: > In your s_client command, you still need to include the -CAfile parameter > and point it to just the self-signed Root certificate. Your server is > sending the intermediates but the client is not able to verify the chain up > to a Root. > > You may want to edit cacerts.pem to include only the Root certificate and > try again. > > > On Tue, May 21, 2013 at 5:50 PM, Jorge Ventura > <jorge.araujo.vent...@gmail.com> wrote: >> >> That is what I have when I don't include the intermediate in the command: >> >> openssl s_client -connect 10.10.10.10:443 -verify 5 -state -showcerts >> verify depth is 5 >> CONNECTED(00000003) >> SSL_connect:before/connect initialization >> SSL_connect:SSLv2/v3 write client hello A >> SSL_connect:SSLv3 read server hello A >> depth=0 >> /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior >> Lake/O=ACME, INC/CN=www.acme.com >> verify error:num=20:unable to get local issuer certificate >> verify return:1 >> depth=0 >> /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior >> Lake/O=ACME, INC/CN=www.acme.com >> verify error:num=27:certificate not trusted >> verify return:1 >> depth=0 >> /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior >> Lake/O=ACME, INC/CN=www.acme.com >> verify error:num=21:unable to verify the first certificate >> verify return:1 >> >> And this one when I include the two intermediate at cacerts.pem. >> >> openssl s_client -connect 10.10.10.10:443 -verify 5 -CAfile >> cacerts.pem -showcerts >> verify depth is 5 >> CONNECTED(00000003) >> depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority >> verify return:1 >> depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA >> verify return:1 >> depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA >> verify return:1 >> depth=0 >> /serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior >> Lake/O=ACME, INC/CN=www.acme.com >> verify return:1 >> --- >> Certificate chain >> 0 >> s:/serialNumber=Tf20oDIbWDBfuhDWLEg4DfACRMOBnxA4/C=US/ST=Minnesota/L=Prior >> Lake/O=ACME, INC/CN=www.acme.com >> i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA >> >> >> >> On Tue, May 21, 2013 at 7:26 PM, Wim Lewis <w...@omnigroup.com> wrote: >> > >> > On 21 May 2013, at 5:02 PM, Jorge Ventura wrote: >> >> Because the client trust the connection when I inform the >> >> intermediate, I suppose the server is not sending the intermediate, >> >> only the first certificate in the chain and in this case the command >> >> fail. >> > >> > That is a reasonable conclusion. You can check for sure using the >> > "-showcerts" option to openssl s_client. >> > >> > >> > ______________________________________________________________________ >> > 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 > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
