OpenSSL and the certification chain verification – CentOS / Linux using s_client

If one needs to validate / verify the certificate chain and the following message is spewed out by “OpenSSL” on the client (s_client or any tool that utilized OpenSSL under the hood such as curl or wget)  then this implies that either the server is really setup for SSL / TLS using a self-signed  certificate or the client does not have access to the root to validate the server certificate that is being returned by the SSL server as part of the “Server Hello” step of the SSL handshake. [One can utilize the " -showcerts" option to delineate and confirm either of the two situations elucidated above]

What we really need to see as a result of a successful verification of the server certificate is:

In order to achieve this with s_client, we can either utilize the "CApath" option or the "CAfile" option. [man s_client for more details]

The two options to achieve successful verification of the server certificate (Option 2 is a little more straightforward and you can try that first):

Option 1: [check to see the default location of the version of OpenSSL that is being used]


$ openssl version -a

 

OpenSSL 1.0.1c 10 May 2012
built on: Tue Nov 13 04:53:59 UTC 2012
platform: linux-x86_64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/local/ssl"

You are interested in the OPENSSLDIR setting where you would find the "certs" folder and that is the default directory of trusted certificates. The certificate of the root Certification Authority (CA) should be a constituent of this folder but there is a peculiarity which is that the certificate should be named or symbolically linked as in "hash.0" where "hash" is the hashed certificate subject name. One could use "c_rehash" script to automate this part.

Copy the root CA certificate to the "certs" folder. And:

$ cd $OPENSSLDIR

$ c_rehash certs [this would do the trick]

$ ll certs [Check the folder to make sure that the necessary symbolic link is created]
total 4
lrwxrwxrwx 1 root root   10 Nov 16 07:34 beebff74.0 -> cacert.pem
-rw-r--r-- 1 root root 1135 Nov 16 07:26 cacert.pem

Run s_client:

$ openssl s_client -connect myHost.com443  -CApath /usr/local/ssl/certs/

And voila, the certification validation is successful since at the end we have:

Verify return code: 0 (ok)

Option 2: [Use the CAfile option]


$ openssl s_client -connect ec2-23-20-189-47.compute-1.amazonaws.com:443  -CAfile /app/sslca/cacert.pem

That should lead to the same result of successful server certificate validation.

 

Copy (scp without password) files to Amazon EC2 instance

While copying files (scp) to Amazon EC2 instance, got the following error:


$ scp ~/Downloads/pcre-8.31.tar.gz  -i /Users/khanna/Downloads/k2.pem ec2-user@xxx.amazonaws.com:/tmp
Permission denied (publickey).
lost connection

The error message is not that intuitive to debug but after some researching it turned out that the order of arguments was incorrect. This fixes that:


$ scp  -i /Users/khanna/Downloads/k2.pem  ~/Downloads/pcre-8.31.tar.gz  ec2-user@xxx.amazonaws.com:/tmp