Category
Internet – Blog No 3
Time to Read
30 Minutes
Who should read this blog?
SSL Certificate check

Preface

While choosing the topic of SSL certificates and to explian chain of trust, the word that came to my mind was Bicholiya.

I am sure you all might have watched a top-rated Netflix show – Indian Matchmaking if you haven’t, I would highly recommend you watch it, at least to understand the chain of trust. So, in this show, our main character Seema Taparia is a Bicholiya.

Bicholiya is a traditional practice followed in India. It involves a unique method of matchmaking where people, known as Bicholia, are responsible for finding suitable matches for unmarried individuals in the community. The Bicholiyas employ various methods to gather information about prospective matches, including visiting neighboring villages, attending social gatherings, and relying on their network of contacts. They collect details about the individual’s family background, personal characteristics, and reputation within the community. It is seen as a reliable and trusted method of matchmaking within specific communities. In a nutshell, Bicholiyas provides a common trust authority on which the bride and groom take such an important decision of marriage. Metaphorically if we encounter bicholiyas in every sphere of life, Last time, did you think twice before entering your user credentials on your bank website, why? because you trusted the website because of a Lock sign visible preceding https, followed by website URL in the browser’s address field. Today we will talk about SSL certificates and how Bicholiyas plays a role here too.

---

Chain of Trust

We will understand how the chain of trust works with the example again of our bicholiya, bride, and groom. Let’s name our bride Simran and groom Raj and Our Bicholiya is world famous Seema Taparia.

Scenario 1

First, let’s understand how trust works between two people. In our example, we will consider that Simran and Raj are from the same village/town or they had a long association before deciding to marry. In this case, both of them know each other very well so there is no third person required to confirm the trust.

This scenario can be compared to the scenario where you are accessing your intranet website data, and you trust this website as it is hosted in your network. you may access your website simply on HTTP or even if you want secured communication with HTTPS, you may use self-signed certificates. No role for Seema Taparia here.

Scenario 2

However, let’s consider a case where Raj and Simran are not from the same place, and no possibility of them knowing each other at all. This is mostly the case in Indian arranged marriages.

Let’s see how things unfold –

Simran receives an email from Raj, whom she has never met before, but who is the referral of our Bicholiya Seema Taparia, Simran herself has met Seema and put forward all her details and requirements well in advance so does Raj, so when Simran receives a message from Raj, she understands the basic compatibility requirements have already taken care of by Seema and vice versa for Raj too.

On this trust, Simran and Raj start meeting and sharing some private data with each other.

This is essentially the Chain of Trust.

Now Humans are not websites, even after basic trust is established there are many factors that are at play for both of them to decide if they are going to marry each other or not. For all that drama, you may watch the show.

Concepts become oversimplified when we understand them from real-world examples.

Since the basic concept is understood let’s understand how machines achieve this chain of trust.

When the client and server are on the same network

In scenario 1, I explained the scenario of Raj and Simran knowing each other as both are from the same village. Since they develop an interest in each other and want to develop this relationship more intimate. Of course, they want their communication to be a private affair(HTTPS) and they don’t want the entire village to know about the status of their relationship. So, they share their own code word with each other for example- Simran may share “The cow is hungry” which means it is a safe time to meet and share a good time at her place. She conveys this message to Raj through the public, but for the public, this simply means her cow is indeed hungry. lol. Same way Raj may share his own code word like “Time to Harvest” which means his place is available to have a good time.

	Public Key	Private Key
Raj	“Time to Harvest”	Raj’s place is available
Simran	“The cow is hungry”	Simran’s Place is available

In the same way, the Client and Web server will generate their own pair of private/public keys. they share their public key with each other over the internet while keeping the private key safe with them.

Note

private key can never be compromised or shared.

Client and Servers encrypt any communication with their respective public keys and decrypt the communication using their own private keys. This is just like a lock that has 2 different keys. Once it is locked with one key, it can only be unlocked with another key. This process is called Asymmetric key exchange which is covered in my previous blog.

This is how the process goes –

• Both client and server generate their own public and private keys.
• Both hide their private keys
• The server shares its public key with the client and the client shares its public key with the server.
• The server generates a new message and signs it with its private key.
• The client uses the public key shared by the server earlier to verify the message signature and read the message.

Let’s complicate this process now.

---

When the client and server are on the Internet

In Scenario 2, we discussed Raj and Simran are not from the same place and no possibility of them knowing each other at all, but both of them know Seema Taparia and have exchanged their details with her. Now the chain of trust plays an important role here. We are going to explain the different players in this chain of trust, let’s start.

Trusted Root CA

Simran receives an email from Raj, whom she has never met before, but who is the referral of our Bicholiya Seema Taparia. In this email, he has attached his details along with the recommendation certificate from Seema Taparia. The recommendation certificate has an authorized signature and a seal of trust in the name of Seema Taparia.

Simran is able to verify that Raj’s profile is indeed signed by Seema and because she trusts Seema’s credentials to verify Raj, she trusts Raj and shares her public key with him. Kindly note in this exchange no party exchange their private key with each other.

Our story is in the building phase and In our story we have brought a new character Seema. Let’s introduce that character in our web communication world. We can call him Certificate Authority(CA).

Seema has established herself as a world-renowned Bicholiya already and everyone trusts her credentials, Similarly, there might be many renowned Bicholiya like her who are well known, of course, she became famous worldwide due to the Netflix show.

In the same way, our CA’s are well-known trust authorities recognized by internet bodies.

Some famous names of CA’s are – Verisign, Let’s Encrypt, DigiCert, Comodo, GlobalSign, GoDaddy, Symantec, Sectigo (formerly Comodo CA), Entrust, and Amazon Trust Services, and many more.

Since they are well-known CA’s their public certificates should be known to all the machines and that is the reason their public key certificates are shipped on all the machine’s certificate stores and hence trusted by all the browsers.

You can open the Certificate Manager in Windows by pressing the Windows key + R to bring up the Run command, type certmgr.msc and press Enter. 

Note the CA certificate available on my Laptop cert-manager.

Since they are well-known CA’s we call them Root CA or Trusted Root Certificate Authority.

In the above snapshot, you can notice terms like Issued to and Issued by and as you will notice they are the same name because they are root CA. Seema Taparia advertises herself as the well-known Bicholiya, she has earned it over the years, similarly, our root CA advertises itself as Trusted Root CA’s. We will more discussion about Issued to and issued by in our next paragraph.

Intermediate CA

Seema Taparia might be world famous but she can not single-handedly handle so many clients worldwide. She needs delegation of work where she remains the root authority but she delegates her work to the intermediate Bicholiyas who approaches her clients in her name, so an intermediate Bicholiya may take a license from her to serve a specific region, that way she expands her chain of trust.

In the same way, we have intermediate CA’s who are issued a license to operate in the name of Root CA

Refer to the Intermediate Certificate in the certificate manager on my laptop.

As you can notice we have Issued To and Issued By columns where Issued To is the Intermediate CA and Issued By is the Trusted Root CA.

So Raj and Simran might not have approached Seema Taparia directly instead two different intermediate Bicholiya deputed to their region.

In this case, when Raj sends an email to Simran which sends his details he will also send the recommendation certificate from Intermediate Bicholiya. The recommendation certificate has an authorized signature and a seal of trust in the name of Seema Taparia. Hence Simran now trusts Raj, Intermediate Bicholiya, and of course, she trusts Seema Taparia.

Note

in most cases you will see both the root and intermediate certificate for a website but there would be cases where you would see only the Root certificate as CA, As the certificate was signed by Root CA and no intermediate CA was involved in the process.

Leaf Certificate

To get registered with either intermediate bicholiya or directly with Seema Taparia, Raj and Simran have to give all their personal details along with their proof document to prove their identity, their education, and their financial background. So they have to fill out a registration form with their details and attach their proof documents along with the form. Once all the details are correctly verified, the Intermediate bicholiya or Root Seema herself signs their registration letter with their personal signature and stamps the registration form with their private seal.

Raj and Simran then can use their signed registration forms to get authenticated as valid brides and grooms.

Similarly, the website owner/admin who wants to SSL secure their websites and make their websites trusted over the internet has to get their certificate signed with either the intermediate CA or Root CA. This process is called a Certificate Signing Request (CSR) which we will cover in the next topic.

So as observed in the whole process, after we get the signed certificate, we would have 3 certificates with us the certificate of the bride/groom(website leaf certificate), the Intermediate bicholiya certificate ( Intermediate CA certificate), and the Seema Taparia’s certificate ( Trusted root Certificate).

Note:

If you want to use your website within your internal network boundaries(intranet), you don’t need to approach the public CA’s, rather you may install your internal public key infrastructure (PKI) solution provided by Microsoft Active Directory Certificate Services (AD CS). An open source alternative to Microsoft AD CS is OPENSSL toolkit. In this case the AD CS Server itself acts as a Internal certificate autority(CA) and signs the certificates for internal website domains.

Just like the Intermediate and Root CA, The leaf certificates are stored in Cert Manager but in the different Personal Certificate folder of the Cert Manager as shown in the below snapshot.

In most cases, the website’s leaf certificates are not present in the Personal Certificate folder on the client side as the website leaf certificate is dynamically presented by the website on the internet to the client when the client browser requests the webpage. On the client side, you will only notice the Intermediate CA and Trusted Root CA public certificates.

The reason is very simple there are millions of websites out there if clients have to install the leaf certificate of all the websites it would be a nightmare not only for the storage perspective but scalability perspective as every day there are thousands of new websites getting added on the internet.

However, the server hosting the website would contain a complete chain of the certificates including Leaf, Intermediate, and Trusted root within their respective folders as I have already shared the snapshot.

---

Certificate Signing Request

As explained above Raj and Simran have their personal details, private key, and public key with them but they have to fill in the details (except the private key remember) in some kind of registration form to get it validated and signed by the intermediate bicholiya or Seema.

Similarly, the website Owner/Administrator has website details that he is going to publish over the internet so he has to create a certificate Signing Request to get the certificate signed by CA by their private keys.

To get a signed certificate, A Website Admin must create a CSR on his server. This process creates a private key and a public key on his server.

Note

The CSR data file that you send to the CA contains the public key. The CA uses the CSR data to create a data structure to match your private key without compromising the key itself. The CA never sees the private key.

There are multiple ways to create a CSR, like using the open-source OpenSSL utility, or Windows ADCS Server, or through the Certificate Authority providers directly.

To create CSR through the Certificate Authority , we can go to their websites and follow the process

Refer this link for creating CSR through Digicert CA.

https://www.digicert.com/kb/util/csr-creation-microsoft-servers-using-digicert-utility.htm

Let’s see how to do it through the OpenSSL utility manually –

• Install OpenSSL: If you don’t have OpenSSL installed on your system, you can download and install it from the official OpenSSL website (https://www.openssl.org/).
• Generate a Private Key: Before creating a CSR, you need to generate a private key. Run the following command to generate a new private key and follow the steps

openssl genpkey -algorithm RSA -out private.key -aes256
...+.....+.........+......+.......+......+......+..................+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*..+..+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.........+........+.......+...........+....+...+...+.....+...............+....+........+.+..+...+....+...............+...........+.+......+..............+.+........+.....................+.+..+.+..+.......+..+.............+........+...+....+..+..........+.....+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.+......+.....+.+.....+...+..........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.........+..+...+....+......+..............+.............+..+...+.+..+...+....+.....+......+.+......+..+.+.....+.......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.....+.....+.+......+........+......+....+.....+.........+.+...........+......+....+......+...+......+.........+.....+..........+.........+........+....+...+.................+...+..........+...............+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Enter PEM pass phrase:sslcertp@ss123
Verifying - Enter PEM pass phrase:sslcertp@ss123
Note - This pass phrase will encrypt your generated private key for extra layer of security. so always remember your paas phrase , better store it on some keyvault, if someone learns the pass phrase and get hold of your private key they may know the private key of the certificate and decrypt the communication.

The Private key is Generated with name private.key and can be opned in Notepad, this is how it looks-

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIGLTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQIQWV1S5UuKEcCAggA
MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAEqBBD12FU1z8fpHOv3LrEie7noBIIE
0B420ILe8ZsaQjN3G0RgDj4Al+aRgNWJP42tFuOZPHLW84u4c11QGEVnTudwRsH6
RLELacqRkS+4MNzbYB9hUp7b683qtHxmJR2RHMvFIXB4C3vCaIf3TukeyRUDHQX2
8ljflrMrl/9bts3sRfjesQMIzAPFen868uAiQRWoJzg+1NIxp4yOy0VgrQiIe/kU
PQJBZGEODunIKmHkIxAHkbHSCuhS5Bi+H8AjkL3ndkiW7ESATlnxf90v33DeV4hP
gAkLLsRabCEnzyRyov0yRbJty3z7Th1q3F0sewJF0wkaWQWJ0rtUocwpmhEr5JDF
3BNCCmXXScTt5OmeZYrBJqLJ4FmrOnOvanzNHHGOeLAEGpb1mjpJtupSrV0WMKDy
kW7ldrewCsD2r9CdGQqxs0umPYexc8vst9ft8ilIZvYwvRbt1DKME0E7d2cK4bUN
DECpL8S0wgWzPaYv5Do/JQuvus4/quGv+0Q1SYL1GZDpq4KOjA1SJZlrbjjnA+1R
80zZ57+6jLxebea9txFBntSmwSIDQY6BWBed5Makts59eGKLVCc1k4IKiA+ivhV5
rwXIEZnqOtx9aIvpF6eQP3HUGgHegCvNHBxPFXNdSHiZEclzqaipGeVZexolk0Sk
pnjawfYrUtt+i49fQ8+c5vYdOKu7AcBKvYJOfNP2drup7/7nLY0hbM6l53ZiqV+d
bN3ZePNRyCnZP3Z9Q83jM8kXQ2TIi74M7vyfH2oCfbgz1V2yJjLIVY5/5dQPtotA
aITqInG6HJkZEwACzz/c6/ecTl8v4vSFLA3xmU8Q6hbMMSgcuJC/o8jerZ4+QH+r
/RqAlZ69AeDSKxq/BR/UGnjIgVlrAouvIPdBl9rM65Y7GRoasVJ2YMTlriAB0SPz
/BGPIrz3Y+XPRGnZ9hkEOI8hR+VVNIcCSZ9r5gTTAD7MvlOONziRbWgyPzXgC5lZ
jyyTVXktcdxqcoBCLuEH1Z3nZIxn24U1OcAkNyobWYG6Wp00Qr8D1WLFb0KemC4l
wP7s7IkiyZuNZJ4JBclHtwyhtpZpGtUwMh/gs2XM0HDjlSBHcOycTv/7DH4K/AYM
TjhMtDGQmaSbYbufngkCR6TuhM4Q3Y8+zWqJn83jcQLOaLt8peXka5tOKwe7W7yV
zzMRXoNL1NeKr2TNSKBRvez65JymqrNDTbnl5zuR1PqPpN75CwuUjZw0FzE96fH0
B+NcJ+qllo4bx3b8lsq8nyzyo9l/ZtNgfztQmOUqhI0Y/+nn+xtO5/VILYPXjazL
3EQH/9ynx2aPLgMh71Odcn6n1ZFuzqVdyoO8EypfX4ixfJgPQD4flMh8Yg9Lfpoh
WHGZad5DsXlVpXf8PRDB1kSzD640Bi2kPoyNohFqdb1qzzH/4vyMQM8P/1Ed5sOw
39dCvXeOgWwP9GPnbXpDbMJCEDnbjnsMlOz7zd3FzRV4jF6xe2eO/irDvcL6J/to
w7hSmaUBVj7+6c+xiQpePqTVaXtyty6a6FXJhF1JS48P+joeDGBuGyj1zeM/ZuGA
DHmkrNl00D86yxMpRpiXKay0AZxVWaCPH2nmYHNiQnZMOkOo9eok0L4TSOyH5SJc
fSesE/ZsIZzaDm5DiR/iRIvHs/GDzVBb5S9ql8iKLuvA
-----END ENCRYPTED PRIVATE KEY-----

• Create a CSR: Once you have the private key, you can use it to create a CSR. This is just like Raj/Simran giving their personal details, Run the following command:

Generate the CSR with the generate private key in above command
openssl req -new -key private.key -out csr.csr

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]:IN
State or Province Name (full name) [Some-State]:Telangana
Locality Name (eg, city) []:Hyderabad
Organization Name (eg, company) [Internet Widgits Pty Ltd]:thecloudblogger.com
Organizational Unit Name (eg, section) []:IT department
Common Name (e.g. server FQDN or YOUR name) []:*.thecloudblogger.com
Email Address []:mail.cloudblogger@gmail.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:abcd1234
An optional company name []:thecloudblogger

Note - The challenge password is intended to serve as a shared secret between the entity requesting the certificate (the applicant) and the Certificate Authority (CA) that will sign the certificate. When the CA receives the CSR, it may verify the applicant's identity by requesting the challenge password.This is optional step.
CSR File is generated and lets open in notepad :

-----BEGIN CERTIFICATE REQUEST-----
MIIDNjCCAh4CAQAwgbcxCzAJBgNVBAYTAklOMRIwEAYDVQQIDAlUZWxhbmdhbmEx
EjAQBgNVBAcMCUh5ZGVyYWJhZCEcMBoGA1UECgwTdGhlY2xvdWRibG9nZ2VyLmNv
bTEWMBQGA1UECwwNSVQgZGVwYXJ0bWVudDEeMBwGA1UEAwwVKi60aGVjbG91ZGJs
b2dnZXIuY29tMRowKAYJKoZIhvcNAQkBFhttYWlsLmNsb3VkYmxvZ2dlckBnbWFp
bC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGdyJfC1NA2yQe
n2YEXqYDn+oC7USJR7F+LVmNck+FVh3OReACChpo9Uz/2BiMWm4aYOfkqcLr3OA6
w5gPNjdGl9NtqHlG7PySChMEfAaF+YfOv7Hty5ydlIKzC9SQ9j3RBFYWxD4vfjBL
CskkCHs210ZFu0ncQ3pljd7+Beg9UjBc8s0MLVrdgQxB4aWjRiVI4xEj9VlHiqGp
ecOEM/LVMEyOAYOMuf3VCXvexqA0SHIiF+FIasYr2/3eK9nKTCTnnqfIIDwcjgYd
jqEq3Z+FyUkdCvL8Za8JnXRQXYMAx+3bn25/hA3YU3BEM5V1AuDjImiaX78R359D
Uz8S9mzLAgMBAAGgOTAXBgkqhkiG9w0BCQcxCgwIYWJjZDEyMzQwHgYJKoZIhvcN
AQkCMREMD3RoZWNsb3VkYmxvZ2dlcjANDgkqhkiG9w0BAQsFAAOCAQEAq6LUtGzu
z0sy0eEY5U0Su7qs1pW0WlgOnc+q9eu3U4I1RRCFurKB5PqU0JNBxM5FL3qaN5uZ
bLtfJ1dYwtMEyAyQIJAtoSw35cfxiHLLx+Frmp8ftULWabPTTMVFG3QNah6L0CZv
uRDiP/HiPlfnLfnTLswHH29Kz5IeqbX5WUu1sdyvyAWH82bnB9UCYROwPDg0cPw/
pPe2zZ/Eqz8b2oRYyDkalBCzZTrNiIX7Se8zZBHXUBpCyFCLGPgUDVP3rzlJfUqO
SWPi904GILFF3G6JyA9a9jsdo7PudDOuEdArYOybOdnqckRSpwjcAAnbhI3rImti
HQ5sPY1mktK7lQ==
-----END CERTIFICATE REQUEST-----

• If you have noticed in the Common Name Field – I have mentioned *.thecloudblogger.com, the reason is tomorrow if my website expands and may have many sub-websites like sales.thecloudblogger.com or hr.thecloudblogger.com so I don’t have to create a separate certificate for each website, *.thecloudblogger.com will cover for all the websites.
• This could also be achieved using SAN (Subject Alternative Filed), so if in your common name, you just enter thecloudblogger.com. Under SAN Field you may enter other valid website names with you want to use this certificate.
  • Create a configuration file (e.g., san.cnf) with the following content:
  • In this example, sales.thecloudblogger.com, www.cloudblogger.com, and 192.168.0.1 are specified as SAN entries. You can add or remove entries based on your requirements. In this case, my certificate can be used for sales.thecloudblogger.com, www.cloudblogger.com, and 192.168.0.1 hostnames too.

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = sales.thecloudblogger.com
DNS.2 = www.cloudblogger.com
IP.1 = 192.168.0.1

Generate the CSR using the configuration file:
openssl req -new -key private.key -out csr.csr -config san.cnf

• Submit the CSR to a trusted Certificate Authority (CA) for signing and issuance of the SSL certificate.
• CA will validate the details provided in CSR and will issue a certificate that can be downloaded in CRT/CER/PEM/PKCS7 formats. Refer to the Digicert page for more details on how they validate the certificate.

---

Contents of downloaded certificate

I have downloaded my signed thecloudblogger website certificate in CRT format and this is how it looks

Certification path tab

Let’s peek inside the certificate, Lets zoom into Certification Path tab and it shows complete chain of the certificate, if you see any component missing try to download again and make sure you have complete chain made of Leaf, Intermediate CA and Root CA.

General tab

General and Details tab shows the details of the selected certificate in the certification path tab, by default these tabs show the details of the Leaf certificate.

General shows the certificate was issue to Common Name (Subject) thecloudblogger.com, shows the validity of the certificate and who issued the certificate, in my case intermediate CA R3.

I have downloaded this certificate from the CA website but if i want to install this certificate on my local laptop, i can click on the button Install Certificate and this will install all 3 certificates viz Leaf Certificate in Personal certificate folder, Intermediate CA certificate in my Intermediate certificate authority’s folder and Root Certificate in my Trusted root certificates folder of my Cert Manager.

Details tab

Details tab shows the actual content of the selected certificate. As we can see the issuer details (Issued By) ,Validity of the certificate, subject name (Issued to), Public key , Subject Alternative Name (SAN) and Thumbprint. Thumbprint as the name suggest is unique to each certificate and can be used to identify a certificate just like fingerprints are used to identify a person. Thumbprint of Leaf , Intermedite CA and Root CA certificate would be unique. Kindly note the certificate does not contain the private key.

Similarly, To check the details of the Intermediate CA certificate R3, go to the Certification path tab and click on view certificate.

If you notice, for Intermediate CA Issuer(Issued by ), Subject(Issued to) fields are changed.

To see the details of the Root certificate, go to the Certification path, select Root certificate and click on view certificate button.

If you notice, for Root CA Issuer(Issued by ), Subject(Issued to) fields are changed and they have same value as ISG Root X1. This shows that Root CA is the epic body and there is no one above them. This is how you can identify if a given certificate is a Root certificate or not.

---

Install the certificate on the Web Server

We have downloaded the complete chain of the certificate for our website thecloudblogger.com. Now this certificate has to be installed on web server hosting our website.

As i have already mentioned that this certificate (CRT format) does not contain the private key, which i used to create the leaf certificate CSR. As you remember i advised to save the private key at a safe place earlier, now we will use that private key to convert the certificate format to PFX(PKCS #12) format.

We can do that by Openssl tool by using this command –

openssl pkcs12 –export –out thecloudblogger.pfx –inkey private.key –in thecloudblogger.crt

Our PFX certificate is ready and contains the complete chain of the certificate along with private key.

Once the PFX certificate is installed on the web server , the server is ready to secure the website using SSL.

On the client side, who will access this website, will have preinstalled Intermediate and Root CA certificates with public keys to identify the Leaf certificate signed by CA’s private keys presented by the Server. In my Blog How HTTPS works i have explained how the entire HTTPS communication process works.

---