Wednesday, March 21, 2012
Saturday, December 5, 2009
Creating and Installing Digital Certificates - in Production
Make sure you have thought it all out and have all the details before you start requesting and installing and using a certificate. Some of the things to think about:
1. Exact name of the server, including domain you want the certificate for should be known, e.g. http://www.sites.company.com/ is different from sites.company.com is different from www.company .com.
2. Decide which organisation you want the certificate for. Also make sure the ‘whois’ record contains your organisation as the owner of the domain you want certificate for; else you will need a domain authorization letter.
3. The kind of authentication you want:
a. Domain authentication: This refers to a type of certificate where the certificate issuing body doesn’t ask for too much details – just the fact ‘CompanyA’ owns ‘DomainA’ – e.g. the ‘whois’ record. These certificates are cheaper and are very very quick to obtain – all online, matter of an hour!
b. Full Organisation Authentication: As opposed to Domain only authentication, full organisation authentication goes a step further and in addition to confirming the fact ‘DomainA’ belongs to ‘CompanyA’, it also confirms ‘CompanyA’ is who it claims to be i.e. its ABN, ACN, other details confirming its identity.
4. Extended Validation: An EV certificate adds a Green colour to the address bar in addition to the padlock a standard certificate adds to a HTTPS request on the browser.
5. Certificate edition: SSL providers sometimes offer various editions of the certificates:
a. Basic: 48-bit certificates; suitable for older style browsers i.e. before IE5 era. All newer browsers should be able to support 128 bits.
b. Standard: forced 128-bit certificates, meaning the server forces the clients (the browsers) to send 128-bit requests.
c. Premium: Usually forced 128-bit certificates with Extended Validation.
6. Choose your CA: CA is the certification Authority; is it going to be Verisign (Big name and big dollars) or Digicert (good service, decent price) or something else.
7. SAN or Subject Alternative name: Subject Alternative Names let you protect multiple host names with a single SSL certificate. Subject Alternative Names allow you to specify a list of host names to be protected by a single SSL certificate. See below:
SAN also comes in 2 flavours:
a. Ability to secure ‘www.domainA.com’ and also ‘domainA.com with the same certificate.
b. The second flavour allows you to secure an extra sub-domain with the same certificate e.g. ‘www.domainA.com’ and ‘sites.domainA.com’.
B) Step by Step procedure to create a certificate:
1. Create a CSR [Certificate Signing Request]: A Certificate signing request refers to a digital request to a CA like VeriSign or Digicert which contains the company details, server/domain details of certificate being requested. Screenshots below show you how to create a CSR:
a. CSR Request data: Go to the Server Certificates under IIS, click on ‘Create Certificate Request’ and on ensuing pop-up (as below) fill in the details.
b. Select the Cryptographic algorithm, in this case Microsoft RSA. Also select the bit length of the certificate. 1024 bit and above is the standard these days, so you could leave the default selection (1024) or higher.
c. Finally, select the file destination and ‘Finish’ the wizard to create your CSR.
d. In case you are wondering, the CSR looks as below.
2. Then go to a CA or certificate issuer’s site like VeriSign or Digicert and buy the appropriate certificate you want. E.g. in the screenshot below for Digicert, simply follow the steps (as outlined in the right-hand side of the screen). Of particular interest is Step-4, where you copy paste the CSR as captured in the text file.
3. Finally, when you finish the payment process on the issuer’s site (and all goes well), you will get an email from the issuer with the certificate as an attachment.
C) Step-by-Step installation procedure: Go to the IIS manager, go the website the CSR was generated for and then go to Server Certificates and click on ‘Complete certificate Request’. On the ensuing pop-up, point to the .cer file received from certificate issuer and click on OK. This will install the certificate ready for use for this website.
D) Making your site HTTPS:
Click on your website in IIS manager, and on the right hand side in ‘Features View’ in IIS7, click on SSL settings and enable SSL by checking the ‘Require SSL’ and ‘Require 128 bit SSL’ to force clients to use 128 bits. In case you are using Virtual Directories, you can enable/disable SSL settings per virtual directory. That’s it, test the site with your browser, when page loads, double click on the pad lock and viola, you see your certificate which is now securing your site.
Creating and Installing Digital Certificates - in Development
Sometimes, if you are like me then most of the times, we work in development infrastructure trying to get that secure WCF service working with HTTPS.
A) Make Cert: In Visual Studio Tools, Make Cert allows you to generate certificates with private keys. You can also generate Root certificates and then generate your certificate using this Root certificate. Go into VS command prompt and issue this command:
Step 1: Create a Certificate to Act as Your Root Certificate Authority
makecert -n "CN=RootCATest" -r -sv RootCATest.pvk RootCATest.cer
1. In this command:
· -n specifies the subject name for the root CA. The convention is to prefix the subject name with "CN = " for "Common Name".
· -r specifies that the certificate will be self-signed.
· -sv specifies the file that contains the private key of the certificate.
· RootCATest.cer specifies the name of the file containing the public key of the certificate.
2. In the Create Private Key Password dialog box, enter a password, confirm the password, and then click OK. Optionally, you can click None without entering the password, but this is not recommended for security reasons.
3. In the Enter Private Key Password dialog box, enter the password again and then click OK.
4. This is the password needed to access the private key file RootCATest.pvk in order to generate the file RootCATest.cer containing the public key.
This step creates a certificate named RootCATest.cer and a private key file named RootCATest.pvk.
Step 2: Install Your Root Certificate Authority on the Server and Client Machines
In this step, you install the certificate in the Trusted Root Certification Authorities location on both the client and server machines. All certificates that are signed with this certificate will be trusted by the client and by the server.
Repeat the following steps on both the client and the server machines:
1. Copy the RootCATest.cer file to the client and server machines.
2. Click Start and then click Run.
3. In the command line, type MMC and then click OK.
4. In the Microsoft Management Console (MMC), on the File menu, click Add/Remove Snap-in.
5. In the Add Remove Snap-in dialog box, click Add.
6. In the Add Standalone Snap-in dialog box, select Certificates and then click Add.
7. In the Certificates snap-in dialog box, select the Computer account radio button because the certificate needs to be made available to all users, and then click Next.
8. In the Select Computer dialog box, leave the default Local computer: (the computer this console is running on) selected and then click Finish.
9. In the Add Standalone Snap-in dialog box, click Close.
10. In the Add/Remove Snap-in dialog box, click OK.
11. In the left pane, expand the Certificates (Local Computer) node, and then expand the Trusted Root Certification Authorities folder.
12. Under Trusted Root Certification Authorities, right-click the Certificates subfolder, select All Tasks, and then click Import.
13. On the Certificate Import Wizard welcome screen, click Next.
14. On the File to Import screen, click Browse.
15. Browse to the location of the signed Root Certificate Authority RootCATest.cer file copied in Step 1, select the file, and then click Open.
16. On the File to Import screen, click Next.
17. On the Certificate Store screen, accept the default choice and then click Next.
18. On the Completing the Certificate Import Wizard screen, click Finish.
Step 3: Create and Install Your Temporary Service Certificate
In this step, you create and install the temporary certificate on the server machine from the signed root CA created in the previous step.
1. Open a Visual Studio command prompt and browse to the location where you have the root CA certificate and private key file installed. The files will be named RootCATest.cer and RootCATest.pvk.
2. Run the following command for creating a certificate signed by the root CA certificate:
makecert -sk <
In this command:
-sk specifies the key container name for the certificate. This name needs to be unique for each certificate you create.
-iv specifies the private key file from which the temporary certificate will be created. You need to specify the root certificate private key file name and make sure that it is available in the current directory.
-n specifies the key subject name for the temporary certificate. If the name of the certificate does not match the DNS or NetBIOS name, later proxy generation will fail.
-ic specifies the file containing the root CA certificate file generated in the previous step.
-sr specifies the store location where the certificate will be installed. The default location is Currentuser, but since the certificate needs to be available to all users, you should use the localmachine option.
-ss specifies the store name for the certificate. Specify My as the personal store location of the certificate.
-sky specifies the key type, which could be either signature or exchange. Using exchange makes the private key exportable, which is required for message security.
-pe specifies that the private key is exportable. This is useful if you want to export the key and use it in another machine for development or testing purposes.
In the Enter Private Key Password dialog box, enter the password for the root CA private key file specified in Step 2, and then click OK.
Note: Important: The subject name and key file name must match the name of the machine on which you are installing this certificate. If the name does not match, you will see a certificate security error when accessing the service.
Step 4: Configure Your Temporary Service Certificate in IIS to Support SSL
In this step, you configure the Web site in IIS to use the temporary certificate for Secure Sockets Layer (SSL) communication. This will enable SSL for the transport communication. These instructions pertain to IIS version 6.0. IIS 7.0 requires different steps.
Click Start and then click Run.
In the Run dialog box, type inetmgr and then click OK.
In the Internet Information Services (IIS) Manager dialog box, expand the (local computer) node, and then expand the Web Sites node.
Right-click Default Web Site and then click Properties.
In the Default Web Site Properties dialog box, click the Directory Security tab, and then in the Secure Communications section, click Server Certificate.
On the Web Server Certificate Wizard welcome screen, , click Next to continue.
On the Server Certificate screen, select the Assign an existing certificate radio button option, and then click Next. If you have a preexisting certificate that you can remove, first remove the certificate by using the Remove the current certificate option, and then proceed with Step 5.
On the Available Certificates screen, select the certificate you created and installed in the previous step, and then click Next.
Verify the information on the certificate summary screen, and then click Next.
Click Finish to complete the certificate installation.
In the Default Web Site Properties dialog box, click OK.
Temporary certificates should only be used for development and testing purposes. For real-world production environments, use a certificate provided by a CA such as Microsoft Windows Server 2003 Certificate Services or a third party.
Note: Remember these certificates are ok to use in .NET/ WCF world only, when talking to TIBCO/J2EE services, certificates are expected to have certain extensions like Key signature etc.
B) Using Built in Windows CA
So as to generate a certificate as close to as the real deal, use the built in CA in your windows XP/Vista. It will with a few clicks generate a certificate with your machine name as subject name, even attach your domain name, if it is part of the machine name.
Once you are IIS manager, click on “Create Self Signed Certificate”, it pops-up a dialog as below. Just fill in a friendly name and click on OK. This will generate a self signed certificate using your machine’s built in CA.
You can now check to see if this certificate was installed by going to management console as below:
1. Type mmc into startàrun and hit enter.
2. FileàAdd Remove Snap-in and on pop-up double click on your certificates.
3. Select Computer Account and click next, Local Computer and then click finish. Then click ok.
4. In the console tree, look at personal folder and you should be able to see the certificate you just created.
How to export your Public Certificates:
If you remember in beginning of previous article, I described the private/public key pairs and how server/SSL certificate carries both. Sometimes we need to export just the public certificate so that the public key can be sent to clients to communicate over SSL. The exported public certificates can be base-64 encoded, PKCS#7 format etc.
This can then be imported into client machines as below:
But remember in production world, when doing chain authentication; because every server has Thawte’s/Verisign’s/Digicert’s public certificate already in its browser, there is usually no need to exchange public certificate.
Good Luck and as always please leave some suggestions/comments.
Sunday, November 15, 2009
First time into the world of SSL Certificates; need simple, practical, usable, tips and explanations to implement one, alright then let’s get started. Few concepts:
SSL also known as Secure Socket Layer is a secure protocol which makes http traffic secure i.e. makes it https. It is a transport level protocol, meaning end to end traffic [e.g. from your browser to IIS] is encrypted using Public/Private Key pairs. This is as opposed to message level encryption where each individual Message [SOAP packet] is encrypted.
What is Public/Private Key Pair?
This question could be asked in no: of ways; what is PKI Infrastructure or what is Asymmetric Encryption? The answer is as follows:
Symmetric Encryption (e.g. DES) uses same key at both ends of traffic flow to encrypt and decrypt whereas Asymmetric Encryption uses a Private Key at Server end. A Private Key is secure and sits only on server; consider it the identity of the server. Public key is at the other end of traffic to decrypt and encrypt. Although there are no: of protocols available, SHA1-RSA seems to be a popular cocktail for Asymmetric encryption.
What is a CA?
This could also be asked as what is root authority? Or what is your root? This is really guys like Versign, Thawte, Geocert. Digicert etc. – Clarification: when I say ‘guys’, I mean ‘Digital Certificates’ of these companies. Think of these as the ‘Parent’ or ‘Master’ certificates. These are able to ‘issue’ SSL certificates which you would install on your server. Sometimes these issued certificates aarre able to issue more certificates. This is referred to as ‘Chain’ of certificates By default, our machine contains a no: of these pre-installed ‘Root’ and ‘Intermediary’ certificates.
To get to these pre-installed certificates, go to Internet explorer-->Tools-->Internet Options-->Content-->Certificates .
Here is a screenshot of Trusted Root CAs – i.e. your browser inherently trusts any certificate issued by these CAs. Remember these are Certificates of CAs themselves, i.e. these are certificates which ‘issue’ other certificates.
Here is another screenshot of the actual certificates installed on your machine. For e.g in the following screenshot, there is a certificate I issued to myself:
You can also look at certificates using Microsoft management console too. Go to Start-->Run-->type mmc-->File-->Add-Remove Snap-in-->double click Certificates-->Select ’Computer Account’ on ensuing pop-up-->Next-->Finish-->OK. This will show you the following view:
What is a Digital Certificate?
This question could also be asked as – what does a SSL certificate do? Or what does a Server Certificate do? Answers follow:
1. It secures all traffic from one end of traffic [Browser/Server] to other [IIS server] and is installed on a server e.g. a Web Server like IIS. It also contains a Private Key.
2. It is usually issued by a public CA [Certification Authority] like Verisign, Thawte etc but it can also be issued by an inbuilt CA in our local machine – a web server or even a XP/Vista Machine.
3. Digital certificate can be used for :
A) Transport Level: End to end authentication whereby the browser establishes session key with the web server and the encrypted session key is used for the duration of the session; all data passed between client and server is encrypted. e.g. ebay, paypal and your bank’s net banking services.
B) Authentication: If the server has a SSL certificate installed, then the client browser connects to the server and as the server responds to the client, it authenticates itself to the client; confirming it is who it claims to be. E.g. Company A. There are 2 levels of authentication provided by the SSL certificate:
i) Domain Authentication: Just the domain name is verified i.e. if someone connects to your server; the browser is guaranteed it is connecting to “www.yoursite.com”. The guarantee is provided by the issuer (e.g. Verisign)
ii) Organisation Authentication: The fact that Company A owns “www.yoursite.com” is verified. This is true SSL certificate and this si what you would want for your web server.
C) Mutual Authentication: This is a special case of Authentication. Imagine there are 2 web servers and both of them are required to authenticate/identify to teach other e.g. Company A’s Server A when initiates traffic flow with Company B’s Server B, the SSL certificate is requested from Server B and when Server B responds it asks Server A for its certificate.
In the next article on this series, I will discuss how to create and Install SSL certificates – in development and Production environment. Any suggestions, corrections or comments are welcome.
Thursday, August 13, 2009
CTP - community technology preview - this is just a point in time release to get more bits into hands of customers between beta releases, for those hard core people who want to be as close to the action as possible.
Beta - these releases get special attention from the QA Team, we plan for them, treat as a milestone, etc.
RC - release candidate, this is the one we hope will become an RTM. Testing additional RC candidates can get to be like a baseball game in extra innings. When we finally say "ship it" everyone celebrates.
RTM - release to manufacture, this is the RC that gets shrink wrapped.
Monday, April 13, 2009
Here are my 2 cents worth on MVC pattern.
MVC is an architectural pattern used in software engineeering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other.
The whole Navitaire application is based on the MVC or Model View Controller Pattern; also known as MVP or Model View Presenter design pattern.
The Model is responsible for managing application data and state, and communicating with a server. When an operation is performed on a model that changes the data or state of an application, the model notifies all of its consumers.
The View represents the presentation layer of an application. A view does not necessarily refer to a Windows form or a Web page and may not be visual at all. For example, a Web service or voice interface can be different views of the application that present the application data to the user.
The Controller provides validation, security enforcement and application workflow logic. For each user operation defined in an application there should be a controller method that is invoked that validates the data and security before invoking method calls on a model object. Logic related to application workflow can also be contained in the controller and may be dependent upon the active view.
As usual don't forget to leave comments. Thanks.
Wednesday, April 8, 2009
1. Object Oriented vs Service Oriented
Before we get into some programming syntax, let us look at what will be different for us as traditional OO (Object Oriented) programmers to get into the SO (Service Oriented) mode.
Object Oriented - Classes and Interfaces are the norm. Two Libraries dependent on each other communicating via dstributed object calls. Hence OO is a tightly coupled way to develop applications.
Service Oriented - Classes and Interfaces are still in use but there is decoration of WCF classes by attributes like ServiceContract, OperationContract. Since the application components and services are connected via messaging mechanism (passing messages) across different platforms, it is called loosely coupled.
e.g. A School Service:
2. Understanding Service Model in WCF
Sunday, April 5, 2009
Increase your Blog Views - Register with Technorati
Increase even more - Register With Blog explosion
Blog views Stats - StarCounter
Monetize - Google adsense (Dont click on it yourself mate ;)
Anyway I am guilty of Blog philia this weekend. I will be back to my usual ramblings soon. Reading a book on WCF by Michelle Bustamante and some MS Architecture guidelines.
Catch you later.