Update Mocrosoft PKI CA to SHA256

Hello,

We have Windows PKI running on server 2012 standard. We have a Root CA server that is switched off and an Issuing Intranet CA that gives out the certificates. I have found this guide to update to SHA256:
http://www.cusoon.fr/update-microsoft-certificate-authorities-to-use-the-sha-2-hashing-algorithm-2/

Is this guide relevant in my case?
Do I need to do this on both Root and Issuing CA?
Will that affect existing certificates?
Do I need to do anything with the certificate templates?

Many thanks!
rookie_bAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
Specifically this article will be more useful as it mentioned
..this depends on the Cryptographic Provider that CA is using. And since each Windows version ships with specific set of providers, you may need to upgrade your CA to a newer version of Windows in order to support SHA-2.

Even if you are using a cryptographic provider that supports SHA-2, you need to instruct the CA to use SHA-2 for future signing requests.
IN fact, the article http://ammarhasayen.com/2015/02/04/what-makes-a-ca-capable-of-issuing-certificates-that-uses-sha-2/ actually reference to your shared link for the SHA-2

I suggest you reference this for upgrade to SHA-2 family
https://technet.microsoft.com/en-us/library/dn771627.aspx
Ensure that SubCA or issuing CA cert keep the old keys and if there are no AD clients they need the new SHA2 cert loaded. Note:  Windows has not set any dates for blocking other types of certificates (e.g., S/MIME) but SSL and code signing; CAs, however, should expect SHA1 certificates issued after 1/1/2017 may stop working at any time.
For code signing certificates, Windows 7 and later versions will stop accepting code signed with SHA-1 certificates without timestamps that were made prior to January 1, 2016. This enforcement will be performed only in user mode using the framework that Windows has for blocking weak cryptographic algorithms. Code signed with SHA-1 certificates that are time stamped before 1 January, 2016 will be accepted until 14 January 2020 (when Server 2008 extended support ends), at latest. This date may be moved earlier if Microsoft decides SHA1 is vulnerable to pre-image attack.

Windows 7 now has additional support for SHA-2 that brings it to parity with Windows 8.  
http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
h1r0Commented:
The easiest and least risky way to handle this is by implementing a new pki in parallel to the existing one and migrating certificate templates over to the new issuing subordinates gradually.  This way, you have an easy way to roll back to your old environment in the event of a failure.  

I would build put a new offline root with sha2 4096 key length.  Then build out two issuing subordinate servers - this way if one of the issuing servers gets owned you don't have to reissue ALL of your certificates.    These servers should have 2048 key length and sha 256 unless you a re positive everything relying on the certificate chain can support higher key lengths.  You will also want to add an http CRL distribution point that points to a webfarm to allow non domain joined devices and machines to perform certificate revocation lookups.

I would also put the certificate web role in this same farm to allow manual certificate enrollment via the web portal.  It's best practice to keep this role off of the issuing cas to protect them from security breaches.  


Finally if you have something external that requires CRL such as sccm- you will need to place another farm in the dmz .  These servers should be joined to a separate dmz forest/domain with a one way trust back to the primal domain.  


Your first step is to identify all issued certificates and the certificate templates in use.  Take special care to identify things like efs and mission critical systems.

As for the migration you will want to install the new ca's without the default certificate templates. This will prevent them from issuing templates until you are ready.  

Next , you want to update the CRL period for all issued certificates to match or exceed the issues certificates expiration date.  This is done so certificates will a have valid crl until they expire allowing you to remove the ca without affecting those issued certs when the time comes.

Next remove a certificate template form the old ca and recreate it in the new ca.  Then reissue the certificate - sometimes this is a manual process (web servers). And sometimes this is automated through auto enrollment policies.  Rinse and repeat until the migration is complete.  

Keep the old pki in place for a few months just to make sure everything is working.  If some, uninstall the ca role and clean up ad to fully remove it - just don't remover the cdp from ad as a precaution .
0
btanExec ConsultantCommented:
just to add that specific to PKI, the CRL is critical. You must establish a regular publication schedule for certificate revocation data so that a highly accurate CRL is always available to clients.

A new CRL is by default published in the following folder: systemroot \system32\CertSrv\CertEnroll\. If the machine is a domain member and has permission to write to AD Domain Services (AD DS), then the CRL is also published to AD DS.

Note that the CRL publishing period is not the same as the validity period for a CRL. By default, the validity period of a CRL exceeds the publishing period of a CRL by 10 percent (up to a 12-hour maximum) to allow for directory replication.

Similar in CRL context but this time in Cert trusted list CTL, in the case of recent case on D-Link's four cert private key were inadvertently disclosed by D-Link and has since been revoked. MS advisory is published on 24 Sep 15 to notify customers that Microsoft has modified the Certificate Trust List (CTL) to remove trust for four digital certificates and that the respective issuing certificate authorities (CAs) have revoked the certificates.

The key is automatic updater of revoked certificates is included in supported editions of Windows 8, Windows Server 2012, Windows RT, Windows 8.1, Windows RT 8.1, Windows Server 2012 R2, and Windows 10 and for devices running Windows Phone 8 and Windows Phone 8.1. But for Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2 it is not in built and so to receive this update customers must install the automatic updater of revoked certificates or do it manually via MMC.. see https://technet.microsoft.com/en-us/library/security/3097966

Timeliness and continuous watchover via the logging is important to ensure readiness of the whole PKI
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2012

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.