Thursday, February 28, 2019

PKI - migration to Windows Server 2016: part 4

In this blog post, I will continue to configure my new Windows 2016 (issuing) CA server. As mentioned in the previous post, I have to adjust some permissions on certain PKI-related Active Directory objects and take care of some other matters (please see below).


***


When PKI clients validate a certificate, they must be able to access not only the certificate itself but also the other certificates in the "certificate chain" as well as the CRL (certificate revocation list) to ensure that the certificate has not been revoked. These items are published to a web share (access ed via http) and optionally to Active Directory (accessed via ldap).

Note: I will assume that the reader understands the fundamentals of PKI.

For the web share, the preferred option is to grant access to a security group and make your PKI server a member of that group. When you migrate to the new server, you simply add the new server to the security group in question. That will allow this new server to publish to the web share. I hope that is clear enough without illustrations because I did not take screenshots.

For Active Directory, we have to adjust permissions on the AIA, CDP and Enrollment Services objects in ADSIEdit at the location shown below. I'll use the AIA container as an example.

Note: the complete path is not shown so I'll point out that we are in the Configuration partition (or naming context) and at CN=Configuration,DC=yourdomain,DC=yourTopLevelDomain.

You will probably notice that despite my recommendation to grant access with security groups, I had simply granted access directly to the "old" PKI issuing CA when I originally configured my PKI: 



Note: the properties are those of the highlighted object in the CN=AIA folder.

Once again, we could grant access to a security group and then add and remove server from that group as needed, but for now, I'll just remove the old CA server and add the new one:



I repeat the process for the CDP folder (no screenshot).

Note: in this case, there was a subfolder for both the old and new CA servers. I adjusted the permissions in both places.

And also in the Enrollment Services folder:




There may be yet other modifications to make based on your particular environment.

After I made the adjustments above, I started ADCS and executed the PKI Health Check (in Windows Server 2016 we have to open the pkiview.msc console for this). There were a number of errors.

Concerning the HTTP location for the certificates and the CRL, when I set up the original PKI, I published to web share "pki" and designated all publication points by "pki" rather than a specific server name. For example (excerpt from my post-installation script):

1:file://\\pki.machlinkit.biz\PKI\%%3%%8%%9.crl"

Afterwards, I created a CNAME record in DNS that pointed to the actual server.

This was a excellent choice and facilitates the migration to another server, provided that you remember to adjust the CNAME record.

In fact, most of the errors in pkiview.msc were due to the CNAME record which I had not yet changed to designate the new CA server. It was simple matter of changing the target host name in the DNS record: 




The last error in pkiview.msc had to do with the name of the Issuing CA certificate file name:


The file name still referenced the former CA server.


Although we can usually not make changes to a certificate without invalidating it, I discovered that and could rename the file (and pkiview.msc was 100% successful then).



Sunday, February 24, 2019

PKI - migration to Windows Server 2016: Part 3

After installing the ADCS (Active Directory Certificate Services) role on our new CA server, we can restore to it the PKI elements that we backed up on the old server. These elements were presented in the first blog post of this series:
  • The CA database and private key.
  • Certain CA registry settings.
  • The CAPolicy.inf file (if there is one present) and any scripts that may have been used to configure the old server and that could be used to configure the new server with the same parameters.
  • A list of certificate templates made available on the CA in question.
In the operations presented below, I will first import the private key (as part of the ADCS configuration), add the certificate templates I want to make available to clients, then restore the certificate database and, finally, reconfigure registry settings.

Note: the CAPolicy.inf file and the list of templates are not elements that are restored, strictly speaking, but used as references that facilitate the reconfiguration of the server. Please see the details below.


***


Configure ADCS (import private key)

I start where we stopped in the previous blog post and click on the link to configure ADCS on the server:




It is necessary to have logged on with credentials that will allow the operations outlined in the screenshot below (an account that is both a local administrator on the CA server and an Active Directory Enterprise Administrator):




At this step, we select the role services to configure, which may vary by environment:




Our CA server functions in the context of a Active Directory domain so we select the option "Entreprise CA":




The previous CA server was a subordinate CA so we must make the new CA server a subordinate server as well:



The next step marks a crucial point in the configuration process. This is where we make the selection to use an existing private key, in this case associated with a certificate. These are the private key and certificate that we backed up on the old CA server and copied to the new CA server. This choice defines the rest of the configuration steps that will be different from those we would see if we were setting up a brand new server.





We need to click on "Import" to select the file containing the certificate (PKCS #12 or .p12):







Here, the certificate has been selected and we are ready to proceed:


Note: we would not select the "Allow administrator interaction..." option unless we use HSM devices. Such a scenario is beyond the scope of my presentation.



We then specify the database locations. This was my first attempt at a CA migration and I forgot to create a folder structure identical to that on the source server. However, it is apparently possible to restore to a different location.




On the "Confirmation" page, we can verify our selections and then configure the CA (which imports the certificate and associated private key of the former CA on this - the new - CA):







When I open the Certificate Authority console, I see that there are no issued certificates, which is expected since we have not yet restored the certificate database:




In "Certificate Templates", we can see the default templates that I will remove because I only want custom templates to be made available to PKI clients. This is not an absolute requirement for restoring PKI functionality. We could leave them there along with the custom templates I will add again from Active Directory.




In the screenshot below, the default templates have been removed but not deleted from Active Directory. We can add them back, if we want, along with any custom template we may have created.




Note: this is a test environment and I had only made one certificate template available: "Web Server - Certificate Request". Once I removed all the default templates, I added this one back from Active Directory (not shown in a screenshot). Once again, certificate templates are stored in Active Directory (not in the certificate database) but are made available to clients in the Certificate Template folder (accessed via different interfaces, the web interface with the URL https://pki-server/certsrv for example).



Restore CA database

We can restore the CA database from the "Certificate Authority" console by right-clicking on the CA server icon, selecting "All Tasks" in the menu and then "Restore CA":




It is necessary to stop ADCS for the restore:




We simply click "Next" on the Welcome page:




I navigate to the location where the database backup is located. We do not select the "Database" folder itself but rather the parent folder, in this case "PKI_BU". Also, I do not need to restore the private key since I already imported it in a previous step.





If all goes well, we should see this message:





So far, we have restored the certificate of the CA server, the private key and the database. We are asked if we want to start ADCS. Even though we do not have incremental backups to restore after our full backup, we will not start ADCS because we still need to adjust registry settings.





Adjust registry settings

Before we make changes to the registry, it is strongly recommended that we backup the current configuration in case something goes wrong. We will then at least have the option of starting afresh. So we go to the following branch of the registry (the path is in the screenshot below), right-click on it and select "Export" and then save it as shown here:




This is my first attempt at a CA migration and a migration from 2008 R2 to 2016 was not addressed in the sources that were available to me. I was not sure what method I should adopt and wondered what effect restoring 2008 R2 registry settings to a Windows 2016 server would have. I noticed that in the "Configuration" key, the only difference was the path for the database and log files:




The CA database was restored despite the different location (default location on the new server as opposed ot the location shown in the screenshot: C:\PKI_Database) so I think we are OK there. As for the key with the name of the CA, I realized I could probably configure the original settings by executing a post-installation script used when the CA was originally created (as opposed to restoring the entire key). So, after some edits, I executed the script to reconfigure the appropriate registry settings.



***


I have almost finished. In my next blog post, I will also present some permission adjustments to the AIA and CDP folders in Active Directory that can be found here (using my domain name in the example):

CN=Public Key Services,CN=Services,CN=Configuration,DC=machlinkit,DC=biz

This is necessary if we publish certificates and the CRL to Active Directory (if not, we can skip this step). We make the permission changes with ADSIEdit.msc. I will explain the process in more detail later but, in a nutshell, we need to grant our new CA server the permission to write to these nodes.

I will also present some errors I encountered as well as their resolution.













Monday, February 18, 2019

PKI - migration to Windows Server 2016: Part 2

Summarizing my previous blog post, I am migrating my subordinate CA (certificate authority) from Server 2008 R2 to Server 2016 and created a backup of all the elements that I need to copy, and then restore, to my new server. Once this is complete, I will remove the ADCS role (Active Directory Certificate Services) from the old server and add it to the new server. At that point, I will be able to restore the elements that were backed up on the old server.


***


Some of the data related to PKI (in an "entreprise" configuration - versus "stand-alone") is stored in Active Directory. This is the case of the certificate templates for example. If we remove the ADCS role from the old server, it is because this removes data associated with the old server such as its CN (common name). This is especially important if we intend to use the same hostname for the new server.

This point deserves clarification. We cannot change the name of the certificate authority (CA) during the migration. If the name of the CA is "Big Company Subordinate CA", that name cannot be changed. However, the new server can have a different hostname (both for the CN and the hostname part of the FQDN). If the old server was called "PKI-Server-1", the new server can be called "PKI-Server-2" or "New-PKI-Server".

In some sources (mentioned in my previous post), the same hostname is used and in others it is different. In this scenario, I will opt for a different name because I thought that you could not change the hostname (that may have been true with previous Windows server versions) and am curious to see what happens.

I will first remove ADCS from the old server and then turn it off. The process is rather simple.



Remove the ADCS role on the old CA

On the old server, I open "Server Manager" and in the "Roles" section, I click on "Remove Roles":




I click "Next" on the "Before you Begin" page...




And then uncheck the role "Active Directory Certificate Services":




We confirm the operation and click on "Remove":





I restart and after logging back on, I see that the removal of the role resumes (leading me to believe the restart is necessary):







Add the ADCS role on the new CA


Here, I assume the new server has the Windows Server 2016 OS installed (with the latest updates) and has been joined to the domain.

Although "Server Manager" has a different appearence in Server 2016, we use this same tool to install the ADCS role. Once inside "Server Manager", we click on "Manage" (in the upper right-hand corner) and then "Add Roles and Features":





We can glance at "Before you begin" which may be useful for those not at all familiar with the process:




Select "Role based or feature based installation":



And then the local server:



Note the different server name and (of course) the different IP address.


Check the role "Active Directory Certficate Services" (and confirm the installation of any additional required features):





The result should look like this (it seems that the "File and Storage Services" roles is always selected by default. You can leave it as is):




We do not need to select any additional features:





At the next step, the purpose of the ADCS role is summarized:



The role service "Certification Authority" is checked by default and I add the "CAWE" role service. This is optional and you may or may not require it in your environment:





The next couple pages appear because of my choice to install the "CAWE" role service. In the first page, we have a summary of the web server role service and in the second, a list of all the components that will be installed. We can accept the default selections there and continue.







A summary of our choices appears. I checked the "restart" option but the server did not require a restart:




Once we click "Install", the process begins and we can observe the progress:




In this case, the installation succeeded. We configure ADCS by clicking on the link shown in the screenshot below (the second red dot from top to bottom):




The configuration of ADCS will be the subject of my following blog post.

Thursday, February 14, 2019

PKI - migration to Windows Server 2016: Part 1

As Windows Server products, such as Server 2008 R2, reach end of life (EOL), we need to migrate applications to more recent OS versions. We do have the option of an in-place upgrade and this works quite well for servers running the Active Directory Certificate Services (ADCS) role. I have heard this from excellent sources and was able to perform such an upgrade myself (in a production environment) with only one significant problem: TCP/IP parameters were eliminated during the upgrade and had to be reconfigured manually. On the other hand, PKI services functioned normally after the upgrade. 

We can also migrate the certificate authority (CA) from one server to another. This is the option I will present in this blog post. In my case, I will migrate the CA from Windows Server 2008 R2 to Windows Server 2016.

The new certificate authority name must be the same on the new server as on the old server. On the other hand, the new server can have the same hostname as the old server but this is not a requirement. Some sources consulted use a new name and others retain the old name.

Concerning my sources, I've consulted several since no single source seems to apply exactly to my scenario. This Microsoft document is very complete but rather old (2013) and supposes a migration to Windows Server 2008 rather than from 2008:

Active Directory Certificate Services Migration Guide

Besides some other blogs and wikipages of varying levels of quality, I consulted the notes of a high-level course offered by "PKI Solutions":

PKI Solutions

The course notes themselves are not available online but you can take some of the courses online and (in my humble opinion) they are well worth the price. 

In the most simple terms, we have to backup a certain number of components on the old CA and then restore them on the new CA. The exact list of components to be migrated differs depending on the source in question, but most include the following:

  • The CA database and private key.
  • Certain CA registry settings.
  • The CAPolicy.inf file (if there is one present) and any scripts that may have been used to configure the old server and that could be used to configure the new server with the same parameters.
  • A list of certificate templates made available on the CA in question.

We are also supposed to publish a new CRL (certificate revocation list) for the server to be migrated (increasing the validity period if necessary). This CRL will be made available in the usual CDP (CRL Distribution Point).

Some of the documentation seems to assume we are migrating a subordinate CA (or at least makes no reference to a root CA). In this series of blog posts, I will migrate a subordinate (issuing) CA. I may or may not present the migration of a root CA in a later post.

For the most part, I will follow the steps outlined in the ADCS Migration Guide quoted above, using or referring to other sources when useful.

In this first blog post of the series, I'll backup the items above and in the following blog posts, we'll see how to restore them on the new CA and then ensure that all the necessary certificate services are functional.


***


Backing up the CA database and private key

The CA database (and private key) can be backed up with certutil using these two commands:

certutil -backup C:\BackupFolder
certutil -backupkey C:\BackupFolder

For example:



We can also backup the CA database and private key using the Certificate Authority console.

Note: I will assume the reader knows how to create and add components to a Microsoft management console (mmc) and then access the appropriate component.


So we right-click on the CA, click on "All Tasks" and then "Back up CA":





We follow the prompts, clicking "Next" as needed:





Check both options (and note that the target folder for the backup must be empty):





Since we are exporting the private key, we must protect the file with a password:



Note: password protected or not, the private key should be stored in a folder that only autorized users can access. 


We then complete the wizard:




Both backup methods produce a folder named "Database" and a .p12 file containing the private key:






Exporting CA registry settings

Some sources use the term "backing up" the registry settings and others the term "exporting". In practice, it is essentially the same thing. What registry key (or folder) should be exported? The sources I consulted differ on this point. Some designate the Certsvc key or the Configuration folder and at least one only has us target the folder with the name of the CA.  

After some research, I opted to take a screenshot of the parameters in Configuration key and then export the key with the name of the CA.

So a screenshot of this...




And an export of this (right-click and then "Export" in the menu):




We have to select a location to save the exported registry key:




Otherwise, we have the option of using the command line here as well:

reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration C:\PKI_MGR\RegSettingsExport.reg




Creating a copy of the CAPolicy.inf file

You may or may not have used a CAPolicy.inf file when building your CA. If you have, the file should be located in the %SystemRoot% directory which is C:\Windows on most servers. The file contains a list of parameters and values. I show one example in the screenshot below. In any event, it is simple matter of copying this file to the folder or media we are using to store the other components that will be migrated to the new CA.





Creating a list of available certificate templates

By available certificate templates, I mean the templates among which users can choose when they request a certificate from a particular issuing CA. This may differ from CA to CA and we would typically want to ensure that the same templates remain available on the new CA after migration. As for most of the other components, we have two options here: a command line option and a GUI option.

At the command line, we can export the list of templates to a text file with certutil:

certutil -catemplates > C:\SomeFolder\catemplates.txt

For example:




The command line option is useful if we have many templates. If there are only a few, we could simply take a screenshot of the available certificate templates:







Issuing a CRL

(Optionally with an extended validity period)

PKI clients (users or computers) must be able to consult a valid CRL or certificate validation will fail. In particular, the CRL must not have expired. In my case, the "CRL publication interval" is 3 days. After 3 days, the CA must publish a new CRL (even if there are no changes to the list) and clients validating certificates must be able to access this list in a CDP (CRL distribution point). So, in the screenshot below, we see that the next update is for 2/16/2019 (at 5:10 PM). This is important. If we dismantle our current CA and the new CA is not yet in place on 2/16/2019, a new CRL will not be published and certificate validation will fail.





There is a small detail that may allow us to gain some time. If we look at the health of our PKI in Server Manager (as shown in the screenshot below), we may observe what appears to be a discrepancy. The expiration date is 2/18/2019 rather than 2/16/2019.




Note: and yes, the screenshots were taken at the same time, give or take a couple minutes.


This analysis of our PKI health takes into consideration a sort of "grace period" that we may or may not have configured for the CRL. In my case, this grace period was configured with a post-installation script as shown below:




Only an excerpt of the complete script is shown but enough to illustrate what I want to explain concerning the effective CRL validity period. So, as already mentioned, the validity period  for the CRL is measured in days with 3 days as the unit (indicated by the red dot). Those are the first two lines in the "Define CRL Publication Intervals" section. A delta CRL is not necessary in most cases and I do not use one. Therefore, we can ignore the next two lines. The last two lines define CRL overlap which is essentially the "grace period" that I mentioned earlier. Even if the current CRL expires (after 3 days) without the publication of a new CRL, we have an additional 2 days to resolve the problem before certificate validation will start to fail. Please note the the overlap (or grace period) cannot exceed the publication interval.

If we think our migration could possibly exceed the CRL validity period (with or without overlap), we have the option of publishing a CRL with an extended validity period.

Note: with or without the extension, it makes sense to publish a fresh CRL (as shown below) just before we begin the migration. Otherwise, we could be dismantling the CA just before the CRL is about to expire and would have no way to publish a new CRL until the new CA is in place.

How do we extend the validity period? In the certificate authority managment console, we click on the icon representing the CA and right-click on the "Revoked Certificates" folder, selecting the option "Properties" which takes us to this screen (screenshot below) where we can increase the publication interval:



We then must publish the CRL with the extended validity period. After clicking on "OK" above (not shown in the screenshot), we return to the "Revoked Certificates" folder on which we right-click once again but selecting "All Tasks" and "Publish" this time:




We click on "OK" to publish:




Now the next update will take place on 2/20/2019 rather than 2/16/2019:




That gives us 4 more days to complete the migration.

This increase is also visible in the PKI health check:




***


Now that all the elements to migrate have been backed up, exported or otherwise recorded, we can copy these elements to another location (possibly the server that will become the new CA server if it is already available) and begin to dismantle the current CA. That will be the subject of my next blog post.