<div>
It is not that hard. Just stop issuing SHA1 certificates like 5 days ago.
</div>


<div>
the SHA256 for internal certs is easy to stop issuing them as SHA1 and you can do that on your existing CA now.<br />
<br />
As you have a CA on your Domain controller i would suggest either migrating that Root CA or setup a new one on a new server, then you would setup a new Sub CA to do issuing and take that opportunity to update the CA certs to be SHA256.<br />
That way you end up with a standalone root CA which you can follow best practice and take it offline and have a sub CA in AD which does the issuing.<br />
If you do it that way you have laid out you would have to redo CA certs to many times which will cause issues with certificate chains being trusted and you end up with several CA certs needing to be held to maintain the chain
</div>


<div>
1st of all its not mandatory to upgrade internal CA from Sha-1 to Sha-2, there is no effect of Sha-1 deprecation on internal CA<br />
Since you already have enterprise root CA, I don't see any requirement of subordinate CA<br />
<br />
Your best option could be just upgrade csp to ksp on existing enterprise root CA only, note that you do require 2012 R2 / 2012 server for time being to support ksp commands because 2008 r2 version certutil do not support ksp commands<br />
<br />
If you have standalone offline root CA, then it make sense to have / deploy subordinate enterprise root CA<br />
<br />
You can refer below article for step by step<br />
<a href="http://blogs.technet.com/b/askds/archive/2015/10/26/sha1-key-migration-to-sha256-for-a-two-tier-pki-hierarchy.aspx" rel="ugc">http://blogs.technet.com/b/askds/archive/2015/10/26/sha1-key-migration-to-sha256-for-a-two-tier-pki-hierarchy.aspx</a><br />
For registry entries copy code from below article<br />
<a href="https://technet.microsoft.com/en-us/library/dn771627.aspx" rel="ugc">https://technet.microsoft.com/en-us/library/dn771627.aspx</a>
</div>


<div>
Thanks for all the comments guys, I appreciate it. Note that the Existing CA is windows server 2008 R2. The key provider is Microsoft Stong Crypto Provider. That only supports SHA1 (I may have put that wrong in the original post, my apologies). <br />
<br />
I know that it's not required to upgrade internal CAs but according to the Microsoft Technet, they are starting to trust SHA-1 less and less. On 1/1/17 they will consider the connection a security risk. Chrome already flags the certificates with a different certificate designation in the browser. &nbsp;I'm not sure if it will still consider the &quot;chain&quot; insecure if I have a SHA-2 certificate, signed by a Subordinate that has a SHA-1 certificate that's been issued by my SHA-1 Root CA. Too many variables. We are going to be using User and Computer certs for 802.1x auth and I don't want to roll out until I get SHA-256 configured. No reason to start with an outdated certificate on a new project. <br />
<br />
I think you guys are right, the risk to reward to upgrading the current cert or even adding the subordinate under the current CA doesn't seem to make sense. I'll suggest we stand up the new PKI environment and just migrate slowly over.
</div>


<div>
You can go with new CA if you have less certificates issued to users, computers because after new CA deployment you have to renew all certificates, there is no migration / co-existence possible<br />
<br />
You could keep DC and CA on same server without any issues and same time you can change certificate provider to KSP (Sha-2)<br />
<br />
If existing issued certs quantity is more in thousands, then there is no point in deploying new CA according to me. you could move CA server role on new 2012 R2 server, however this has more steps and complications (but one time for day or two)<br />
1st you have to backup CA DB and Cert followed by uninstall CA role from server<br />
Then you need to rename DC server host name - separate steps for that<br />
Then you need to build 2012 r2 member server as CA server with same hostname as old DC name and need to restore CA certificate along with database followed by you can change provider to KSP<br />
These steps will ensure that already issued certificates will remain valid in terms of CRL and AIA<br />
There are MS articles available to move CA role from one server to another <br />
<br />
If you move CA role on server having different hostname than previous, then already issued certificates will fail to check CRL and AIA functions and it will start certificate validation errors
</div>


<div>
Mahesh, at this point we are not doing any auto-enrollment from all the research I have done thus far. All certificates are basically web certificates. We are currently a small environment, under 200 servers, with probably 100 total SSL certificates. <br />
<br />
I really want my entire chain at SHA-256. that, as you said would require a rekey which invalidates the &nbsp;existing deployed certificates that have been issued as the Root CA would &nbsp;using a different certificate generated via SHA-256. I think my best option is to stand up a new CA environment as the CA involvement, at this point is not that large. If this was a bigger environment, in the thousands as you mentioned, I think my hands would be tied to actually perform this upgrade, but live with a SHA-1 cert chain.<br />
<br />
Another question. I collegue asked if there's a dependency to have the CA services on a domain controller? I have done this previously in a different environment but never heard of requiring the CA services to run on a DC. Also are there any dependencies on functional-levels of the forest? I think we are still at 2003 due to some older authenticating application that's being retired soon.
</div>


<div>
You can run CA with openssl command line and import produce to active directory. Builtin CA is somewhat easier to operate.
</div>


<div>
Yes I'm used to standalone CAs which are so much easier but the manager wants &quot;Enterprise&quot; for the AD integration.
</div>


<div>
The TechNet actually shared the move from CSP (2008) to KSP (2012). It include standalone but as a whole moving to EntCA is to do it fist time right if machine are all domain joined. Also a scalable CA practice is to isolate RootCA and have issuing CA as the subordinate CA. The latter issuance of cert &nbsp;will be good moving ahead. <br />
<br />
The chain trust is actually alright if root is SHA1 (for legacy support reason mainly) as the server issued by subCA will not be affected as the long as SubCA maintain at SHA256 - PCI check go to that compliance level but I do agree that whole chain goes for SHA256 ultimately. <br />
<br />
Likewise you may consider to have your DC not as CA at the same time though most have done it for convenience and default to that single server for all security checks. AD and CA maintenance at times will be more easily managed for downtime and by various team operationally.
</div>


<div>
<div class="content wysiwyg-content">
I have a windows 2008 R2 server that serves as a domain controller and doubles as an Enterprise Root CA. The CA is using CSP and SHA-1. We are working to figure out the details of getting to SHA-256. I know I have to upgrade to get to KSP to allow for SHA-2. There are a couple things that I am hoping for clarification on my plan.<br />
<br />
I think my best option for the least amount of disruption would be to setup a Subordinate CA on Windows 2012 R2 Ent. I would originally get a SHA-1 certificate for the subordinate. I would use KSP as the provider and start issuing SHA-256 certificates from the subordinate. I would begin replacing the certificates that have been issued directly from the Root CA (currently all certs are generated from the Root) with certificates from the subordinate. After all certificates have been replaced, I would deploy a new Root CA on Windows 2012 R2 Ent and move the subordinate underneath that new Root CA. I would use GPO to push the subordinate and the new Root CA to my domain machines. <br />
<br />
<br />
Is this a valid approach? More work than necessary? Suggestions? Thank you!
</div>
</div>


I have a windows 2008 R2 server that serves as a domain controller and doubles as an Enterprise Root CA. The CA is using CSP and SHA-1. We are working to figure out the details of getting to SHA-256. I know I have to upgrade to get to KSP to allow for SHA-2. There are a couple things that I am hoping for clarification on my plan.

I think my best option for the least amount of disruption would be to setup a Subordinate CA on Windows 2012 R2 Ent. I would originally get a SHA-1 certificate for the subordinate. I would use KSP as the provider and start issuing SHA-256 certificates from the subordinate. I would begin replacing the certificates that have been issued directly from the Root CA (currently all certs are generated from the Root) with certificates from the subordinate. After all certificates have been replaced, I would deploy a new Root CA on Windows 2012 R2 Ent and move the subordinate underneath that new Root CA. I would use GPO to push the subordinate and the new Root CA to my domain machines. 


Is this a valid approach? More work than necessary? Suggestions? Thank you!

PKI upgrade to SHA-256

HTTPS is a protocol for secure communication over a computer network which is widely used on the Internet. HTTPS consists of communication over Hypertext Transfer Protocol (HTTP) within a connection encrypted by Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL). The main motivation for HTTPS is authentication of the visited website and to protect the privacy and integrity of the exchanged data. HTTPS is widely used for protecting page authenticity on all types of websites, securing accounts and keeping user communications, identity and web browsing private.

SSL / HTTPS

Windows Server 2012 is the server version of Windows 8 and the successor to Windows Server 2008 R2. Windows Server 2012 is the first version of Windows Server to have no support for Itanium-based computers since Windows NT 4.0. Windows Server 2012, now in its second release (Windows Server 2012 Release 2) includes Foundation, Essentials, Standard and Datacenter, and does not support IA-32 or IA-64 processors.

Windows Server 2012

Security is the protection of information systems from theft or damage to the hardware, the software, and the information on them, as well as from disruption or misdirection of the services they provide. The main goal of security is protecting assets, and an asset is anything of value and worthy of protection.  Information Security is a discipline of protecting information assets from threats through safeguards to achieve the objectives of confidentiality, integrity, and availability or CIA for short. On the other hand, disclosure, alteration, and disruption (DAD) compromise the security objectives.