In order to understand ECS certificates, you need to understand command/requests and users:

 

1. Requests & Users

There are 2 types of S3 requests/commands that are sent to ECS nodes and 2 types of types of users:

  1. management
  2. object

Management users make management requests. Object users make object requests

 

The APIs for both object and management requests are documented here:

https://www.emc.com/techpubs/api/ecs/v2-2-0-0/index.htm

 

 

1.1 Management Requests

Management requests are sent on port 4443.  These are ECS configuration type requests (e.g. creating/reading/updating/deleting of: replication groups, namespaces, mgmt. users, object users.

 

These requests can be sent via curl or the python ecscli.py tool (https://community.emc.com/docs/DOC-52139 ). Only object users send these requests to ECS. A mgmt. user will authenticate via username/password and will receive a token that is good for 24 hours. This token is sent in the X-SDS-AUTH-TOKEN header of each subsequent mgmt. command.

 

1.2 Object Requests

Object requests are sent on 9020 (http) and 9021 (https) for S3, 9022 (http) and 9023 (https) for Atmos, and 9024 (http) and 9025 (https) for Swift.  If you are using a load balancer these port numbers may be different. Talk to your IT staff to get load balancer information.

Typical object type requests are:

- Read a file/object from a bucket.

- Write a file to a bucket.

- Set metadata  on an object.

Only object users make these object requests. An object user has a secret key that is used to sign the request. No tokens or passwords sent to the ECS for these requests.

 

 

2. Keys/Certificates

There ECS allows you to configure two different ssl certificates:

  1. object certificate – for performing object requests over SSL. These https object requests are sent on port 9021, 9023, or 9025.
  2. management certificate – for performing ssl mgmt. and UI requests. These https mgmt. requests are sent on port 4443 and the UI requests are sent on port 443.

 

Both of these key/certificate pairs are uploaded to the ECS via management APIs on port 4443 (which means that the object key/certificate is uploaded via mgmt. command on port 4443 even though this certificate will be used for object requests by object users for https on port 9021)

 

 

You can upload either a self-signed certificate, a certificate signed by a CA authority or in the case of object certificate, you can request the ECS to generate one for you

 

2.1 Key/Certificate Formats and Generation

 

2.1.1Private Key File

2.1.1.1Passphrase

The private key file can not be passphrase protected. You need to either create the key/cert pair without putting a passphrase on the private key or the passphrase needs to be removed from the private key. This can be done by:

/path/to/openssl rsa -in /path/to/originalkeywithpass.key -out /path/to/newkeywithnopass.key

 

2.1.1.2Format

Private keys need to be in PKCS1 format. To verify the format:

head <private key file>

 

It should begin with “----- BEGIN RSA PRIVATE KEY ----- “

and not simply “----- BEGIN PRIVATE KEY ----- “

 

Unfortunately some newer versions of openssl create keys in pkcs8 format (the latter example) and ECS does not currently support that format

 

The example steps for generating the key and removing the passphrase will be shown in Certificate generation sections.

 

2.1.2Certificate

Certificates must be in pem encoded x509 format.


There are two options for certificate generation: generate a self-signed certificate, or purchase one from a certificate authority (CA).  For test purposes, the self-signed certificate is usually acceptable but you may need to go through some extra steps to have your clients validate the certificate (like installing it in your keystore).  For production purposes, a CA-signed certificate is strongly recommended since it can be validated by any client without any extra steps.

 

For maximum compatibility with object protocols, the Common Name (CN) on your certificate should point to the wildcard DNS entry used by S3 since S3 is the only protocol that utilizes virtually-hosted buckets (and thus, injects the bucket name into the hostname). There can only be one wildcard entry on an SSL certificate and it must be under the CN.  The other DNS entries for your load balancer for the Atmos and Swift protocols should be registered as a Subject Alternative Names (SANs) on the certificate.  The following examples will show how to generate a certificate or certificate request using openssl, but your IT organization may have different requirements or procedures for generating certificates.

 

2.1.2.2 Subject Alternative Names

When you create  a certificate, you generally specify the hostname where the certificate will be used. Since ECS has multiple nodes and they each have their own hostname, installing a certificate created for a specific hostname could cause a common name mismatch error on the nodes that don’t have that hostname. Certificates can be created with alternative IPs or hostnames called Subject Alternative Names (SANs)

 

 

 

2.1.2.3 Generate Certificate with SANs

OpenSSL doesn't allow you to pass Subject Alternative Names (SANs) through the command line so you have to add them to a configuration file first.  To do this, you'll have to locate your default OpenSSL configuration file. On ubuntu, this is located at /usr/lib/ssl/openssl.cnf.  Copy the file to a temporary directory where you will be generating your certificates.

 

root@ubuntu:~# cp /usr/lib/ssl/openssl.cnf request.conf

 

Edit the file with a text editor and append the following lines (note the space between the brackets and the name of the section):

 

step 1:

when installing on a load balancer, use the DNS variable

[ alternate_names ]

DNS.1 = os.example.com

DNS.2 = atmos.example.com

DNS.3 = swift.example.com

 

or

 

when installing directly on the hosts, use the IP prefix and the ip addresses of the nodes

[ alternate_names ]

IP.1 = 10.1.83.51

IP.2 = 10.1.83.52

IP.3 = 10.1.83.53

IP.4 = 10.1.83.54

 

step 2:

Now find the section [ v3_ca ] and add the following lines this section:

 

subjectAltName    = @alternate_names

basicConstraints = CA:FALSE

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

extendedKeyUsage = serverAuth

 

step 3:

The following line is likely to already exist in this [ v3_ca ] section. If you are creating a certificate signing request, you should comment it out as shown below:

 

#authorityKeyIdentifier=keyid:always,issuer

 

step 4:

In the [ req ] section:

x509_extensions = v3_ca #for self signed cert

req_extensions = v3_ca    #for cert signing req

 

step 5:

Finally, in the CA_default section, uncomment or add the lines:

 

copy_extensions = copy

 

 

 

Next, generate a private key to sign the request.  Keep this file safe; the security of your certificate depends on this private key and you'll need it later.

 

root@ubuntu:~# openssl genrsa -des3 -out server.key 2048

Generating RSA private key, 2048 bit long modulus

............................................................+++

.......+++

e is 65537 (0x10001)

Enter pass phrase for server.key: <enter a password>

Verifying - Enter pass phrase for server.key: <enter a password>

root@ubuntu:~# chmod 0400 server.key

 

Now that you have a private key, you can either create a certificate request (.req) to request a certificate from a CA or generate a self-signed certificate.  Note that in both cases, we're setting the Common Name (CN) on the certificate to *.os.example.com.

2.1.2.4 Certificate Request

root@ubuntu:~# openssl req -new -key server.key -config request.conf -out server.csr

Enter pass phrase for server.key: <your passprhase from above>

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:<Enter value>

State or Province Name (full name) [Some-State]:<Enter value>

Locality Name (eg, city) []:<Enter value>

Organization Name (eg, company) [Internet Widgits Pty Ltd]: <Enter value>

Organizational Unit Name (eg, section) []:<Enter value>

Common Name (e.g. server FQDN or YOUR name) []:*.os.example.com

Email Address []:<admin email>

 

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []: <optional>

An optional company name []: <optional>

 

You can then use openssl to check the contents of your request.  In particular, you'll want to check that the SANs are correctly set (in yellow below).

root@ubuntu:~# openssl req -in server.csr -text -noout

Certificate Request:

    Data:

        Version: 0 (0x0)

        Subject: C=US, ST=Minnesota, L=Plymouth, O=EMC, OU=ASD, CN=*.os.example.com/emailAddress=admin@example.com

        Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:bc:8f:83:7b:57:72:3d:70:ef:b9:d0:f9:97:71:

b7:5a:dc:ca:39:73:53:6b:ab:a7:10:7a:20:c1:75:

9b:36:9b:dc:bc:7d:16:f9:e5:c7:2c:d7:1b:80:98:

4e:d9:7f:8f:d8:e1:57:07:9a:61:38:5c:f1:1b:95:

6f:3c:d7:ef:e0:03:ce:19:82:77:84:07:7b:b8:c0:

ee:d9:5b:2d:c2:5e:1e:fb:e3:78:04:af:d6:6f:58:

14:de:fb:8a:ea:6c:60:5c:fd:f4:86:31:d5:fd:c5:

74:c0:89:55:e1:83:ac:6f:b6:f4:6b:89:d6:15:76:

36:80:64:ca:72:2d:f3:44:9c:60:5a:12:35:5b:87:

4b:b7:54:b1:36:44:c6:d0:0a:2b:40:ab:1b:f3:9e:

a9:93:56:66:b6:af:fe:c1:fd:02:fd:ce:e7:59:7c:

d2:dc:e8:e1:3e:58:2b:6e:f4:74:15:db:12:ae:32:

2a:51:a0:31:bd:27:5f:a9:45:8a:5b:7d:18:87:54:

3a:ae:4e:f4:70:ae:23:a3:24:55:87:1f:e2:98:33:

0a:17:5f:0b:9a:1b:e8:b6:48:47:bc:81:e8:63:e1:

fe:38:21:ed:97:5f:bc:3f:b4:7b:64:dd:e0:67:4e:

a8:9e:66:86:43:0a:fd:31:3d:69:b1:03:20:51:39:

db:77

Exponent: 65537 (0x10001)

        Attributes:

        Requested Extensions:

X509v3 Subject Alternative Name:

DNS:os.example.com, DNS:atmos.example.com, DNS:swift.example.com

X509v3 Basic Constraints:

CA:FALSE

X509v3 Key Usage:

Digital Signature, Non Repudiation, Key Encipherment

X509v3 Extended Key Usage:

TLS Web Server Authentication

    Signature Algorithm: sha256WithRSAEncryption

2c:7a:f3:7d:8e:8d:37:8f:66:c8:91:16:c0:00:39:df:03:c1:

         9d:22:2f:50:d3:15:e6:85:c2:1e:a2:78:c2:07:b5:d7:0c:3b:

93:80:53:44:cc:a3:b0:5c:2d:6b:c1:58:ec:82:54:63:e0:80:

         9e:2f:b9:d1:40:c6:70:54:8e:66:96:20:1f:3d:26:dc:4c:40:

         78:4f:bf:5a:14:d0:ff:03:55:7d:26:44:51:02:c2:dd:94:88:

         10:84:70:09:0a:45:0e:5a:6b:89:2a:11:1b:e9:6a:0b:ea:74:

f6:fb:a9:ea:dc:8f:be:e8:f7:6b:a4:40:bc:b5:d6:98:cf:f6:

a6:30:67:8f:c7:b2:0b:8a:4f:6f:65:c2:0a:d8:3b:dd:8a:6e:

3a:65:04:a9:de:83:79:45:81:69:eb:73:48:0c:da:0a:0d:ad:

         b4:dd:b3:86:ec:a4:09:c6:e8:67:64:24:19:a2:00:81:7b:27:

65:fc:d9:69:f6:d8:4a:ea:63:63:f9:b7:33:8f:1d:e2:35:09:

8e:34:46:c4:24:70:ac:a3:a4:8a:a8:a5:dc:33:66:dc:f1:8b:

26:5c:b7:bd:02:9c:d8:22:45:0c:3a:cb:9b:87:b7:2b:7f:73:

82:d9:68:ff:be:e4:4e:e1:78:16:67:47:14:01:31:32:0e:a2:

         67:a2:49:c3

 

Now that you have your certificate request, you can submit it to your CA who will send you a signed certificate file.

 

2.1.2.5 Self-Signed Certificate

Generating a self-signed certificate is almost identical to generating the request.  The only difference is that instead of generating a request file you add an -x509 argument to generate a certificate file.

 

root@ubuntu:~# openssl req -x509 -new -key server.key -config request.conf -out server.crt

Enter pass phrase for server.key: <your passprhase from above>

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:<Enter value>

State or Province Name (full name) [Some-State]:<Enter value>

Locality Name (eg, city) []:<Enter value>

Organization Name (eg, company) [Internet Widgits Pty Ltd]: <Enter value>

Organizational Unit Name (eg, section) []:<Enter value>

Common Name (e.g. server FQDN or YOUR name) []:*.os.example.com

Email Address []:<admin email>

 

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []: <optional>

An optional company name []: <optional>

 

You can then use openssl's x509 command to view the certificate.  Make sure your SANs are present in the certificate.

 

root@lviprj140:~# openssl x509 -in server.crt -noout -text

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 11095856477230454626 (0x99fc66ad7c09d762)

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: C=US, ST=Minnesota, L=Plymouth, O=EMC, OU=ASD, CN=*.os.example.com/emailAddress=admin@example.com

        Validity

Not Before: Oct 14 16:47:40 2014 GMT

Not After : Nov 13 16:47:40 2014 GMT

        Subject: C=US, ST=Minnesota, L=Plymouth, O=EMC, OU=ASD, CN=*.os.example.com/emailAddress=admin@example.com

        Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:bc:8f:83:7b:57:72:3d:70:ef:b9:d0:f9:97:71:

b7:5a:dc:ca:39:73:53:6b:ab:a7:10:7a:20:c1:75:

9b:36:9b:dc:bc:7d:16:f9:e5:c7:2c:d7:1b:80:98:

4e:d9:7f:8f:d8:e1:57:07:9a:61:38:5c:f1:1b:95:

6f:3c:d7:ef:e0:03:ce:19:82:77:84:07:7b:b8:c0:

ee:d9:5b:2d:c2:5e:1e:fb:e3:78:04:af:d6:6f:58:

14:de:fb:8a:ea:6c:60:5c:fd:f4:86:31:d5:fd:c5:

74:c0:89:55:e1:83:ac:6f:b6:f4:6b:89:d6:15:76:

36:80:64:ca:72:2d:f3:44:9c:60:5a:12:35:5b:87:

4b:b7:54:b1:36:44:c6:d0:0a:2b:40:ab:1b:f3:9e:

a9:93:56:66:b6:af:fe:c1:fd:02:fd:ce:e7:59:7c:

d2:dc:e8:e1:3e:58:2b:6e:f4:74:15:db:12:ae:32:

2a:51:a0:31:bd:27:5f:a9:45:8a:5b:7d:18:87:54:

3a:ae:4e:f4:70:ae:23:a3:24:55:87:1f:e2:98:33:

0a:17:5f:0b:9a:1b:e8:b6:48:47:bc:81:e8:63:e1:

fe:38:21:ed:97:5f:bc:3f:b4:7b:64:dd:e0:67:4e:

a8:9e:66:86:43:0a:fd:31:3d:69:b1:03:20:51:39:

db:77

Exponent: 65537 (0x10001)

        X509v3 extensions:

X509v3 Extended Key Usage:

TLS Web Server Authentication

X509v3 Subject Alternative Name:

DNS:os.example.com, DNS:atmos.example.com, DNS:swift.example.com

X509v3 Basic Constraints:

CA:FALSE

X509v3 Key Usage:

Digital Signature, Non Repudiation, Key Encipherment

    Signature Algorithm: sha256WithRSAEncryption

0e:51:d0:48:df:a3:b0:0c:ce:f8:ea:c6:e0:26:be:ef:d4:87:

         7f:d3:36:36:b3:ef:a2:7d:17:a3:00:e3:2b:58:2f:5c:a8:f8:

a2:7f:85:a0:e8:f3:73:c0:27:74:b8:bf:3b:af:a7:ed:04:f1:

05:86:b5:7e:75:47:50:a7:24:7a:da:a1:bb:0e:a6:09:7b:f1:

31:e8:6f:44:e2:82:4e:5f:7b:f2:25:85:63:c7:27:f8:d3:86:

         e5:ce:2f:42:42:15:e9:9f:fd:02:13:13:01:c9:3e:1c:6e:f5:

         25:11:52:0f:49:5f:61:40:f1:2a:b4:4f:b7:b2:8a:d7:ef:b4:

60:c2:db:34:65:4f:ca:aa:df:c7:ff:e3:c2:41:3a:28:9c:39:

3a:cd:de:5b:81:71:a3:6b:d9:61:0e:d5:4a:47:fb:e2:77:b2:

         07:b3:32:c6:e1:cf:5c:2c:a6:89:ac:77:45:d3:56:96:47:11:

b1:ee:28:4f:ca:35:7f:90:6e:70:c4:fb:78:15:d3:ab:f2:51:

         08:87:83:80:cf:89:6b:61:d9:ce:41:64:08:58:12:58:1c:a1:

dc:2b:82:93:b6:80:63:4b:ab:c2:f6:fa:0c:ba:c7:21:01:da:

         9b:5f:a9:4d:a3:42:dd:3d:4b:ca:50:76:c9:86:dd:36:76:3a:

         e5:7a:18:9f

 

2.1.2.6 Chain File

In both cases (self signed and CA signed), you should now have a certificate file. In the case of a self-signed certificate, the certificate is the chain file.  If your certificate was signed by a CA, you'll need to append the intermediate CA cert(s) to your certificate.

Do NOT append the root CA certificate:

 

root@ubuntu:~# cp server.crt serverCertChain.crt

root@ubuntu:~# cat intermediateCert.crt >> serverCertChain.crt

 

 

 

 

 

 

2.2 Uploading keys/Certificates:

 

When using either the python cli or the curl command, you need to be authenticated to the ECS mgmt interface.

You need a request to authenticate/login. For python, please see the instructions for the "authenticate" command.

 

Using curl:

curl -L --location-trusted -k https://<ip of ECS node>:4443/login -u "root:password" -v


curl -L --location-trusted -k https://10.247.100.247:4443/login -u "root:ChangeMe" -v

 

< HTTP/1.1 200 OK

< Date: Fri, 09 Dec 2016 22:30:25 GMT

< Content-Type: application/xml

< Content-Length: 93

< Connection: keep-alive

< X-SDS-AUTH-TOKEN: BAAcWGVaT3dEZVRIcG1IM21DZUpxR2lRcFJ2ZFVJPQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOjhkMmMzNmU3LTc2YjAtNDEzNS05Y2Y2LWFiYjZiZmFmYThjYwIADTE0ODEzMTQ0MDg3NDUDAC51cm46VG9rZW46NTFmOWQ5MDQtNGU0ZC00ZTFjLWIyMmYtYWE5YTAzM2UyM2MzAgAC0A8=


In the instructions that follow the X-SDS-AUTH-TOKEN is the BAA....A8=

In a unix shell terminal, you can set a TOKEN with:

export TOKEN=BAAcWGVaT3dEZVRIcG1IM21DZUpxR2lRcFJ2ZFVJPQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOjhkMmMzNmU3LTc2YjAtNDEzNS05Y2Y2LWFiYjZiZmFmYThjYwIADTE0ODEzMTQ0MDg3NDUDAC51cm46VG9rZW46NTFmOWQ5MDQtNGU0ZC00ZTFjLWIyMmYtYWE5YTAzM2UyM2MzAgAC0A8=

 

This randomly generated TOKEN string occasionally expires, but should be valid for 24 hours.

 

2.2.1 Installing key/certificate pair for MANAGEMENT requests/users:

 

The api for the management certificate upload request:

https://www.emc.com/techpubs/api/ecs/v2-2-0-0/VDCKeystoreService_setKeyCertificatePair_ac181a68892973691944aff245349900_b2081f90369a6d96de7811240fd3b244_detail.htm

 

 

Using the python ecscli tool:

python ecscli.py vdc_keystore update –hostname <ecs host ip> -port 4443 –cf <cookiefile> –privateKey <privateKey> -certificateChain <certificateChainFile>

 

 

alternatively, using curl:

First will need

curl -L --location-trusted -k https://10.247.100.247:4443/login -u "root:ChangeMe" -v

 

curl -svk -H "X-SDS-AUTH-TOKEN: $TOKEN" -H "Content-type: application/xml" -H "X-EMC-REST-CLIENT: TRUE"  -X PUT -d "<rotate_keycertchain><key_and_certificate><private_key>`cat privateKeyFile`</private_key><certificate_chain>`cat certChainFile`</certificate_chain></key_and_certificate></rotate_keycertchain>" https://X.X.X.X:4443/vdc/keystore

 

Unfortunately, the ECS nginx service will need to be restarted on each of the ECS nodes in order to get the newly uploaded certificate to be used. You will need to ssh onto one of the nodes. Nginx runs inside the blobsvc docker container on each node. So you will not have access to the nginx service by simply ssh’ing onto the node. You will need to run the restart command inside the container. Depending upon the version of ECS, the sudo may or may not be enabled. If sudo is available you can use viprexec to distribute a single command to the container on all ECS nodes:

 

ssh admin@<ecs node ip address>

sudo -i viprexec -i -c "/etc/init.d/nginx restart;sleep 60;/etc/init.d/nginx status"

 

 

2.2.2 Installing a key/certificate pair for OBJECT users/requests:

 

The API for the object certificate upload request:

https://www.emc.com/techpubs/api/ecs/v2-2-0-0/ObjectCertificateService_13b21af0b283a828d2c9204e31a2b2f5_overview.htm

 

 

Using the python ecscli tool:

python ecscli.py keystore update –hostname <ecs host ip> -port 4443 –cf <cookiefile> -pkvf <privateKey> -cvf <certificateChainFile> -ss false

 

using curl, you need to use the xml format (so that carriage returns, etc will be handled via the `cat` command):

curl -svk -H "X-SDS-AUTH-TOKEN: $TOKEN"

-H "Content-type: application/xml" -H "X-EMC-REST-CLIENT: TRUE"  -X PUT -d "<rotate_keycertchain><key_and_certificate><private_key>`cat privateFile.key`</private_key><certificate_chain>`cat certChainFile.pem`</certificate_chain></key_and_certificate></rotate_keycertchain>" https://X.X.X.X:4443/object-cert/keystore

 

NOTE: That even though this is the object certificate to be used for object requests sent on port 9021, this upload command is a management command which is sent on port 4443

 

Once this is done It can take up to 2 hours for the certificate to be distributed to all nodes. However, this certificate is immediately distributed upon dataheadsvc restart of the node where the certificate was uploaded and can be done if sudo is available on the node.

 

ssh admin@<ecs_ip_where_cert_uploaded>

 

sudo kill `pidof dataheadsvc`

 

 

The dataheadsvc monitoring service will automatically restart the dataheadsvc

 

 

2.3 Verifying the Installed Certificates

The object certificate and management certificate each have their own GET request to retrieve the installed cert. Once again, both of these commands are management request

 

2.3.1 Verifying the installed/Active Management Certificate

 

https://www.emc.com/techpubs/api/ecs/v2-2-0-0/VDCKeystoreService_getCertificateChain_e7ead70eedc2bcb79f6788664cc42b85_b2081f90369a6d96de7811240fd3b244_detail.htm

 

 

using the python ecscli.py tool:

python ecscli.py vdc_keystore get –hostname <ecs host ip> -port 4443 –cf <cookiefile>

 

or via curl:

curl -svk -H "X-SDS-AUTH-TOKEN: $TOKEN" https://x.x.x.x:4443/vdc/keystore

 

 

2.3.2 Verifying the installed/Active Object Certificate

 

https://www.emc.com/techpubs/api/ecs/v2-2-0-0/ObjectCertificateService_getCertificateChain_8b62f07f5281d5525f23c2f75d1591a4_13b21af0b283a828d2c9204e31a2b2f5_detail.htm

 

using the python ecscli.py tool:

python ecscli.py keystore show –hostname <ecs host ip> -port 4443 –cf <cookiefile>

 

or via curl:

curl -svk -H "X-SDS-AUTH-TOKEN: $TOKEN" https://x.x.x.x:4443/object-cert/keystore

 

 

You can also check the certificate presented by a port by using OpenSSL’s s_client:

 

openssl s_client -connect host:port -showcerts

 

  1. e.g. since object requests to ECS test drive on port 443, the object certificate can be verified by:

 

openssl s_client -connect object.ecstestdrive.com:443 –showcerts

 

CONNECTED(00000003)

depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2008 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA - G3

verify return:1

depth=1 C = US, O = "thawte, Inc.", CN = thawte SHA256 SSL CA

verify return:1

depth=0 C = US, ST = Massachusetts, L = Bedford, O = EMC, OU = Advanced Software Division, CN = *.object.ecstestdrive.com

verify return:1

---

Certificate chain

0 s:/C=US/ST=Massachusetts/L=Bedford/O=EMC/OU=Advanced Software Division/CN=*.object.ecstestdrive.com

i:/C=US/O=thawte, Inc./CN=thawte SHA256 SSL CA

-----BEGIN CERTIFICATE-----

MIIFVDCCBDygAwIBAgIQOFpBhTIHb/ZUIpbeLF43rzANBgkqhkiG9w0BAQsFADBD

MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMdGhhd3RlLCBJbmMuMR0wGwYDVQQDExR0

aGF3dGUgU0hBMjU2IFNTTCBDQTAeFw0xNTEyMDQwMDAwMDBaFw0xNzEyMDIyMzU5

NTlaMIGOMQswCQYDVQQGEwJVUzEWMBQGA1UECAwNTWFzc2FjaHVzZXR0czEQMA4G

A1UEBwwHQmVkZm9yZDEMMAoGA1UECgwDRU1DMSMwIQYDVQQLDBpBZHZhbmNlZCBT

b2Z0d2FyZSBEaXZpc2lvbjEiMCAGA1UEAwwZKi5vYmplY3QuZWNzdGVzdGRyaXZl

LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOzUkRLkCCsD0/UF

ZyHHuSzjyrOwWfuSFveeVEwkwFYdzIW7nM/hyxU3V5LWgetVra6l2LG1JQx/VUaR

k81YK11HnLUAs0xkS/NYw7TuwzgHlk6RuOXSFU8516NAdW1KAtHReLpER0gCHhrf

y7XYBQETwKuQlRNu7K60Nzo0MSye4jCKA8u74rEekFhoQoILamhYlY8EWNr36Xeq

ljZ10tbawWYM+emegxBjNuQNIy0pEPX27RRGpfTWMBW+X7qIHAq7Go4MLcQ5bJqh

4siUhHo4/kSLRp2rn2WSYy1QDsg6gLFY6EyOj/gqMmygKTE28yGBOCkpyz329Ly9

vUbHgR8CAwEAAaOCAfYwggHyMIGeBgNVHREEgZYwgZOCFmF0bW9zLmVjc3Rlc3Rk

cml2ZS5jb22CFGNhcy5lY3N0ZXN0ZHJpdmUuY29tghdwb3J0YWwuZWNzdGVzdGRy

aXZlLmNvbYIWc3dpZnQuZWNzdGVzdGRyaXZlLmNvbYIXb2JqZWN0LmVjc3Rlc3Rk

cml2ZS5jb22CGSoub2JqZWN0LmVjc3Rlc3Rkcml2ZS5jb20wCQYDVR0TBAIwADBu

BgNVHSAEZzBlMGMGBmeBDAECAjBZMCYGCCsGAQUFBwIBFhpodHRwczovL3d3dy50

aGF3dGUuY29tL2NwczAvBggrBgEFBQcCAjAjDCFodHRwczovL3d3dy50aGF3dGUu

Y29tL3JlcG9zaXRvcnkwDgYDVR0PAQH/BAQDAgWgMB8GA1UdIwQYMBaAFCuaNa4B

GDgw4XB6BeARdqPOvZAUMCsGA1UdHwQkMCIwIKAeoByGGmh0dHA6Ly90Zy5zeW1j

Yi5jb20vdGcuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBXBggr

BgEFBQcBAQRLMEkwHwYIKwYBBQUHMAGGE2h0dHA6Ly90Zy5zeW1jZC5jb20wJgYI

KwYBBQUHMAKGGmh0dHA6Ly90Zy5zeW1jYi5jb20vdGcuY3J0MA0GCSqGSIb3DQEB

CwUAA4IBAQCheGTBFUIcVIynoKiYuWAS0YY4nqM+nv+wU8qQsakt4hPgK9qGH7EK

lvX1omw1vZcD6aiDQH1kyaMC/SgqwQfFVUy4iMqFAINssz8OCjAajpnRzyG//V2C

PG2+MqjzUZbLNIcICd3YOEiy4Ooxa/jgRLsIhOx87VjUgYHbh+bcNEbV5hCZxQe8

5MwOqr6NY67C8dTiiRCMEMt/auKM+qa9ZnUHT0suFUqTPyxkrtk2acbzvzsjgHOb

BoyGlabbkWxjlJmvE7VPmDvz8944NlFgRw2DZUWyO1AMI9kjCkUMXdKNDoui2S71

dDweLjSe7dHB3FhdGpyUXubmkg2Hex+E

-----END CERTIFICATE-----

1 s:/C=US/O=thawte, Inc./CN=thawte SHA256 SSL CA

i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2008 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G3

-----BEGIN CERTIFICATE-----

MIIEwjCCA6qgAwIBAgIQNjSeGMmcJmm2Vi5s5a1xMjANBgkqhkiG9w0BAQsFADCB

rjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMf

Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UECxMvKGMpIDIw

MDggdGhhd3RlLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxJDAiBgNV

BAMTG3RoYXd0ZSBQcmltYXJ5IFJvb3QgQ0EgLSBHMzAeFw0xMzA1MjMwMDAwMDBa

Fw0yMzA1MjIyMzU5NTlaMEMxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwx0aGF3dGUs

IEluYy4xHTAbBgNVBAMTFHRoYXd0ZSBTSEEyNTYgU1NMIENBMIIBIjANBgkqhkiG

9w0BAQEFAAOCAQ8AMIIBCgKCAQEAo2Mr1LpdOK6wz7lMON8gffErR3Edi2jzVvmc

2qrlhCbepXEwvPMxI53oO4DIZld1tlcO25P1Jo5wumRSZooqiFxEGE2oony9VmEy

kBL5NYdIYLBukGdEAY3nyQ1jaHJyq2M8hrgffa2IJadqiCn7WcZ4cV8suonm04D9

V+y5UV9DMy5+JTukBNFgjLNEM5MMrSq2RKIZO6/EkG97BYeGmyxqnStsd8kAn8nP

rO0+G/fD89n4bNSgV8T7KDKqM/Dmupjf5cJOnHS/ikjC8hvwd0BBBwSyOtVMxCmp

EUA/AkbwkdXSgYOGE7Mx7UarqId2qZl9vM0xUPSltdylMrOLiwIDAQABo4IBRDCC

AUAwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3

dGUuY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwQQYDVR0gBDowODA2BgpghkgBhvhF

AQc2MCgwJgYIKwYBBQUHAgEWGmh0dHBzOi8vd3d3LnRoYXd0ZS5jb20vY3BzMDcG

A1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQQ0Et

RzMuY3JsMA4GA1UdDwEB/wQEAwIBBjAqBgNVHREEIzAhpB8wHTEbMBkGA1UEAxMS

VmVyaVNpZ25NUEtJLTItNDE1MB0GA1UdDgQWBBQrmjWuARg4MOFwegXgEXajzr2Q

FDAfBgNVHSMEGDAWgBStbKqUYJzt5P/6Pgp0K2MD97ZZvzANBgkqhkiG9w0BAQsF

AAOCAQEAdKZW6K+Tlhn7JvkNsESlzel6SAN0AWwTcbfggpCZYiPj1pmv8McenqgY

Idu0lD80VhuZVS+O8EUzMrdywRNbNNP1YOUuGNFcxWrBqodQDBydZCv/G9zVLmEL

57m2kVOG2QMq0T17StorB74p8mBCqZEaDi480X2lExQC+u6LjbbIuD5WgVchJD9l

w7TJzlyNRqxT8/lVdMgr/dJ4cPX4EeX0p60g9Z3x7HD2E6zmjI3bP8byeQ6rUvLM

G3knzxaz1vPGNoBD7MWU8N2QjfjGUkZW63RHvqbzGa5xTMDh59TP7dQGKCoRPLrZ

QW4A54E3k+TaYsYdZ29jtBSG2aZi8A==

-----END CERTIFICATE-----

---

Server certificate

subject=/C=US/ST=Massachusetts/L=Bedford/O=EMC/OU=Advanced Software Division/CN=*.object.ecstestdrive.com

issuer=/C=US/O=thawte, Inc./CN=thawte SHA256 SSL CA

---

No client certificate CA names sent

Peer signing digest: SHA512

Server Temp Key: ECDH, P-256, 256 bits

---

SSL handshake has read 3252 bytes and written 433 bytes

---

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

No ALPN negotiated

SSL-Session:

Protocol  : TLSv1.2

Cipher    : ECDHE-RSA-AES128-GCM-SHA256

Session-ID: 47D2750DCC4511CAD952DB2499E3C01DF9BF2242B39EEC6D81B2EBA65787C0F7

Session-ID-ctx:

Master-Key: 546D7DE00F80A4055936AAE0C88178E7746FD4DBE275093D415101D2827D9F632E53588752D170D42F60B7F0F882C314

Key-Arg   : None

PSK identity: None

PSK identity hint: None

SRP username: None

TLS session ticket lifetime hint: 300 (seconds)

TLS session ticket:

0000 - 69 30 cf af 5f 52 46 75-49 5c f1 9f 1a 2a 00 b2   i0.._RFuI\...*..

0010 - 05 8d 69 d8 11 90 d0 b8-ef db ab ae fd 84 76 a9   ..i...........v.

0020 - 83 6c 9c 83 08 51 ec 5e-ed 9f 3f ef 25 22 ab 40   .l...Q.^..?.%".@

0030 - 7f 85 79 58 c2 06 62 c4-54 fb 29 6c 2e b5 c3 47   ..yX..b.T.)l...G

0040 - 5b de 1b bd 11 cc 08 c9-0a f7 79 e0 9d ae 60 d7   [.........y...`.

0050 - c9 1b 6a 4a 40 ce 9e 9b-70 80 2a 56 7e 50 5f 3d   ..jJ@...p.*V~P_=

0060 - 42 91 ee a4 d5 09 a6 5b-8b 17 58 9d 78 8b 79 df   B......[..X.x.y.

0070 - 97 fe 5b 6a e4 81 94 a3-7f fa e3 57 8c 88 7b ad   ..[j.......W..{.

0080 - e7 ef b1 07 d1 2e db 14-59 3e 3f a0 be ed a1 9e   ........Y>?.....

0090 - bd 14 f2 3c a2 45 2e 77-8d a3 04 ac 1f c5 1a fa   ...<.E.w........

 

Start Time: 1466169790

Timeout   : 300 (sec)

Verify return code: 0 (ok)