This post will guide to to install CA Server over windows server 2012 ,
SSL websites (encryption) and individual (authentication)
When a web site is encrypted by a certificate, the owner of the certificate proves to the viewer of the content a match between the DNS name, the website name, and the certificate name in a process known as the secure socket layer (SSL). Hopefully most computer users do have some understanding of the meaning of SSL and encryption, i.e., web sites prefixed with https:// are expected when entering a password or credit card number.
Now thinking about authentication, when a user or computer or device entity presents a certificate for authentication, it proves the entity belongs to a trusted group of users, computers, or devices. The use of certificates for authentication replaces or augments traditional username/password credentials, and requires that someone or something possess a unique user, computer, or device certificate instead of, or in addition to, knowledge of a username and password.
Certificates are particularly useful to confirm identify of users and systems across Windows domains, using a federation concept; or in the absence of Windows networking when domain login using Kerberos is unavailable, for example, client computers in “workgroup” mode only. The mutual trust for the “certificate issuing authority” (the CA) replaces a trust for an Active Directory forest or domain.
Private vs. public CAs
If you publish websites to the public, you probably have purchased certificates from a publiccertificate provider such as VeriSign, GoDaddy, and Thawte. A public cryptographic authority (that issues trusted root authority certificates) is needed when you expect members of the general public, or large numbers of employees, partners, or customers, to trust your certificate.
These SSL certificates cost from $50 to $350 per year or more and are a good value if you have public-facing websites, and for Outlook WebApp (OWA) and Active-Sync. Individual private certificates for user, computers, and devices from public providers go for $10 to $50 per user or more annually. This quickly becomes too expensive for all but very small organizations with very high security requirements.
Most client operating systems already trust the root certificates of the major industry public certificate providers. However if you have internal-only, private websites that need SSL encryption and/or private services like token-based logon that need digital certificates for authentication, you can save a lot of money using private certificates — issued by and trusted by your network.
The trick is to get the private root trust certificate of your CA trusted by the client OS — this is done automatically by Active Directory Group Policy, but the trusted private root certificate must be manually distributed to devices and non-domain computers. It’s an actual digital file that must be stored on, or transferred to, the storage media or memory of the device. This is an administrative burden, but you can consider this an added security layer, because members of the general public don’t have the public key of the PKI solution. A properly designed root (and if appropriate) subordinate CAs can be self-renewing with little administrative work for periods up to twenty years, the maximum recommended lifetime of a root certificate.
Significantly, if you plan to use PKI for encryption of user, computer, and/or device authentication in your enterprise, you need to establish a private certificate authority (CA) or partner with a service provider to establish and maintain one for you. Once you have a private CA properly installed and optionally published to the Internet, you are in a position to be your own certificate provider and issue the same certificates the public providers do.
Certificates you issue can be used for private website SSL encryption, and for all user, computer, and device level authentication in a variety of valuable scenarios. Examples are hardening of routers and switch management such that they require certificates to have their settings changed remotely and centralized certificate-based SSH key issue for managing Linux computers.
Deploying a private CA with Windows Server 2012
There are some great features in Windows Server 2012 that leverage certificates for some useful scenarios like large-scale Direct Access, the VPN-less always-connected wide area networking based on IPv6. (Note: New with Windows Server 2012, small and medium organizations can deploy Direct Access without a full private CA deployment as well.) Most token-based, two-factor login solutions use certificates for their PKI, and Windows Server 2012 natively lets you present credentials on removable tokens.
Microsoft applications like Active Directory, Exchange and SharePoint can be integrated to include encryption and token-based certificates in countless high-security scenarios. You can literally save money deploying on-premise Lync 2010 if you use private certificates on some components. For example, creating trusted subject alternate name (SAN) certificates needed by Lync internal servers can be problematic without a CA. Another scenario is private certificates on domain controllers enabling S-LDAP scenarios, for example, cross-forest address lists between business partners.
You may already have a CA running on an earlier version of Windows, or you may decide now is the time to stand up your own private CA. Windows Server 2012 preserves existing CA technology from Windows Server 2008 and previous releases, and adds some new features as well. There is no lost investment for users of Microsoft’s enterprise PKI solution.
let’s see 🙂
congratulation you have internal CA and working well ,, don’t forget custom template if you need and edit security for admins if needed