As you move your traditional desktop based applications to the cloud, you naturally begin worrying about security.
Typically, you want to make sure that no unauthorized person or entity gains access to your cloud based applications. There are several things you can do to build robust security around your cloud based applications. One important step is to make your web services secure by using SSL (Secure Socket Layer).
SSL is a method of encrypting the communication between a client application (like a desktop application, mobile application or a web browser) and the web server application running somewhere on the cloud. You might recognize this as the HTTPS URLs that you see from time to time. HTTPS URLs are secure web sites and services that use SSL.
Given that there are many server technologies like ASP .NET, Apache and Java based services, there are several ways to implement SSL security into your web-service.
Over the next several posts, I will talk about various technology components that go into implementing an SSL based web service. In this post I will talk about certificates.
For SSL to work, a verifiable trusted certificate is the key. A certificate provides information on who this certificate belongs to among other things. But this is not enough. You need to be able to trust that certificate. If I tell you that a digital certificate I send to you is trust worthy, you might choose to believe me or not (depending on how well you know me). Given that there are millions of websites, you will not know everyone and it would be impossible to verify each individual certificate before using their websites or services.
To solve this problem, we have Certificate Authorities (CA). If I am a web service provider and you are a client who intends to use my service, we do not need to explicitly know each other to trust each other. If both of us trust a Certificate Authority, than we implicitly trust each other (at least, that is how the system works on the internet now). So when a certificate Authority issues a certificate to a web service vendor, the client which uses that vendor service requests for the vendor certificate and once it is obtained, the client verifies if it is issued by a certificate authority.
This verification is performed by validating the vendor certificate against a certificate belonging to the Certificate Authority itself. This certificate (of the Certificate Authority) is called the Root Certificate. When you install a web browser on your computer, the root certificates of the most popular certificates are automatically installed in a secure location on your machine. You will find information on popular Certificate Authorities by just googling for them.
Now, does this mean you need a certificate from a Certificate Authority (Most of the CAs charge money for issuing certificates) to start building SSL based web services? Not necessarily. You can create certificates for yourself (both root and regular) using the free microsoft windows command-line tool makecert. Since you know yourself ( you do know yourself don’t you?) you can trust your root certificate and any certificate issued with that root certificate (unless you do not trust yourself, which could happen some times). Here are a couple of web articles (first, second) that show how to use makecert to create root and regular certificates.
That is it for now. In my next blog post, I will talk about using these certificates and configuring a WCF Web service to implement SSL.