Design Your Solution

Using Windows Server Digital Certificates

Print
Check out this page on Dell.com! Email
Rate
1 out of 5
2 out of 5
3 out of 5
4 out of 5
5 out of 5

By: Tom Henderson (7/28/2010)

Certificate services are used to generate and subsequently verify or impugn requests for certificate files. The certificate files are used to verify authenticity of transactions or session relationships between computers. This verification is part of the process of creating encrypted conversations between systems, including Virtual Private Networks (VPNs). Windows Certificate Services has a Certificate Authority (CA), which generates certificates for servers and local desktops. Networks with Web servers that need certificates for SSL and HTTPS protocols can use Windows® CA services, or get certificates generated by other, third-party Certificate Authorities. Considering Certificates A Certificate Authority is critical for network communication safety, as well as authenticating users, processes, and their requests. The process works like this: a user or process makes a request, and is issued a key. The key is compared with a certificate located at the Certificate Authority. The CA compares the key to a reference key it holds, and verifies (or impugns) the request. Certificates are digital files containing meta-information regarding the origin of the certificate and a unique set of random numbers. Windows Certificate Services generate local system certificates for users, then stores them to subsequently verify authenticity of a request. If Windows CS is used to generate the certificate, then the certificate is filed, and when users (or processes) make authentication requests, CS says, essentially, “yes, that’s authentic” or “no, there’s a problem.” It’s part of a trust system. On busy networks using machine-machine encryption, the certificates aren’t referred to very often. The cycle on internal certificate authentication requests is low even on busy internal networks; the authentication traffic is comparatively boring in size. On public-facing Web sites, where HTTPS or SSL/TLS encryption are used, however, authentication requests can come many times per second. Here, referring to a third party for authentication starts to make sense, not only to cut traffic, but also to diminish organizational liability. If a third party holds the root certificate, the third party has presumably done at least some work to verify the credentials of organizations whose certificates they vet. In real life, the vetting process may be extensive or minimal, depending on the policies of the third party root certificate authority. Some are lax, others are thorough. IIS and Apache can proxy authentication requests to an internal or external Certificate Authority for verification. Third Party CAs Public-facing websites that require authentication for Transport Layer Security (TLS) often use third-party certificate issuers and CAs. Users receive assurance that the site to which they’re navigating is indeed who they say they are, rather than someone phishing their information. Self-signed certificates don’t necessarily offer this type of protection, and aren’t going to be found in the browser certificate cache, making site visitors shy away from them. Third party CAs authenticate one or many fully qualified domain names (FQDNs) for other sites, depending on their price, which varies from free to several hundred dollars per year. These CAs, like Network Solutions and VeriSign, use a fairly rigorous procedure to authenticate and verify information about the organization behind the FQDN, and have reasonable tech support for difficulties or when circumstances demand changes in the certificate, or how it’s responded to. For example, banks often need to expire certificates for various products, and new certificates may need to be generated or updated to reflect changes with the product. Internal CS and CA Windows has four kinds of certificate services servers, which are sometimes used independently and other times are used in conjunction with a DNS server role implementation. There is an enterprise root CA, enterprise subordinate CA, a stand-alone root CA, and stand-alone subordinate CA. The initial process for enterprise or stand-alone services is to generate a root certificate. This takes a few minutes. Subsequently other services can be built from the stored certificate. Smartcards can be enabled, as well as Windows network admittance controls, which in turn, are based on certificates given to users when they pass an initial configuration safety test. Network encryption is subsequently anchored on certificate authentication (server certificates) by users that enable them to set IPSec protocol-based communications. Overall Windows networks don’t need to have Certificate Services at all; they’re optional. If one takes the option, however, many services become available, including encryption, network authentication control, and internal and external authentication. Each organization must decide if they have need for public-facing external HTTPS/SSL/TLS encryption, and then the choice becomes whether to handle Certificate Services yourself, or use third-party authenticators for verification. External certificate providers add cost, but for some organizations, the added trust makes them mandatory. Related Information From Dell.com: A Success Blueprint for the Efficient Enterprise.

Certificate services are used to generate and subsequently verify or impugn requests for certificate files. The certificate files are used to verify authenticity of transactions or session relationships between computers. This verification is part of the process of creating encrypted conversations between systems, including Virtual Private Networks (VPNs).

Windows Certificate Services has a Certificate Authority (CA), which generates certificates for servers and local desktops. Networks with Web servers that need certificates for SSL and HTTPS protocols can use Windows® CA services, or get certificates generated by other, third-party Certificate Authorities.

Considering Certificates

A Certificate Authority is critical for network communication safety, as well as authenticating users, processes, and their requests. The process works like this: a user or process makes a request, and is issued a key. The key is compared with a certificate located at the Certificate Authority. The CA compares the key to a reference key it holds, and verifies (or impugns) the request.

Certificates are digital files containing meta-information regarding the origin of the certificate and a unique set of random numbers. Windows Certificate Services generate local system certificates for users, then stores them to subsequently verify authenticity of a request. If Windows CS is used to generate the certificate, then the certificate is filed, and when users (or processes) make authentication requests, CS says, essentially, “yes, that’s authentic” or “no, there’s a problem.” It’s part of a trust system.

On busy networks using machine-machine encryption, the certificates aren’t referred to very often. The cycle on internal certificate authentication requests is low even on busy internal networks; the authentication traffic is comparatively boring in size.

On public-facing Web sites, where HTTPS or SSL/TLS encryption are used, however, authentication requests can come many times per second. Here, referring to a third party for authentication starts to make sense, not only to cut traffic, but also to diminish organizational liability. If a third party holds the root certificate, the third party has presumably done at least some work to verify the credentials of organizations whose certificates they vet. In real life, the vetting process may be extensive or minimal, depending on the policies of the third party root certificate authority. Some are lax, others are thorough. IIS and Apache can proxy authentication requests to an internal or external Certificate Authority for verification.

Third Party CAs

Public-facing websites that require authentication for Transport Layer Security (TLS) often use third-party certificate issuers and CAs. Users receive assurance that the site to which they’re navigating is indeed who they say they are, rather than someone phishing their information. Self-signed certificates don’t necessarily offer this type of protection, and aren’t going to be found in the browser certificate cache, making site visitors shy away from them.

Third party CAs authenticate one or many fully qualified domain names (FQDNs) for other sites, depending on their price, which varies from free to several hundred dollars per year. These CAs, like Network Solutions and VeriSign, use a fairly rigorous procedure to authenticate and verify information about the organization behind the FQDN, and have reasonable tech support for difficulties or when circumstances demand changes in the certificate, or how it’s responded to. For example, banks often need to expire certificates for various products, and new certificates may need to be generated or updated to reflect changes with the product.

Internal CS and CA

Windows has four kinds of certificate services servers, which are sometimes used independently and other times are used in conjunction with a DNS server role implementation. There is an enterprise root CA, enterprise subordinate CA, a stand-alone root CA, and stand-alone subordinate CA.

The initial process for enterprise or stand-alone services is to generate a root certificate. This takes a few minutes. Subsequently other services can be built from the stored certificate.

Smartcards can be enabled, as well as Windows network admittance controls, which in turn, are based on certificates given to users when they pass an initial configuration safety test. Network encryption is subsequently anchored on certificate authentication (server certificates) by users that enable them to set IPSec protocol-based communications.

Overall

Windows networks don’t need to have Certificate Services at all; they’re optional. If one takes the option, however, many services become available, including encryption, network authentication control, and internal and external authentication. Each organization must decide if they have need for public-facing external HTTPS/SSL/TLS encryption, and then the choice becomes whether to handle Certificate Services yourself, or use third-party authenticators for verification. External certificate providers add cost, but for some organizations, the added trust makes them mandatory.

Related Information From Dell.com: A Success Blueprint for the Efficient Enterprise.