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.

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

Server Name Indication (SNI)

SNI (Server Name Indication) is an extension for SSL/TLS protocol. This extension allows the client to recognize the connecting hostname during the handshake process.  SNI permits a server to use different SSL certificates over the same IP address. Therefore, it serves correct certificates for those websites and delivers secured site to the customer. Each certificate is bind with particular FQDN, and with the help of SNI, the server picks the right certificate for the particular domain name.

A more generic solution for running several HTTPS servers on a single IP address is TLS Server Name Indication extension (SNI, RFC 6066), which allows a browser to pass a requested server name during the SSL handshake and, therefore, the server will know which certificate it should use for the connection. SNI is currently supported by most modern browsers, though may not be used by some old or special clients.

During ssl handshake "Client Hello" packet, you should see "Extension: server_name".

Latest Nignx server supports SNI. If you type: nginx -V
You should see: TLS SNI support enabled

https://www.ssl2buy.com/wiki/server-name-indication-sni-use-multiple-ssl-on-a-single-ip
http://nginx.org/en/docs/http/configuring_https_servers.html#single_http_https_server