Showing posts with label ssl certificate. Show all posts
Showing posts with label ssl certificate. Show all posts

Saturday, May 23, 2020

Use openssl to check SSL Certificate

Modern browsers provide the GUI to quickly check SSL certificate details

Sometimes in Linux environment, we need to use command line to check SSL certificate, then openssl comes to the picture.

$ echo | openssl s_client -servername NAME -connect HOST:PORT 2>/dev/null | openssl x509
$ echo | openssl s_client -servername NAME -connect HOST:PORT 2>/dev/null | openssl x509 -noout -${param}
  • -text: print ssl certificate in text format, like echo | openssl s_client -connect www.google.com:443 2>/dev/null | openssl x509 -text
  • -fingerprint: print certificate fingerprints
  • -dates: print notBefor and notAfter date and time
  • -subject: print subject name
  • -issuer: print certificate issuer CA
Run man s_client to see the all available options.
Run man x509 to see the all available options.

Use below command to check ssl cert chain
openssl s_client -showcerts -connect example.com:443 -servername example.com

SSL certificate formats

There are 3 SSL Certificate Formats and Encodings
  1. The most commonly used encoding schema for X.509 certificate files is the PEM (Privacy Enhanced Mail) encoding
  2. DER (Distinguished Encoding Rules) is another popular encoding used to store X.509 certificate files.
  3. PKCS refers to a group of public-key cryptography standards devised and published by RSA Security. 

What is inside an SSL certificate?

An SSL certificate usually contains a name, public key, the digital signature of the certificate issuer, the name of the issuer, certificate serial number, expiration date and additional information.

X.509 Version 3 certificates support the following fields:
Subject: Provides the entity details that the CA issues the certificate to.
Issuer: Provides a distinguished name for the CA that issued the certificate.
Validity: Provides the date and time when the certificate becomes valid, and becomes invalid. The date when an application evaluates the certificate must fall between the Valid From and Valid To fields.
Serial Number: Provides a unique identifier for each certificate that a CA issues.
Public Key: Contains the public key of the key pair that is associated with the certificate
Signature Algorithm: The algorithm used to sign the certificate, like SHA-256 with RSA Encryption
Signature: Bit string containing the digital signature, like 512 bytes : 0D 60 34 91 79 92 CE 50 AE xx xx .....
Fingerprints: Provides the unique identifier of the certificate. In X.509-based PKI system, fingerprints are primarily used to authenticate root keys. 

X.509 version 3 certificates also include optional extensions:
Subject Alternative Name: This extension allows multiple hostnames to be protected by a single certificate. SAN certificate is also known as Unified Communication Certificate (UCC) or a multi-domain certificate.

CRL distribution points (CDP): When a server presents a certificate, an application or client must determine whether the certificate has been revoked. The CDP extension provides one or more URLs where the application or service can retrieve the certificate revocation list (CRL) from.

Authority Information Access (AIA): When validating a certificate, the certificate of the CA that issued the certificate, also referred to as the parent CA, must also be evaluated for revocation and validity. This extension provides one or more URLs from where an application can retrieve the issuing CA certificate.

Enhanced Key Usage (EKU): This attribute includes an object identifier (OID) for each application  a certificate can be used for. Each OID is a unique sequence of numbers from a worldwide registry.

Certificate policies: Describes what measures an organization takes to validate the identity of a certificate requestor before it issues a certificate. An OID is used to represent the validation process and can include a policy-qualified URL that fully describes the measures taken to validate the identity.

What is an SSL certificate?

An SSL certificate is a digital certificate that authenticates the identity of a website or a server. The most widely accepted format for certificates is X.509.

A CA (Certification Authority) is a trusted third party that vouches for the identity of individuals and organizations.  Essentially the certificate authorities maintain a large database of public keys which are distributed as requested. For instance, Godaddy, DigiCert, Verisign etc are popular CAs.

A Certificate Request is used to obtain a CA signed Server Certificate or Client Certificate from a Certification Authority.

A Server Certificate is digital certificate used to identify the server to clients when they connect.  The public and private keys associated with the server certificate are also used to encrypt the SSL session key information.

A Client Certificate is a digital certificate used to identify individuals when they connect to an SSL server.

Self-Signed Server Certificates are as cryptographically secure as CA signed certificates but are generally not "trusted" by client programs (e.g. browsers).

A Signing Certificate is used to digitally sign a client or server certificate during the certificate generation process. It is part of the certificate chain.

A Root Certificate is the starting certificate in a certificate hierarchy.  All certificates contain information tracing their origin back to a Root Certificate.  A Trusted Root Certificate is one where the root certificate is known to the requester.  The Trusted Root Certificate must be installed at the client when authenticating a Server Certificate.  A Trusted Root Certificate must be installed at the server when authenticating a Client Certificate. (See Mutual TLS authentication)

A Certificate Private Key is used to decrypt messages encrypted using the Certificate Public Key contained in a digital certificate.  The Private Key is generally password protected using the Private Key Password (passphrase) to prevent unauthorized use of the Private Key.  If the Private Key Password is compromised, the Certificate must be revoked and a new one generated.

How does the client (e.g. browser) know when to trust an SSL certificate?

The connection is trusted if:
  • The root certificate for your website matches the pre-installed root certificate in the browser
  • None of the certificates in the chain on the server are invalid, expired or revoked.
  • The domain name in your certificate matches the domain name in the URL.

Friday, May 10, 2019

ssl certificate 101

A certificate verifies that an entity is the owner of a particular public key.

Certificates that follow the X.509 standard contain a data section and a signature section. The signature section is to verify the certificate authenticity, and the data section includes such information as:
  • The Distinguished Name of the entity that owns the public key
  • The Distinguished Name of the entity that issued the certificate
  • expiration info
  • The public ke
You can obtain a certificate from a Certificate Authority (CA) such as VeriSign, Godaddy etc. Alternately, you can create a self-signed certificate, in which the owner and the issuer are the same.

An organization that issues certificates can establish a hierarchy of CAs. The root CA has a self-signed certificate. Each subordinate CA has a certificate that is signed by the next highest CA in the hierarchy. A certificate chain is the certificate of a particular CA, plus the certificates of any higher CAs up through the root CA. (certificate chain)

https://docs.oracle.com/cd/E19509-01/820-3503/ggbgc/index.html

ssl certificate and private key

In normal key-pair based PKI (public key infrastructure), there are private key and public key as a pair (Use one key to encrypt, and use the other key to decrypt). In a certificate-based system, there are private key and certificate.

Public-key cryptography is based on the concept of a key pair, which consists of a public key and a private key. Data that has been encrypted with a public key can be decrypted only with the corresponding private key. Conversely, data that has been encrypted with a private key can be decrypted only with the corresponding public key.

Certificate holds more information than the public key. The certificate is a wrapper for the public key, in addition, it contains additional information such as issuer, what the certificate is supposed to be used for, and other types of metadata. Certificate also contains signature to help verify the public key ownership.

Typically, a certificate is signed by a certificate authority (CA) using CA's private key. This verifies the authenticity of the certificate. Company A's public key signed with a valid CA's private key is called company A's certificate.

Servers are typically configured with certificates issued by well-known issuers called Certificate Authorities (CAs). Similar to a server, a CA has a certificate and a private key. When issuing a certificate for a server, the CA signs the server certificate using its private key. The client can then verify that the server has a certificate issued by a CA the client trusts. Client (like browsers) generally contains a list of well known CAs that it trusts.

In short, server has a certificate signed by trusted CA, The client only believes the server certificate if it is signed by a certificate authority it trusts. Because CAs are trusted, their own Public Keys used to verify the signatures of issued Digital Certificates are widely published. 

So practically, during ssl handshake, what happens is instead of sending its own public key, the client sends the symmetric key (session key) encrypted by the public key of the server. Server decrypts it with its private key and it gets to know the symmetric key. Now the further communication happens with this symmetric key encryption and decryption.

Wednesday, August 22, 2018

RingCentral Phone provisioning is unsecure


Recently I provisioned a Cisco SPA-525G2 Desk Phone to my RingCentral Free Trial account, and found their provisioning process is totally not secure.

When I added an existing phone on account admin portal, it prompted me to input the IP address of my IP Desk Phone. I am curious how the flow works underneath, then I dig it out and find RingCentral uses http instead of https. It doesn't provide either server side certificate or client side certificate for mutual TLS authentication. This means the provisioning data packets are exposed to hackers, and also any device can get provisioned through their provisioning portal. I am very surprised of their design from security perspective.

Phone resync URL
http://10.100.61.87/admin/resync?http://service.ringcentral.com/op/?u=1953899020&ai=803497337020&sn=$SN&pn=$PN

Proxy to their provisioning portal using HTTP
http://service.ringcentral.com/op/?u=1953899020&ai=803497337020&sn=$SN&pn=$PN

Variables in the URL will be replaced by desk Phone with serial number and product model
http://service.ringcentral.com/op/?u=1953899020&ai=803497337020&sn=CCQ214808CZ&pn=SPA525G2

If you sniff the network, you can clearly see the request and response in clear text (including user ID, password, auth ID etc info in plain XML file), and you can use any User agent to do the provisioning acting as a Cisco IP Phone.

This design worries me about their security design. I am not sure if they design by purpose or design by mistake.

Thursday, August 16, 2018

Mutual TLS Authentication


Mutual authentication or two-way authentication refers to two parties authenticating each other at the same time. By default the TLS protocol only proves the identity of the server to the client using X.509 certificate and the authentication of the client to the server is left to the application layer. TLS also offers client-to-server authentication using client-side X.509 authentication.

When Mutual TLS authentication is in place, both client and server authenticate each other through the digital certificate so that both parties are assured of the others' identity. In this aspect, both client and server use 12 handshake messages to establish the encrypted channel prior to message exchanging.


Refer to https://www.codeproject.com/articles/326574/an-introduction-to-mutual-ssl-authentication

When set up Mutual TLS authentication, it involves creating your own Certification Authority, self-signing the server certificate and client certificate, then installs self-signed certificate on server and client. The detailed steps are as followings:

1. Generate CA certificate:
1.1. Generate CA key:
openssl genrsa -out ca.key 2048
1.2. Generate CA certificate request:
openssl req -new -key ca.key -out ca.csr -subj /C=US/ST=ABC/L=XYZ/O=Example/OU=Test/CN=Root/emailAddress=john.doe@example.com
1.3. Generate CA certificate:
openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.pem

2. Generate server certificate:
2.1. Generate server key:
openssl genrsa -out server.key 2048
2.2. Generate certificate request:
openssl req -new -key server.key -out server.csr -subj /C=US/ST=ABC/L=XYZ/O=Example/OU=Test/CN=test.cert.example.com/emailAddress=john.doe@exampl
e.com
2.3. Generate certificate:
openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out test.cert.example.com.pem -days
365

3. Generate client certificate:
3.1. Generate client key:
openssl genrsa -out client.key 2048
3.2. Generate certificate request:
openssl req -new -key client.key -out client.csr -subj /C=CN/ST=FJ/L=City/O="Company"/OU=Dept/CN=ClientID/emailAddress=support@company.com
3.3. Generate certificate:
openssl x509 -req -in client.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out client.pem -days 365

4. Combine cert and key:
cat client.pem client.key > client2.pem

Some client like Firefox, to install the client certificate, we’ll need a PKCS#12 file which stores both the certificate and the client’s private key.
openssl pkcs12 -export -clcerts -in client.pem -inkey client.key -out client2.p12

5. Configure server:
Apache:
TLSCACertificateFile ca.pem
TLSCertificateKeyFile server.key
TLSCertificateFile test.cert.example.com.pem
TLSVerifyClient demand

Nginx:
ssl_certificate test.cert.example.com.pem;
ssl_certificate_key server.key;
ssl_client_certificate ca.pem;
ssl_verify_client on;

6. Configure client (device or browser):
6.1 Add ca.pem as a trusted CA certificate on client side
6.2 Add client2.pem or client2.p12 as a client certificate and use it

https://blog.codeship.com/how-to-set-up-mutual-tls-authentication/ also gives step-by-step instructions to set up mutual authentication using openssl commands.

CA certificate
openssl genrsa -aes256 -out ca/ca.key 4096 chmod 400 ca/ca.key
openssl req -new -x509 -sha256 -days 730 -key ca/ca.key -out ca/ca.crt
chmod 444 ca/ca.crt
openssl x509 -noout -text -in ca/ca.crt

Server certificate
openssl genrsa -out server/client-ssl.bauland42.com.key 2048
chmod 400 server/client-ssl.bauland42.com.key
openssl req -new -key server/client-ssl.bauland42.com.key -sha256 -out server/client-ssl.bauland42.com.csr
openssl x509 -req -days 365 -sha256 -in server/client-ssl.bauland42.com.csr -CA ca/ca.crt -CAkey ca/ca.key -set_serial 1 -out server/client-ssl.bauland42.com.crt
chmod 444 server/client-ssl.bauland42.com.crt
openssl x509 -noout -text -in server/client-ssl.bauland42.com.crt
openssl verify -CAfile ca/ca.crt server/client-ssl.bauland42.com.crt

Client certificate
openssl genrsa -out client/heiko.key 2048
openssl req -new -key client/heiko.key -out client/heiko.csr
openssl x509 -req -days 365 -sha256 -in client/heiko.csr -CA ca/ca.crt -CAkey ca/ca.key -set_serial 2 -out client/heiko.crt
openssl pkcs12 -export -clcerts -in client/heiko.crt -inkey client/heiko.key -out client/heiko.p12

Nginx server config
ssl_certificate /etc/nginx/certs/server/client-ssl.bauland42.com.crt;
ssl_certificate_key /etc/nginx/certs/server/client-ssl.bauland42.com.key;
ssl_client_certificate /etc/nginx/certs/ca/ca.crt;
ssl_verify_client on;

Wednesday, August 8, 2018

SSL certificate types


Speaking of SSL certificate types, usually we have two dimensions to categorize.

From validation dimension, there are three types of SSL certificate available today:
  1. Extended Validation (EV SSL)
  2. Organization Validated (OV SSL) 
  3. Domain Validated (DV SSL)
From domain name dimension, there are also three types of SSL certificate available today:
  1. Single-name (valid for only single domain)
  2. wildcard (valid for all subdomains)
  3. multi-name (valid for multiple domains/subdomains, called SAN or UC certificate)
You can have a wildcard cert *.domain.com which is valid for all subdomains.
You can have a single-name cert host.domain.com which is only valid for this host
You can have a multi-name cert host1.domain1.com, host2.domain2.com, this is called a SAN (Subject Alternative Name) Certificate. They are often called "UC-Certificate" as well.

For example:

When Wildcard SSL certificate is issued for *.domain.com, you can secure your unlimited number of sub domains over the main domain.

sub1.domain.com
sub2.domain.com
sub3.domain.com
sub*.domain.com

If the Wildcard SSL certificate is issued on *.sub1.domain.com, in that case you can secure all second level subdomains which are listed under the sub1.domain.com

aaa.sub1.domain.com
bbb.sub1.domain.com
ccc.sub1.domain.com
***.sub1.domain.com

If you want to secure limited number of different domains and second level domains, then you can choose multi domain SSL that can secure up to 100 domain names with a single certificate.

domain.com
sub1.domain.com
aaa.sub2.domain.com
domain2.net
domain3.org

Underneath


You may be wondering what the technical difference is between these types. It all comes down to the Subject Alternative Name (SAN) field that is embedded in the certificate when it’s issued.
When a certificate only has one SAN field and it contains a reference to a single website, then it’s a single-domain certificate.
If that one SAN field contains an asterisk in the website name (e.g. *.domain.com) then it’s a wildcard certificate.
If the certificate has many SAN fields, then it’s a multi-domain certificate. Multi-domain certificates sometimes have 100 or more SAN fields (with performance penalty), and some or all of these fields may contain wildcards, creating a hybrid “multi-domain wildcard” certificate.

Reference

https://serverfault.com/questions/104160/wildcard-ssl-certificate-for-second-level-subdomain
https://www.digicert.com/subject-alternative-name.htm
https://serverfault.com/questions/391311/how-many-domains-can-be-bound-with-one-ssl-certificate

Wednesday, August 30, 2017

nginx proxy_pass 502 Bad gateway

I use proxy_pass to proxy local API requests to our dev servers, something like

proxy_pass https://dev-server.com/api

All of a sudden, it stops working with a "502 Bad Gateway" error in browser DevTool network. However I can access https://dev-server.com/api directly using web browser.

It is obvious that nginx upstream fails for some reason. I googled a lot, and most discussions are relating to nginx configuration. However, I didn't change anything to nginx configuration before it stops working. Something happened on api server side?

Yes, our api server turned off TLSv1.0 due to security concern. I checked my local nginx and openssl versions, and realized we have 2 options:
1. Upgrade openssl version
2. Rollback api server changes to allow TLSv1.0

$ /usr/local/nginx/sbin/nginx -v
nginx version: nginx/1.0.15

$ openssl version -a
OpenSSL 0.9.8zh 14 Jan 2016
built on: Jan 23 2017
platform: darwin64-x86_64-llvm
options:  bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) blowfish(idx)
compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS -DZLIB -mmacosx-version-min=10.6
OPENSSLDIR: "/System/Library/OpenSSL"

How to enable TLSv1.2 in Nignx?
https://askubuntu.com/questions/319192/how-to-enable-tls-1-2-in-nginx

ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA;
ssl_prefer_server_ciphers on;

Monday, October 31, 2011

SSL certificate in Java Keystore

Untrusted Certificate?
If you get the ssl certificate from trusted public CA like Verisign, Thawte, digicert, GeoTrust etc, JRE and browsers will recognize it. However for some non-popular CA or home-issued certificate (for in-house testing purpose), JRE will not trust it. For instance, DST Root CA X3 isn't trusted by Java/Android platform even though most browsers trust it.

How do I fix this? 
Import certificate to Java Keystore.
First, save the certificate (*.cer).
Second, use keytool to import the Root certificate into your cacerts keystore.

Import certificate
The cacerts file is located in your JRE install directory under "<JRE_HOME>/lib/security/cacerts". The command to import will be similar to: $ keytool -keystore /opt/jre/lib/security/cacerts -storepass changeit -import -trustcacerts -v -alias DSTRootCAX3 -file dstRootCAX3.cer

Trust this certificate? [no]:  yes
Certificate was added to keystore
[Storing /usr/java/jre/lib/security/cacerts]

After above step done, restart services (Java process).

Verify imported certificate in keystore
C:\Program Files\Java\jdk1.7.0_01\jre>bin\keytool -list -keystore .\lib\security
\cacerts -storepass changeit -v > newstore.out
C:\Program Files\Java\jdk1.7.0_01\jre>notepad newstore.out

Alias name: verisignclass1g2ca
Creation date: Mar 25, 2004
Entry type: trustedCertEntry

Owner: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Serial number: 4cc7eaaa983e71d39310f83d3a899192
Valid from: Sun May 17 17:00:00 PDT 1998 until: Tue Aug 01 16:59:59 PDT 2028
Certificate fingerprints:
     MD5:  DB:23:3D:F9:69:FA:4B:B9:95:80:44:73:5E:7D:41:83
     SHA1: 27:3E:E1:24:57:FD:C4:F9:0C:55:E8:2B:56:16:7F:62:F5:32:E5:47
     SHA256: 34:1D:E9:8B:13:92:AB:F7:F4:AB:90:A9:60:CF:25:D4:BD:6E:C6:5B:9A:51:CE:6E:D0:67:D0:0E:C7:CE:9B:7F
     Signature algorithm name: SHA1withRSA
     Version: 1


*******************************************
*******************************************

Use -rfc to get certificate
C:\Program Files\Java\jdk1.7.0_01\jre>bin\keytool -list -keystore .\lib\security
\cacerts -storepass changeit -rfc

Alias name: verisignclass1g2ca
Creation date: Mar 25, 2004
Entry type: trustedCertEntry

-----BEGIN CERTIFICATE-----
MIIDAjCCAmsCEEzH6qqYPnHTkxD4PTqJkZIwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMSBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2ln
biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMB4XDTk4MDUxODAwMDAwMFoXDTI4MDgwMTIzNTk1OVowgcExCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMSBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2ln
biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCq0Lq+Fi24g9TK0g+8djHKlNgd
k4xWArzZbxpvUjZudVYKVdPfQ4chEWWKfo+9Id5rMj8bhDSVBZ1BNeuS65bdqlk/AVNtmU/t5eIq
WpDBucSmFc/IReumXY6cPvBkJHalzasab7bYe1FhbqZ/h8jit+U03EGI6glAvnOSPWvndQIDAQAB
MA0GCSqGSIb3DQEBBQUAA4GBAKlPww3HZ74sy9mozS11534Vnjty637rXC0Jh9ZrbWB85a7FkCMM
XErQr7Fd88e2CtvgFZMN3QO8x3aKtd1Pw5sTdbgBwObJW2uluIncrKTdcu1OofdPvAbT6shkdHvC
lUGcZXNY8ZCaPGqxmMnEh7zPRW1F4m4iP/68DzFc6PLZ
-----END CERTIFICATE-----


*******************************************
*******************************************