Windows Server 2003 Installing CA

Windows Server 2003 can be used as a Certificate Authority (also known as CA) to provide extended security by offering support for Digital Certificates.
Digital Certificates can be granted to users based upon their roles and group membership. For example, a regular user that wants to enroll for a certificate will only be allowed to enroll for a specific set of Digital Certificates, while another user that is a member of the Domain Admins group will be allowed to enroll for a different set of certificates that can be used for a variety of functions, including Recovery Agents, IPSec, SSL and so on.
User Digital Certificates are valid for different purposes, including:

• Allowing data on disk to be encrypted
• Protecting e-mail messages
• Proving the user's identity to a remote computer

and more.
Note: There may be scenarios where a company might opt to use 3rd party issued Digital Certificates instead of creating their own, especially when that company's users will be dealing with out-of-the-company users, exchanging encrypted e-mail messages between themselves and these outside users, or when using SSL on a secured web site. This is because the outside users might not be willing to trust the company's internal CA.

Step 1: Install the IIS Service

In order to install the CA you will first need to install IIS on a Windows Server 2003 computer. On Windows Server 2003 IIS is not installed with the default Windows 2003 installation.

1. Click Start > Control Panel > Add or Remove Programs.
2. In Add or Remove Programs, click Add/Remove Windows Components.
3. Under Components, click on Application Server (but do NOT select it) and press on the Details button.
4. In the Application Server window click to select IIS and click Ok.
   
   
   Click Next
   
   
   
   
   
   6. After the wizard completes the installation, click Finish.

   Step 2: Install the CA Service

   To install the CA service perform the following steps:
   
   1. Click Start > Control Panel > Add or Remove Programs.
   2. In Add or Remove Programs, click Add/Remove Windows Components.
   3. Under Components, select Certificate Services.
      
      
      
      
      
      
      
      
      You will get a warning about domain membership and computer renaming constraints, and then click Yes.
      
      
      
      
      
      
      On the CA Type page, click Enterprise root CA, and then click Next.
      
      
      
      
      
      
      
      
      On the CA Identifying Information page, in the Common name for this CA box, type the name of the server, and then click Next.
      
      
      
      
      
      
      
      
      
      
      On the Certificate Database Settings page, accept the defaults in the Certificate database box and the Certificate database log box, and then click Next.
      
      
      
      
      
      
      
      
      
      
      9. You will get a prompt to stop Internet Information Services, click Yes.
      10. Enable Active Server Pages (ASPs), by clicking Yes.
      11. When the installation process is completed click Finish.

      Step 3: Obtain a User Digital Certificate from the CA

      After installing and configuring the CA on your domain you will now need to ask your users (at least those who will require message security) to enroll for a Digital Certificate.
      
   
   
   
   
   Abstracted From http://www.Petri.com
   
   
   
   
   
   

SSL(Secure Socket Layer) & Certificate Authority

What is SSL and what are Certificates?

The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works.

1. A browser requests a secure page (usually https://).
2. The web server sends its public key with its certificate.
3. The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
4. The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.
5. The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data.
6. The web server sends back the requested html document and http data encrypted with the symmetric key.
7. The browser decrypts the http data and html document using the symmetric key and displays the information.
   
   
   
   

   Private Key/Public Key:

   The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. This is sometime hard to understand, but believe me it works. The keys are similar in nature and can be used alternatively: what one key emcrypts, the other key pair can decrypt. The key pair is based on prime numbers and their length in terms of bits ensures the difficulty of being able to decrypt the message without the key pairs. The trick in a key pair is to keep one key secret (the private key) and to distribute the other key (the public key) to everybody. Anybody can send you an encrypted message, that only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite , you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. Beware, in this case the message is not secured you have only signed it. Everybody has the public key, remember!
   One of the problem left is to know the public key of your correspondent. Usually you will ask him to send you a non confidential signed message that will contains his publick key as well as a certificate.
   

   Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message

    The Certificate:

   How do you know that you are dealing with the right person or rather the right web site. Well, someone has taken great length (if they are serious) to ensure that the web site owners are who they claim to be. This someone, you have to implicitly trust: you have his/her certificate loaded in your browser (a root Certificate). A certificate, contains information about the owner of the certificate, like e-mail address, owner's name, certificate usage, duration of validity, resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage) and the certificate ID of the person who certifies (signs) this information. It contains also the public key and finally a hash to ensure that the certificate has not been tampered with. As you made the choice to trust the person who signs this certificate, therefore you also trust this certificate. This is a certificate trust tree or certificate path. Usually your browser or application has already loaded the root certificate of well known Certification Authorities (CA) or root CA Certificates. The CA maintains a list of all signed certificates as well as a list of revoked certificates. A certificate is insecure until it is signed, as only a signed certificate cannot be modified. You can sign a certificate using itself, it is called a self signed certificate. All root CA certificates are self signed.
   
   
   
   

   The Symmetric key:

   Well, Private Key/Public Key encryption algorithms are great, but they are not usually practical. It is asymmetric because you need the other key pair to decrypt. You can't use the same key to encrypt and decrypt. An algorithm using the same key to decrypt and encrypt is deemed to have a symmetric key. A symmetric algorithm is much faster in doing its job than an asymmetric algorithm. But a symmetric key is potentially highly insecure. If the enemy gets hold of the key then you have no more secret information. You must therefore transmit the key to the other party without the enemy getting its hands on it. As you know, nothing is secure on the Internet. The solution is to encapsulate the symmetric key inside a message encrypted with an asymmetric algorithm. You have never transmitted your private key to anybody, then the message encrypted with the public key is secure (relatively secure, nothing is certain except death and taxes). The symmetric key is also chosen randomly, so that if the symmetric secret key is discovered then the next transaction will be totally different.
   

   Symetric Key-->[Public Key]-->Encrypted Symetric Key-->[Private Key]-->Symetric Key

   
   
   
   

   Encryption algorithm:

   There are several encryption algorithms available, using symmetric or asymmetric methods, with keys of various lengths. Usually, algorithms cannot be patented, if Henri Poincare had patented his algorithms, then he would have been able to sue Albert Einstein... So algorithms cannot be patented except mainly in USA. OpenSSL is developed in a country where algorithms cannot be patented and where encryption technology is not reserved to state agencies like military and secret services. During the negotiation between browser and web server, the applications will indicate to each other a list of algorithms that can be understood ranked by order of preference. The common preferred algorithm is then chosen. OpenSSL can be compiled with or without certain algorithms, so that it can be used in many countries where restrictions apply.
   
   

   The Hash:

   A hash is a number given by a hash function from a message. This is a one way function, it means that it is impossible to get the original message knowing the hash. However the hash will drastically change even for the slightest modification in the message. It is therefore extremely difficult to modify a message while keeping its original hash. It is also called a message digest. Hash functions are used in password mechanisms, in certifying that applications are original (MD5 sum), and in general in ensuring that any message has not been tampered with. It seems that the Internet Enginering Task Force (IETF) prefers SHA1 over MD5 for a number of technical reasons (Cf RFC2459 7.1.2 and 7.1.3).