Hi,
When you need a digital certificate for your organization, typically for SSL or other encryption-related needs, most people are inclined to buy a certificate from a third-party vendor. Certificates can be pretty pricy -- a wildcard certificate, which provides SSL certification for a given domain and all of its possible subdomains, can run as much as $900.
Follow these steps to generate and sign your own digital certificates:
Look in the Add/Remove Programs section of the Windows server that will be the enterprise CA for the domain, and click on Add/Remove Windows Components.
Make sure the World Wide Web Service and Internet Information Services Manager (these last two are in Application Server) are also installed. If not, check them off and install them first, then reboot.
The Certificate Services component should be installed. If it's not, check it off and install it. Both the Certificate Services CA and Certificate Services Web Enrollment Support components should be installed. The CA configuration wizard will start.
A word of caution about installing the Certificate Services component: When you do, you'll be warned that the machine's name and domain membership cannot be changed "due to the binding of the machine name to CA information in Active Directory." In short, if you're going to set up a machine to create certificates, it should be one of the last steps you take with that machine when it's being configured.
When you're asked which type of certification authority to set up, make sure you select Enterprise root CA.
The "Common name" for the CA should be the DNS host name or NetBIOS name of the machine running Certificate Services. You can also set the validity period for any certificates you sign; by default, it's five years, which should be more than adequate for the type of work needed.
The other defaults for the CA wizard should be left as is.
More detailed directions for setting up a certification authority are available in Microsoft's online documentation for Windows Server. There's also a utility called SelfSSL in the IIS 6.0 Resource Kit that allows you to automate the process of generating and installing a self-signed certificate, so you don't need to go through the whole process manually.
There are a number of benefits to being your own certification authority, and there are about as many risks. Consequently, it's not something everyone should consider as an automatic possibility.
The benefits:
It's relatively easy. I mentioned the SelfSSL utility, and there are a number of tutorials that describe how to generate your own certificates without too much difficult.
It's inexpensive. With Windows Server, for instance, the tools needed to create the certificates are part of the OS itself and come at no additional cost.
It can be done in a very short amount of time -- minutes at most.
You have total control over the process and can generate exactly the certificate you need.
The risks:
Some people will be leery to trust a certificate that was not certified by a trusted third party, and may in fact reject it outright. Web browsers might alert the user that the certificate was self-signed and flag it as a problem, so it may not be possible to use a self-signed certificate for public commerce.
One of the reasons for having a certificate signed by a third party is to guarantee that the site users are communicating with really is who it says it is. A self-signed certificate is much more vulnerable to a man-in-the-middle attack. For instance, if someone spoofed your site from the outside and generated a self-signed certificate to go with it, it would be that much easier to fool relatively incautious users into thinking their site is your site.
DNS cache poisoning is a way to hijack a server by changing the IP record for that server in the DNS server that hosts its domain name. A certificate makes this harder to pull off, since the certificate ensures that the IP address and the domain name match; in other words, the IP address retrieved from the DNS server is checked against a third party. Obviously, this means that if you change IP addresses for a server, you'll need to issue new certificates for it, but that ought to happen rarely enough that it won't be an issue.
One good rule of thumb to determine whether or not to use a self-signed certificate for anything is the scope of its use. Any encryption that's being conducted in a forum accessible by the general public, whether it's commerce or just regular communications, should be done with a commercially generated and signed certificate. If you're just testing something internally or want to set up a communications channel amongst you and a number of other known and trusted parties who aren't going to have a problem with a self-signed certificate, then you can set yourself up as your own certification authority.
Refer these links
http://www.cisco.com/application/pdf/paws/98599/csr-thirdparty-wcs.pdf
Regards,
Surya
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.