What is SSL Certificate

To start with some historical knowledge. Netscape in 1994 developed the first version of the SSL protocol, which was released in successive versions over the next few years. At some point the name changed from SSL to TLS, and formally subsequent versions of certificates are known by this name. By convention, however, it has become accepted that when talking about TLS certificates, we call them SSL certificates.

Above we mentioned the TLS (formerly SSL) protocol and the SSL certificate. What are the differences between the two? Let's start with the TLS protocol. Since in the ISO/OSI model it works at the presentation layer, it is possible to secure a higher layer - the application - with it. Now, each layer in the ISO/OSI model contains mechanisms to provide security. The following table shows examples of protocols in the following layers of the ISO/OSI model.

ISO/OSI Layer	Example Protocols
Application	HTTP, FTP, SSH, DNS, DHCP
Presentation	MIME , XDR , SSL , TLS
Session	NetBIOS , SAP
Transport	TCP , UDP
Network	IP (IPv4, IPv6) , IPX , ICMP , IGMP , IPsec
Data Link	ARP , LAPB
Physical	Ethernet, DSL

http://kawia.wex.pl/protokolyosi.html

The aforementioned "security" of the TLS protocol consists of:

• encrypting the data,
• ensuring the integrity of data transmission,
• confirmation of the server's identity,
• optional confirmation of the client's identity.

Now that we know what the TLS protocol is and what its task is, we are left with the SSL certificate. It will be easiest to understand it with an example of the use of the protocol itself.

Operation of the SSL protocol

The first SSL session, or handshake, can be demonstrated in several steps:

Client                                               Server
-----------------------------------------------------------
ClientHello                  -------->
                                                ServerHello
                                               Certificate*
                                         ServerKeyExchange*
                                        CertificateRequest*
                             <--------      ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished                     -------->
                                         [ChangeCipherSpec]
                             <--------             Finished
Application Data             <------->     Application Data

• Initially, the user sends an unsecured, clean ClientHello message to the server, which signifies the declaration of an SSL connection. In addition, it contains such information as:
  • server_version - the maximum possible version of the protocol,
  • (client) random - that is, 32 bytes (28 of which are to be generated with a strong number generator),
  • session_id - the identifier used to renew the handshake session in abbreviated version (abbreviated handshake),
  • cipher_suite - a list of cipher suites that the client knows. One set is a 16-bit identifier that defines a set of algorithms,
  • compression_method - list of data compression algorithms that the client knows ,
  • extensions - extensions (optional).
• The server responds with a ServerHello message, which stores:
  • server_version - the version of the protocol selected from those passed by the client,
  • (server) random - analogously and independently to (client) random,
  • session_id - the identifier for the current connection. If clientHello.session_id was not empty and was completed (e.g. from cache), the server checks it, and when it is found, it goes to Finished. We will return to this in a later step,
  • cipher_suite - the selected cipher suite,
  • compression_method - the selected compression algorithm,
  • extensions - extensions (optional).
• The server sends Certificate, which stores the public key,
• The server sends ServerKeyExchange, which is some additional information not necessary for key exchange, if those defined in the Certificate are non-existing,
• The server sends CertificateRequest, a request addressed to the client, asking it to identify itself with its own certificate. The message contains a list of "root certificates," the points with which certificate validation will be performed,
• The server sends ServerHelloDone, i.e. a zero-length message, thus informing the client that it is time for its response,
• The client responds with Certificate, if the server has stewarded it,
• The client replies ClientKeyExchange, i.e. a random value encrypted with the server's key,
• The client responds with CertificateVerify*. In the simplest terms, this is a digital signature created from previous messages, which is also a confirmation to the server that the client is using the public key from the certificate it encrypted,
• Both parties, first the client and then the server, send a ChangeCipherSpec, i.e. a message that is a confirmation to the recipient that subsequent records will already be encrypted using the previously indicated cipher and key sets.
• The Finished messages, which are sent immediately after ChangeCipherSpec, are the first encrypted cryptographic values, which at the same time include all previous messages. In this way, both parties are able to verify that they are talking to each other and that their messages have not been modified.

Once complete, the client and server are able to exchange encrypted data. As we mentioned the first one, this is the first handshake (handshake). For subsequent (abbreviated handshakes), the communication graph is as follows:

Client                                               Server
-----------------------------------------------------------
ClientHello                  -------->
                                                ServerHello
                                         [ChangeCipherSpec]
                             <--------             Finished
[ChangeCipherSpec]
Finished                     -------->
Application Data             <------->     Application Data

Let's go back to ServerHello.session_id for a moment. We mentioned that the server, at the moment of recognizing ClientHello.session_id, skips the whole process and immediately goes from Finished point. Such a session is remembered by the web server for up to a dozen hours.

*****Information sent optionally, depending on the min. cipher sets used.

Reading certificates in the console

To check the SSL certificate, we can use nmap or openssl tool. Knowing the specific address and port, we type the following command:

nmap -p 443 --script ssl-cert google.com

In response, we get a fair handful of information:

Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-19 01:48 CEST
Nmap scan report for google.com (172.217.16.46)
Host is up (0.023s latency).
Other addresses for google.com (not scanned): 2a00:1450:401b:804::200e
rDNS record for 172.217.16.46: muc03s08-in-f46.1e100.net

PORT    STATE SERVICE
443/tcp open  https
| ssl-cert: Subject: commonName=*.google.com/organizationName=Google LLC/stateOrProvinceName=California/countryName=US
| Subject Alternative Name: DNS:*.google.com, DNS:*.android.com, DNS:*.appengine.google.com, DNS:*.bdn.dev, DNS:*.cloud.google.com, DNS:*.crowdsource.google.com, DNS:*.datacompute.google.com, DNS:*.flash.android.com, DNS:*.g.co, DNS:*.gcp.gvt2.com, DNS:*.gcpcdn.gvt1.com, DNS:*.ggpht.cn, DNS:*.gkecnapps.cn, DNS:*.google-analytics.com, DNS:*.google.ca, DNS:*.google.cl, DNS:*.google.co.in, DNS:*.google.co.jp, DNS:*.google.co.uk, DNS:*.google.com.ar, DNS:*.google.com.au, DNS:*.google.com.br, DNS:*.google.com.co, DNS:*.google.com.mx, DNS:*.google.com.tr, DNS:*.google.com.vn, DNS:*.google.de, DNS:*.google.es, DNS:*.google.fr, DNS:*.google.hu, DNS:*.google.it, DNS:*.google.nl, DNS:*.google.pl, DNS:*.google.pt, DNS:*.googleadapis.com, DNS:*.googleapis.cn, DNS:*.googlecnapps.cn, DNS:*.googlecommerce.com, DNS:*.googledownloads.cn, DNS:*.googlevideo.com, DNS:*.gstatic.cn, DNS:*.gstatic.com, DNS:*.gstaticcnapps.cn, DNS:*.gvt1.com, DNS:*.gvt2.com, DNS:*.metric.gstatic.com, DNS:*.urchin.com, DNS:*.url.google.com, DNS:*.youtube-nocookie.com, DNS:*.youtube.com, DNS:*.youtubeeducation.com, DNS:*.youtubekids.com, DNS:*.yt.be, DNS:*.ytimg.com, DNS:android.clients.google.com, DNS:android.com, DNS:developer.android.google.cn, DNS:developers.android.google.cn, DNS:g.co, DNS:ggpht.cn, DNS:gkecnapps.cn, DNS:goo.gl, DNS:google-analytics.com, DNS:google.com, DNS:googlecnapps.cn, DNS:googlecommerce.com, DNS:googledownloads.cn, DNS:source.android.google.cn, DNS:urchin.com, DNS:www.goo.gl, DNS:youtu.be, DNS:youtube.com, DNS:youtubeeducation.com, DNS:youtubekids.com, DNS:yt.be
| Issuer: commonName=GTS CA 1O1/organizationName=Google Trust Services/countryName=US
| Public Key type: ec
| Public Key bits: 256
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2021-03-23T08:18:59
| Not valid after:  2021-06-15T08:18:58
| MD5:   b075 896c 843f 374e d237 4807 b992 09a7
|_SHA-1: 2f5c 43f2 d253 75f8 0aac 79a2 9087 2697 e98a c90a

Nmap done: 1 IP address (1 host up) scanned in 0.43 seconds

For detailed, slightly less readable information, we will use the command:

echo | openssl s_client -showcerts -servername google.com -connect google.com:443 2>/dev/null | openssl x509 -inform pem -noout -text

The structure of the certificate is described below, although we won't dwell on the structure itself further.

• Certificate
  • Version number
  • Serial number
  • Signature algorithm identifier
  • Name of the issuer
  • Validity period
  • Invalid before the date
  • Invalid after the date
  • Entity name
  • Information about the entity's public key
  • Algorithm of the public key
  • Entity's public key
  • Issuer identifier (optional)
  • Identifier of the entity (optional)
  • Extensions, additional information (optional)
• Algorithm signature certificate
• Signature certificate

Types of certificates

We can distinguish three types of certificates that differ in the level of verification of the party's identification. These include:

• DV (Domain Validation) - the most basic form of security, in which verification of domain ownership by the person redeeming the certificate occurs,
• OV (Organization Validation) - in order for the certificate to be issued, there is verification of ownership of the domain as well as the company that manages it,
• EV (Extended Validation) - detailed verification of both the entity and the domain ownership by the Certification Authority for the identity of the company.

Additional information

About past threats related to certificates and SSL/TLS communication, refer here.

Sources

https://tools.ietf.org/html/rfc5246
https://jchost.pl/blog/tls/
https://students.mimuw.edu.pl/SO/Projekt04-05/temat5-g6/Danka/ssl_my.html
https://pl.wikipedia.org/wiki/X.509
https://www.ssl.com/pl/FAQ/faq-co-to-jest-ssl/
https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work