How to Upgrade/Move your Enterprise Certification Authority (CA) from 2008 R2 to 2012 R2 - Part 2

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. 
   

Read More...

How to Upgrade/Move your Enterprise Certification Authority (CA) from 2008 R2 to 2012 R2 - Part 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.

Source Server (2008 R2) Preparation

1. Publish a new CRL to ensure that your migration period is covered. Open Certification Authority - Right Click Revoked Certificates - All Tasks - Publish                                                                                  
                                                           
2. Take a backup from the Current Source CA (2008R2 server) - Right Click Certification Authority - All Tasks - Back Up CA                                                                                                        
                                                 Make sure to pick both check boxes as shown above   (Private Key, CA Cert and DB). Store them in a dedicated empty folder (will be copied later to the destination server).                              
                                                               
             
3. After picking a password and finishing the Wizard check the Backup folder (In our case C:\CA_Backup). We should have a CAname.P12 file and a Database folder.                                                        
4. Next step will be taking a backup from the CA configuration in the registry as another check point/line of defense (hopefully won't be needed). Navigate to HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration and right click configuration and take an Export and save the output REG file in the same Backup location.                                                                                                      
   
                                                                                                 
5. If a Custom CApolicy is used then we need to copy the CApolicy.inf file from the C:\Windows (Default location) to the backup folder created earlier.                                                                                 
6. Final step to be done on the Source CA server is to stop the certification Authority service and change its start up to be disabled in case anyone by mistake tried to start it (Remember we will be keeping the source server for some time till everything is up on the new server)                                                             
   

This should conclude Part 1 of this series, In Part 2 we will install the CA on the new 2012 R2 and restore the backup taken on the old  2008 R2.  Hopefully this has been beneficial and see you on the next Part.

Read More...

PKIView OCSP Location#1 Error

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"                                                                                                                                                                                                                                   
                                                                                                                                                                                           

This did the trick and it was fixed back in the PKIView.

Read More...

Users Expired Certificate Warning-Lync Certificate

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.

This message is a normal Windows Warning Notification regarding a user certificate stored in the personal certificate store of the user account logged on this machine. In this specific case it was Microsoft Lync Communication certificate. When the Lync communication certificate expires, the client will just receive new certificate for the user SIP URI and everything should work normal.

However to manually stop receiving the warning shown above the user can check the box near the certificate and click done.

The question is why all users in the domain started getting these warning messages. To identify the root cause, i ran a GPRESULT from one of the client computers and i noticed a group policy configured across the domain with these warning settings. These specific settings are located under

“User Configuration/Windows Settings/Security Settings/Public Key Policies/Certificate Services Client – Auto-Enrollment Settings”

There is a checkbox as shown below for the Expiration Notification when the the given percentage of certificate lifetime is reached. To avoid getting these warning you can remove/uncheck this option and users won't receive this notification.

It should be noted that if there is no group policy set, the users won't get any notification and won't even notice that the certificate expired and they got a new one.

Read More...

AD CS not configured for Revocation checking of all certificates

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

This command will enable the CA support for certificate request signed by old certificate. If the OCSP is not renewed, you need to go ahead and renew it as per the following articles

http://blogs.technet.com/b/xdot509/archive/2013/06/06/operating-a-pki-ca-certificate-renewals-and-ocsp.aspx

http://technet.microsoft.com/en-us/library/cc770413(WS.10).aspx

Read More...

Enable Auto Enrollment to Avoid Expiring Certificates

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. 

This user with the Autoenroll feature enabled when logged in on the CA server will get notified and the certificate will get enrolled and the Certificate won't get expired.

Read More...

The Validity Period of an Issued Certificate is Shorter than Configured

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.

If the CA Remaining duration is less than the required user certificate duration then you need to increase the CA value and renew the CA certificate as follows:

1. Configure CAPolicy.inf that directly controls CA certificate.
2. Go to C:\Windows Folder, find the file CAPolicy.inf
3. Change the "RenewalValidityPeriodUnits" value to the appropriate period (10 or 15 Years)
4. Restart the CA Service
5. Renew the CA Certificate (Right Click on the CA - All Tasks - Renew CA Certificate)

If the CA Period/Duration is fine and longer than the user certificate need then we need to check the default Validity Period in the CA Registry by doing the following:

1. Open Admin CMD on the CA server and type certutil -getreg ca                                                                                                                                                                                    
2. Check the ValidityPeriodUnits which refers to the maximum period that this CA can issue. You can define this value according to your own requirements, but it won’t exceed the lifetime of CA.
3. From the Same CMD run certutil -setreg ca\ValidityPeriodUnits 5 (This will increase the validity to 5 years)
4. Stop and restart CA service.

Now try again to Enroll certificate again from client to check the validity period.

Read More...

How to Publish New Certificate Revocation List (CRL) from Offline Root CA to Active Directory and Inetpub

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.

In order to Publish a new CRL from the offline Root CA to the Enterprise Sub CA you need to do the following:

1. Publish a new CRL on the Root CA, this can be done by Right Click the "Revoked Certificates" - All Tasks - Publish                                                                                                                                                                                                                                                          
   
                                                                                                                                                                    
2. Copy the CRL file from the Root CA located under %systemroot%\system32\certsrv\certenroll to the Sub CA Server
3. Turn off the Root CA
4. Copy the above file to the InetPub folder (HTTP Path) in the Sub CA server which is by default located under the C:\inetpub\wwwroot\Certdata
5. Open an Admin Command Prompt and run the following command to publish it to the Active Directory (LDAP Path).                                                                                           certutil -f -dspublish " C:\Inetpub\wwwroot\certdata\RootCA.crl

This process of renewing the CRL and publishing a new one is manually done since the Root CA is offline and thats why its better to make the CRL publish interval more than the default value so you won't do it frequently. You may also want to set an automated reminder before the next renewal date.

Read More...

Certificate CRL and Delta CRL are not copied automatically to the HTTP Path

A common problem noted on several implementations of Active Directory Certificate Services is the CRL and Delta CRL copies to the HTTP Path.  By default Microsoft Enterprise CA only publishes CRL automatically to LDAP path defined in the CRL Distribution Point (CDP). Normally CA administrators could define CDP in many locations as LDAP and HTTP (Inetpub Folder). Since it’s only copied to LDAP, the HTTP location gets expired and the user would encounter this error.

The certificate will try to retrieve the CRL and Delta CRL from each defined location (LDAP and HTTP) when system check the revocation status of certificate. If it can get the CRL from one and only one of these locations then it will pass the revocation process and function normally even if the CRL is not copied to the HTTP location. However it will give the above Expired Status for CRL and Delta CRL HTTP Location.

To solve this issue you have two options:

1. Copy them manually from the CERTSRV folder to the Inetpub folder
2. Create a batch file to copy them automatically and add this batch file to the daily scheduled tasks.

The Batch file should be something like this

Xcopy c:\windows\system32\certsrv\CertEnroll\*.crl  C:\Intetpub\

Read More...

UAG Direct Access IP-HTTPS fail with SAN Certificate

Lately I passed by this issue with a client trying to implement the UAG Direct Access using UCC SAN (Subject Alternative Name) Certificate. The Problem was that the Direct Access IPHTTPS URL name “da.company.com” was not the common name of the Certificate (The common name was www.company.com).  Microsoft recommends either Wildcard certificate or normal HTTPS certificate for the DA name. If you don't have other option but the SAN certificate then Its recommended to have the Common name matching the Direct Access IPHTTPS URL otherwise a manual work around should be done on both the UAG server and the UAG client.

UAG Server

The Direct Access URL should be adjusted manually on the UAG server using the Netsh command as follows:

Netsh Interface HTTPStunnel Set Interface https://da.company.com:443/IPHTTPS

Then run

Netsh Interface HTTPStunnel show interface

UAG Client

The UAG clients/OU (according to your setup) GPO need to be modifed manually to add the Direct Access URL.

Computer Configuration/Policies/Administrative Templates/Network/TCPIP Settings/IPv6 Transition Technologies/IP-HTTPS State

Make sure to update the GPO on the client (GPupdate /force) and activate the UAG configuration.

Read More...