What is Certificates?, why we use it ?
Main function of SSL certificates:
Assures the identity of the provider
A point-to-point encryption between the service and the client
When a service is secured by TLS/HTTPS and a client wants to consume to service, a handshake has to take place first, to set up the secure channel in which the exchanged information is encrypted, so people with bad intentions can not simply sniff the data from the network .
The handshake work in a quick overview:
IE(Browser)-àA browser request a secure page with https: -à SERVER
IE(Browser)ß the web server send its request with public key and certificate ß SERVER
IE(Browser)à The browser ensure that the certificate validation date is not expire , revoked and issued by a trusted party .the common name will match the web site name ß- SERVER
IE(Browser)-à The browser create a symmetric key and send it to the server -à SERVER
IE(Browser)à The server decrypt the symmetric key by its private key ß SERVER
IE(Browser)ß the server send the page encrypted with symmetric key ß SERVER
IE(Browser)-à The browser decrypt the page using symmetric key and display the information -à SERVER
Note:
A certificate contains a public and a private key
The browser ensures that the certificates is unexpired, unrevoked, issued by a trusted party and that its common name matches the website that it is connecting to
The private key is used to decrypt the symmetric key created by the client, which was encrypted by the certificate’s public key.
When the client requests a secure conversation with the server, the server returns its certificate and its public key. The client generates a symmetric key and encrypts this symmetric key with the certificate’s public key and passes this encrypted symmetric key to the web server. This encrypted symmetric key can only be decrypted by the private key of that certificate, and the private key is never being traded, it always remains on the server. The private key is highly confidential and the web server is the only one having the private key. As the symmetric key encrypted with the exchanged public key is only decrypt able with the private key, the server is the only instance able to decrypt this encrypted symmetric key and get the same symmetric key as the client has. If someone would have been sniffing the handshake, he would only get a symmetric key, which he cannot decrypt because he does not have the private key … As only the server can get the symmetric key by decryption, we are setting up a secure channel. Both the client and the server will have an identical symmetric key, which nobody else can have if the private key is safe, and all communication can from this point on be encrypted with the symmetric key, which both sides have and which people with bad intentions do not have. One of the issues which might arise when using transport security is that the web server does not have enough rights on the private key. At some point, the web server will get an encrypted symmetric key which it has to decrypt with its private key. If the web server does not have enough rights to this private key, it will fail to decrypt the encrypted symmetric key and the handshake will fail, resulting in an error.
If this issue would occur, you can solve this by managing the Private keys of your certificate that you use for the transport security as following:
From start -àrun -àmmc
Console1 window will open then go to -àFile-àadd/Remove snap-in
A add or remove snap-ins window is open, in available snap-ins pane click on certificate then click add then certificate snap-in window is open then click Local computer click finish. Then certificate will add with in selected snap-ins console root.
If your application pool under which your IIS application runs is for example “Network Service”, then you would have to add Network Service to the users that have access to this private key and make sure it has read rights to the private key, so that it can retrieve the key from the local machine to decrypt the encrypted symmetric key.
As also mentioned in the things to notice, the common name of the certificate has to match the domain name of the website it is connecting to. In our case our domain is ‘CompanyXYZ server’ as we are running it in IIS locally. If our website would be hosted on a domain http://www.XYZ.com, our certificate subject would be “www.XYZ.com”.
There are 2 ways to get a certificate. One is creating a self-signed certificate and the second is to buy a certificate which is issued by a trusted certificate authority, like VeriSign.
Self-signed certificates are only good for development purposes. Thus once you want to go into production with your application, you will need to get a certificate from a verified certificate authority. These authorities will issue the certificate for you and the subject of the certificate will be your website domain name. This way the certificate will also guarantee the identity of the website to the client by the SSL certificate, as these authorities will not issue multiple certificates for one and the same domain.
These certificates are issued by authorities, like VeriSign, Thawte, GoDaddy and a few others. These are “recognized” certificate authorities. If you want to have a valid certificate which can be trusted by clients, your certificate will have to come from one of these recognized certificate authorities. These recognized certificate authorities is what we call a “trusted root certification authority“, a global trusted authority that issues SSL certificates for secure communication.
You can find these trusted root certification authorities in your certificates MMC:
Under console root-àcertificate (Local computer)
àPersonal
à trusted root certification authority
Main function of SSL certificates:
Assures the identity of the provider
A point-to-point encryption between the service and the client
When a service is secured by TLS/HTTPS and a client wants to consume to service, a handshake has to take place first, to set up the secure channel in which the exchanged information is encrypted, so people with bad intentions can not simply sniff the data from the network .
The handshake work in a quick overview:
IE(Browser)-àA browser request a secure page with https: -à SERVER
IE(Browser)ß the web server send its request with public key and certificate ß SERVER
IE(Browser)à The browser ensure that the certificate validation date is not expire , revoked and issued by a trusted party .the common name will match the web site name ß- SERVER
IE(Browser)-à The browser create a symmetric key and send it to the server -à SERVER
IE(Browser)à The server decrypt the symmetric key by its private key ß SERVER
IE(Browser)ß the server send the page encrypted with symmetric key ß SERVER
IE(Browser)-à The browser decrypt the page using symmetric key and display the information -à SERVER
Note:
A certificate contains a public and a private key
The browser ensures that the certificates is unexpired, unrevoked, issued by a trusted party and that its common name matches the website that it is connecting to
The private key is used to decrypt the symmetric key created by the client, which was encrypted by the certificate’s public key.
When the client requests a secure conversation with the server, the server returns its certificate and its public key. The client generates a symmetric key and encrypts this symmetric key with the certificate’s public key and passes this encrypted symmetric key to the web server. This encrypted symmetric key can only be decrypted by the private key of that certificate, and the private key is never being traded, it always remains on the server. The private key is highly confidential and the web server is the only one having the private key. As the symmetric key encrypted with the exchanged public key is only decrypt able with the private key, the server is the only instance able to decrypt this encrypted symmetric key and get the same symmetric key as the client has. If someone would have been sniffing the handshake, he would only get a symmetric key, which he cannot decrypt because he does not have the private key … As only the server can get the symmetric key by decryption, we are setting up a secure channel. Both the client and the server will have an identical symmetric key, which nobody else can have if the private key is safe, and all communication can from this point on be encrypted with the symmetric key, which both sides have and which people with bad intentions do not have. One of the issues which might arise when using transport security is that the web server does not have enough rights on the private key. At some point, the web server will get an encrypted symmetric key which it has to decrypt with its private key. If the web server does not have enough rights to this private key, it will fail to decrypt the encrypted symmetric key and the handshake will fail, resulting in an error.
If this issue would occur, you can solve this by managing the Private keys of your certificate that you use for the transport security as following:
From start -àrun -àmmc
Console1 window will open then go to -àFile-àadd/Remove snap-in
A add or remove snap-ins window is open, in available snap-ins pane click on certificate then click add then certificate snap-in window is open then click Local computer click finish. Then certificate will add with in selected snap-ins console root.
If your application pool under which your IIS application runs is for example “Network Service”, then you would have to add Network Service to the users that have access to this private key and make sure it has read rights to the private key, so that it can retrieve the key from the local machine to decrypt the encrypted symmetric key.
As also mentioned in the things to notice, the common name of the certificate has to match the domain name of the website it is connecting to. In our case our domain is ‘CompanyXYZ server’ as we are running it in IIS locally. If our website would be hosted on a domain http://www.XYZ.com, our certificate subject would be “www.XYZ.com”.
There are 2 ways to get a certificate. One is creating a self-signed certificate and the second is to buy a certificate which is issued by a trusted certificate authority, like VeriSign.
Self-signed certificates are only good for development purposes. Thus once you want to go into production with your application, you will need to get a certificate from a verified certificate authority. These authorities will issue the certificate for you and the subject of the certificate will be your website domain name. This way the certificate will also guarantee the identity of the website to the client by the SSL certificate, as these authorities will not issue multiple certificates for one and the same domain.
These certificates are issued by authorities, like VeriSign, Thawte, GoDaddy and a few others. These are “recognized” certificate authorities. If you want to have a valid certificate which can be trusted by clients, your certificate will have to come from one of these recognized certificate authorities. These recognized certificate authorities is what we call a “trusted root certification authority“, a global trusted authority that issues SSL certificates for secure communication.
You can find these trusted root certification authorities in your certificates MMC:
Under console root-àcertificate (Local computer)
àPersonal
à trusted root certification authority
