In part 1 of this series we discussed the steps needed and preparation done on the source 2008 R2 CA server prior to the move to the new 2012 R2 Server. For more details please check Part 1 article http://itcalls.blogspot.com.eg/2016/01/enterprise-ca-upgrade-from-2008-r2-to.html

In Part 2 we will start working now on the new 2012 CA server by installing the Certiifcation services and importing the backup taken from the old Source CA.

Certification Authority Installation:

1. 
   

In this series we will be going through the main steps to migrate and move our Enterprise Subordinate Certification Authority from Windows 2008 R2 server to Windows 2012 R2 Server (Side by Side move). In Part 1 of this series I will be discussing the main requirements and preparation done on the Source Server (CA on 2008 R2)

Key things to note:

1. If you would like to have the new CA server computer name same as the old one then you will need to decommission and remove the old server from the domain prior to building the new server. In our case i will keep the old server (Just disable the Certificate Windows services) and have the new server with new name (Just in case you need to revert back at any time)                                                                    
2. During the Migration and setup of CA on the new server no certificates or CRLs will be issued. Its preferred to run this after hours. Plan to publish a CRL that will cover the downtime period.                                                                                 
3. User running the migration should be member of Enterprise Admins or Domain Admins group.

After configuring and installing OCSP on an Enterprise Certification Authority I noticed that the OCSP location in the PKIView is displaying an error as per below screen shot.



The OCSP was working fine with current certificate and I verified and validated it using the

Certutil -url (Check below article for more details)

http://blogs.technet.com/b/askds/archive/2009/06/29/implementing-an-ocsp-responder-part-iii-configuring-ocsp-for-use-with-enterprise-cas.aspx

It turned to be that the original AIA path that was used has been changed on my CA extensions with another path which led to this error. So in order to fix this issue, the following was done:

1. Revoked the Latest CA Exchange certificate, this can be done by checking your Certification Authority - Issued Certificate - Arrange them by Certificate template and check the latest CA Exchange Certificate                                                                                                                                                                                                                                                                                                                                       
                                                                                                                                                                                                                  
2. From an Admin Command prompt run "certutil -cainfo xchg"                                                                                                                                                                                                                                   
                                                                                                                                                                                           

Several users started receiving certificate expiration warning messages on their computers regarding specific user certificates. Upon checking this certificate it turned out to be Lync Communication certificate as per the below screen shot.

Recently the SCOM server (One of your best friends on the network) started reporting the error "AD CS not configured for Revocation checking of all certificates", SCOM reported Event 128 as a warning

Event 128 is normally reported when someone try to use Certificate Request with all time-valid CA certificates to request a certificate. However y default CA doesn't support such request and event 128 gets reported.

After checking this issue and consulting Microsoft tech support, this issue will normally occur only after renewal of CA certificate. When the CA certificate is renewed, the OCSP Response signing certificate used for validation of existing certificates must still be signed by the CA certificate that was used to issue the existing certificates and new CA certificate. However by default CA doesn't support the renewal of OCSP Response signing certificate by using a previous CA certificate.

This issue/behavior can be fixed as follows:

1. From elevated CMD run the certutil -setreg ca\UseDefinedCACertInRequest 1
2. Restart the CA services

Its common that sometimes few admins miss the renewal of some key certificates in their Microsoft internal PKI (Public Key Infrastructure), this is due to the fact that its a bit of manual task and you need to set manually some Outlook reminders (My favorite method) or run schedules tasks to remind you before the Certificate expiration date.

However if you a user that logs frequently on this CA (Certificate Authority) server we can enable Auto Enrollment for this user. After configuring it, we don’t need to worry about the expiring certificates as long as the specific user still logs onto the CA.

To Enable Auto Enrollment you need to do the following:

1. Right click on the Certificate Template where you need to enable the Auto Enrollment feature
2. On the Security Tab (Check below image), add a specific user or grant an existing user the Auto Enroll permission (In my case i picked a normal low privileged service account that connects periodically on the server at least each month for maintenance and installing latest windows updates.)                                                                                                                                                                                                                                                                      
   
                                                                                                                                                            
3. Publish the Template and issue the needed certificate.
4. Open the Group Policy Management (On your Domain Controller) and either create a new Group policy or simply edit the Default Domain Policy
5. Navigate to User Configuration - Policies - Windows Settings - Security Settings - Public Key Policy and enable Autoenrollment as shown below. 

I recently passed with couple of scenarios where one of the issued Certificates in Microsoft PKI infrastructure solution has validity period shorter than the period already configured on the template of this certificate. The main reason of changing and increasing the validity period/years for several specific certificates is to avoid frequent renewal process. 

The scenario i passed by recently was when a user duplicated one of the templates and changed the Validity from the default 2 Years to 4 Years and issued the new Certificate however the issued certificate still reads 2 Years. This can be due to one of two reasons

1. The CA certificate period /Remaining Period (CA cannot issue a certificate that is longer than its own CA certificate) is less than the user certificate period. You cannot issue a user certificate which is 10 Years valid if your Root CA is 5 years only.
2. The default Validity Period that is allowed by CA (defined in CA reg)

To check for the CA Certificate period/Duration, you need to do the following

1. Open the CA Console
2. Right Click on the CA - Properties
3. From the General TAB click View Certificate and check the duration.

Its highly recommended when building your Microsoft PKI (Public Key Infrastructure) to have your Root CA offline after issuing the Enterprise Sub CA certificates. Its recommended to minimize the access to the Offline Root CA as possible. The Root CA is not a domain joined machine and can be turned off without any problem.

One of the Key issue is the CRL generated from the Root CA, you need to set the CRL interval for a large value so that we don’t need to copy the CRL to an online location frequently and do not implement delta CRLs, because the publication of each delta CRL would require access to the offline root CA in order to copy the delta CRL to an online publication location. In order to change the CRL interval you need to:

1. Turn on the Offline Root CA and login with Admin account
2. Open the Certification Authority Console
3. Right Click on the "Revoked Certificates" and click Properties.
4. Set “CRL Publish interval” to a large value (Default is 26 Weeks) and  uncheck “Publish Delta CRL” check-box.