Sorry for being absence from the blog right now. A lot of time consuming stuff is happening at work right now, but I will better myself, I promise!

A very common problem I see regarding ADCS and PKI is that many structures “survive them self” and are used for purposes that they were not initially designed for.

Some problems that I run in to are that people initially install an classic “next-next-finish” Enterprise Root “just to issue some internal SSL certificates” and after two or three years, the CA has got Sub-CA’s for other Issuing or NAP CA’s and suddenly we have requirements of publically available CRL’s for IP-HTTPS in DirectAccess, or even worse, external parties are trusting this structure for their usage or Sub-CA!

So I thought that is a good idea to “lock down” a PKI to the intended purpose of what the structure was actually designed for.

This can very, very easily be done by using (creating) the %WINDIR%\CAPolicy.inf before your install your Enterprise Root.

The following CAPolicy.inf is an example of a PKI lockdown for an internal Enterprise Root:

[Version]
Signature=”$Windows NT$”

[PolicyStatementExtension]
Policies=InternalUseOnly

[InternalUseOnly]
OID=2.5.29.32.0
Notice=”This PKI is intended for internal use only.”

[BasicConstraintsExtension]
PathLength=0
Critical=Yes

[Certsrv_Server]
LoadDefaultTemplates=False

So what does all this text mean? Well, the PolicyStatementExtension section defines the associated policies with the CA. We specify a policy that we call “InternalUseOnly”. First when I tested this, the ADCS wizard did not parse the content of that section if didn’t had and OID (I just wanted the populate the User Notice field).

A quick phone call to my dear friend and mentor Hasain Alshakarti @ http://www.secadmins.com confirmed the conclusion that I already had come to. A OID MUST be specified. But since a Root CA have the “All Issuance Policy” by default, Hasain came up with the clever idea that we can simply walk around that problem by simply specifying that OID for our policy.

The BasicConstraintsExtension is a very powerful section and by specifying PathLength we can specify how many levels of CA’s we allow underneath the root. A very common configuration that I usually do when I design/implement two tiers is that I have a PathLength=1 on the Root CA and a PathLength=0 on the Issuing CA.

The LoadDefaultTemplates part tells the ADCS setup wizard to NOT populate the default list of certificates in the certificateTemplates attribute in the pKIEnrollmentService object in Enrollment Services under Public Key Services that exists in the Configuration partition in Active Directory. By doing this, we do not enroll any certificates “by accident” and we can ourselves choose the exact templates we want to use on our CA.

Here are some screenshots!

We can clearly see that our critical extension PathLength does not allow any Subordinay CA’s.

We can also see that our notice text is associated with the All Issuance Policy.

// Fredrik “DXter” Jonsson

No related posts.

I want to start with a little disclaimer: The real credits for this tool does not really belong to me. This tool is using the really wonderful PSPKI PowerShell module from http://pspki.codeplex.com/ and all credits should go them for making this wonderful piece of work public. I just format the output that those cmd-lets provide into a HTML based report.

A very common problem people have with certificates is that they realize that it’s time to renew their certificates… after they have expired!

To be able to get a web based report of the certificates in an ADCS CA that is about to expire within 30 days, I wrote this small script today on the train on my way to work. It accepts two switches, –computername of the CA (which defaults to local computer if not specified) and –reportfile (defaults to a HTML-file on the current users desktop).

The script can be run locally on the CA if desired.

This opens up the report.

The report contains all certificates that are expiring within 30 days. This can be edited in the script.

I want to thank a small group of people for their input during the day.

Ludwig “Ludde” Nilsson = for cosmetic input regarding the HTML report.

Stefan Schörling = for his support, thoughts and feedback during the development of this script.

Kerim Sidia = for validation of “intelligent” design.

Niklas Goude = for his clever idea regarding detection of the PSPKI module.

Hasain Alshakarti = for a good note about that the filtering is client based (very large ADCS databases will take longer time to process).

Please note that this is a simple proof of concept and is not done or complete in any way. I will continue to work on this and include many more switches, etc.… but I wanted to show you guys already now what can be done if people share their knowledge and work together.

The code to the script is embedded below.

PKI and ADCS is fun, so go out and play!

// Fredrik “DXter” Jonsson

#ADCS Certificate Expiration Report Tool
#Made by Fredrik “DXter” Jonsson (dxter@poweradmin.se) 2011-08-09
#http://www.poweradmin.se

#Get input strings
param(
  [string] $computername = “$ENV:COMPUTERNAME”,
  [string] $reportfile = “$ENV:USERPROFILE\Desktop\acert_certificate_expiration_report.html”
   )

#Start stopwatch
$totalTime = New-Object -TypeName System.Diagnostics.Stopwatch
$totalTime.Start()

#Credits
Write-Host
Write-Host “ADCS Certificate Expiration Report Tool ” -ForegroundColor “Yellow”
Write-Host “by Fredrik “”DXter”" Jonsson (dxter@poweradmin.se)” -ForegroundColor “Yellow”
Write-Host

if(Get-Module -ListAvailable -Name PKI | Where-Object { $_.name -eq “PKI” })
{
#Import PSPKI PowerShell module
if(Get-Module -Name PKI | Where-Object { $_.name -eq “PKI” })
{
Write-Host “PSPKI PowerShell module already imported…” -ForegroundColor “Yellow”
}
else
{
Write-Host “Importing PSPKI PowerShell module…” -ForegroundColor “Yellow”
Import-Module -Name PKI
}
Write-Host

#Set variables
Write-Host “Setting variables…” -ForegroundColor “Yellow”
Write-Host
$caname = $computername.ToLower()
$domaindns = $ENV:USERDNSDOMAIN.ToLower()
$todaysdate = Get-Date
$findaldate = $todaysdate.AddMonths(1)
$htmlpre = “<P>Generated by user: $ENV:USERNAME</P><P>The following certificates expire before $findaldate</P>”
$htmlpost = “<P>Certificate expiration information retrived from $caname.$domaindns</P>”
$htmltitle = “Certificate expiration information from $caname.$domaindns”
$htmlinput = Get-CertificationAuthority “$caname.$domaindns” | Get-IssuedRequest -Filter “NotAfter -ge $(Get-Date)”, “NotAfter -le $((Get-Date).AddMonths(1))”

#Generate report
Write-Host “Generating report…” -ForegroundColor “Yellow”
Write-Host
$htmlinput | ConvertTo-Html -Body (Get-Date) “Report date:” -Property RequestID,RequesterName,CommonName,NotBefore,NotAfter,SerialNumber -Pre $htmlpre -Post $htmlpost -Title $htmltitle | Out-File -FilePath $reportfile

#Open report
Write-Host “Opening report…” -ForegroundColor “Yellow”
Write-Host
Invoke-Item $reportfile

#Warning if PSPKI is not installed
}
else
{
Write-Host “PSPKI is not installed. Please install it from http://pspki.codeplex.com/ ” -ForegroundColor “Yellow”
Write-Host
}

#Stop stopwatch
$totalTime.Stop()
$ts = $totalTime.Elapsed
$totalTime = [system.String]::Format(“{0:00}:{1:00}:{2:00}”,$ts.Hours, $ts.Minutes, $ts.Seconds)
Write-Host “Process total time: $totalTime” -ForegroundColor Yellow
Write-Host

No related posts.

Yesterday myself, Hasain Alshakarti and Göran Melvås (all three of us are members of Swedish Windows Security User Group) had a live session at Microsoft Sweden about Forefront Identity Manager Certificate Management 2010 (FIM-CM 2010).

I wanted to thank all you guys that attended our three hour long session about ADCS, PKI, smartcards, readers and everything related inside and outside FIM-CM in real life. And it was really fun to meet some of you guys from ITProffs as well!

Our presentation and our “how-to-automatically-install-and-configure-adcs-in-7-seconds” PowerShell script will be available on Hasain’s blog on http://secadmins.com. The recording for yesterday will show up there as well (including the demo we didn’t have time for to complete)

Some of you guys may thought that I joked, but I am serious about my challenge! If any of you guys can beat my record and install ADCS in less than 7 seconds, I buy you lunch! It’s a promise!

Here are some pictures from yesterday. The thanks for the pictures goes to my colleague and friend Per “Nimmsis” Sjökvist.

Myself and Göran Melvås on stage.

All three of us live on stage.

// Fredrik “DXter” Jonsson

No related posts.

A question that I get all the time, is how to issue internal Extended Validation certificates from an internal Enterprise CA. Even though EV certificates do not provide increased security from a technical point of view, sometimes people just want them for the green address bar.

So to help all you guys out there that wants to issue EV SSL certificates from your internal CA, here is a complete step by step! To simplify stuff, here in my example I will use an Enterprise Root CA running on Windows Server 2008 R2.

First, I start by duplicating a certificate template and since I only need the server authentication EKU in the certificate and that I also need to supply information regarding CN/SAN/etc. during the enrollment, I duplicate the Web Server template and make it a V3 (CNG/2008) template (however, this template can be a V2 template if desired).

We create a new V3 template from our V1 Web Server template by duplicating it.

First we configure the name of the template and the validity period.

Then we need to edit the Issuance Policies of the certificate.

We create a completely new Issuance Policy. Now, a unique OID is being generated. Copy this OID, it is very important! (The CPS location URI is optional.)

Then we bind the newly created Issuance Policy with this certificate template.

Now the certificate template is associated with our newly created Issuance Policy.

We also verify that a computer account (or a security group of computers) has enroll rights on this template.

Now we are done with the template configuration. Now we just bind the template to the Enterprise CA just as usual. Just right click on Certificate Templates in ADCS and choose “New" > "Certificate Template to Issue” and select our new template and press OK.

Next we need to tell our domain members that the OID that was generated in our issuance policy and comes from our Enterprise CA is trusted for EV certificates and results in a green address bar.

First, we create a new group policy object. Of course, if you have an existing GPO for other domain wide PKI configurations like to enable auto enrollment, etc. you can just update your existing GPO with these settings.

We add the public root certificate of our Enterprise Root to the “Trusted Root Certification Authorities” in Public Key Policies.

We right click on the root certificate and choose properties. Then we go to the Extended Validation tab and add that exact OID that we copied from the Issuance Policy.

We apply the settings and link it to the domain. After that is done, the group policy processing on all domain members will make all machines to be aware of the new OID.

Lets try to issue a EV certificate now!

To do this we use the MMC snap-in for the certificate management for the computer account, which is (according to me), the easiest way to handle the request of a certificate on a domain member (at least when you supply information the request your self).

Since we gave the computer rights to enroll the certificate in the security settings in the template, we see the template as available for enrollment. We will click “configure settings” to supply all information in the request before we send it to the CA (which is the default setting in the Web Server template which we duplicated).

We supply some information in the request and press OK.

We select our configured template and click enroll.

Then the certificate request is being sent to the CA which signs the request and sends it back to the client which binds the certificate to the private key and the certificate ends up in the local machine personal certificate store.

If we take a look at the certificate, we can see that it has the OID for our new Issuance Policy (which translates to the name of the Issuance Policy when we look at the certificate).

And an even closer look shows that the certificate also holds all the attributes in the subject field that we chose to submit.

Now we bind the certificate to a internal website in IIS.

Lets try it out from an other machine to see if it works (you can not try this on the webserver itself, it will be valid but not green)!

It works like a charm!

// Fredrik “DXter” Jonsson

No related posts.

Not many people are not aware of the fact that enabling SAN attributes in certificate requests can be a security issue. I have seen many people on different forums that tell other people to enable EDITF_ATTRIBUTESUBJECTALTNAME2 with certutil on Enterprise CA’s to be able to request and issue web server certificates containing SAN-certificates.

This is not true! SAN attributes can be specified using certificate extensions in the MMC and should be done that way instead of attributes in the request!

The problem is, if this is enabled, that a a user can supply any SAN attribute in it’s certificate request and if the certificate is enrolled without any certificate manager approval, the user can issue the certificate to itself and the certificate may contain any SAN attribute, making an impersonation attack possible.

More info can be found on: http://technet.microsoft.com/en-us/library/ff625722(WS.10).aspx

// Fredrik “DXter” Jonsson

No related posts.

Not many people are aware of a certain available option in CAPolicy.inf that came with Windows Server 2003 SP1. The LoadDefaultTemplates is very useful since it prevents the CA to associate itself with the default list of certificate templates when we are installation an Enterprise CA.

The cool stuff is that this parameter was ignored on Enterprise Issuing CA’s in Windows Server 2003 SP1. Only Enterprise Root’s in Windows Server 2003 SP1 could use this option. However, this changed in Windows Server 2008 and later. This option can now be used on any Enterprise CA in the hierarchy.

What happens in reality is that the ADCS wizard does create the certificate templates in the Certificate Templates container in Public Key Services just as usual, but it does NOT assign any certificate templates to the CA.

This can be verified by either open the ADCS console and look at Certificate Templates or open the CA’s pKIEnrollmentService object in the Enrollment Services container in Public Key Services with adsiedit.msc (look at the data in the certificateTemplates attribute, it should be <not set>).

I personally think that this should be a standard on every Enterprise CA that gets installed, since we can guarantee that no certificate is being issued by “accident”. In other words, we do not issue certificates before we manually assign them to the CA, meaning that we can use all the time we need to configure ADCS in our own pace.

If you want to enable this “hidden” feature in the ADCS installation wizard, apply the following (minimum) content to your %WINDIR%\CAPolicy.inf file:

[Certsrv_Server]
LoadDefaultTemplates = False

// Fredrik “DXter” Jonsson

No related posts.

At this TechDays 2011 here in Sweden, I got a question when I was standing in the Swedish Windows Security User Group booth about if there was some easy way to determine if the Microsoft Base CSP (KB909520) is installed on a machine or not. My instant answer was to try to run pintool.exe since it is a PIN management utility that comes with the Base CSP.

However, in Windows Vista and above, even if the Base CSP is included by default, pintool.exe isn’t. This is because this functionality has been merged into the Windows logon screen that is native in Windows.

Just for fun, and because of my unusual big amount of spare time a few days ago, I wrote this very small PowerShell script to check if Base CSP is installed on a local or remote machine. The script is doing this regardless if the target computer is running a pre or post Windows Vista operating system, since the script is simply checking if the dll for Base CSP is installed in Windows or not.

The reason I am not using the Get-HotFix cmd-let that is native in PowerShell is that Base CSP is not available as an hotfix for Vista and later since it is already included. Therefor, it will not show up as an installed hotfix.

The reason that I am checking for that file and not the Gemalto .NET mini driver (that is also a part of KB909520) is that the axaltocm.dll mini driver for the Gemalto .NET cards might be installed, but not always. In Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008, it is installed by default with the Base CSP. But it is not installed be default in Windows 7 and Windows Server 2008 R2!

This is because the mini drivers for smartcards are dynamically installed when needed from Windows Update through the smartcard plug and play feature in Windows 7 and Windows Server 2008 R2. (You have to enable it on 2008 R2. It is disabled by default for security reasons.)

The script relies on two quite basic components, remote access to the C$ share of the computer and that it is responding to ping to be able to check if the machine is available on the network or not. If you don’t like this, simply remove that part from the code.

If no input for the computer parameter is given, the script will default on localhost.

Here we try to check the computer SRV0042. It is not responding to ping and is assumed to be offline.

If you need to distribute the Base CSP through WSUS, I wrote a blog post about for a year ago: http://poweradmin.se/blog/2010/01/15/distributing-the-base-csp-for-windows-xp-with-wsus/

My dear friend Hasain tipped me about the following one liner to list all installed CSP’s in Windows with PowerShell. Sometimes the coolest things are both short, easy and brilliant, even if you don’t think about them.

Get-ChildItem HKLM:\SOFTWARE\Microsoft\Cryptography\Defaults\Provider | Format-List

The script can be found below. Enjoy!

// Fredrik “DXter” Jonsson

#Get input strings
param(
  [string] $computer = "localhost"
   )
.$ENV:SystemRoot\System32\ping.exe -n 1 $computer | Out-Null
if ($? -eq $True)
{
if (Test-Path -Path "\\$computer\C$\Windows\System32\basecsp.dll")
{
    Write-Host
    Write-Host "Microsoft Base CSP is installed on $computer!" -ForegroundColor Green
    Write-Host
}
else
{
    Write-Host
    Write-Host "Microsoft Base CSP is not installed on $computer!" -ForegroundColor Red
    Write-Host
}
}
else
{
    Write-Host
    Write-Host "$computer is not available!" -ForegroundColor Red
    Write-Host
}

No related posts.

Yesterday I saw it again – a Windows Server 2003 Root CA that was installed with NO CAPolicy.inf file!

Apparently, not everybody are aware about how Certificate Services works regarding the creation of the certificate that is being generated in the Certificate Services wizard, so lets go through it one more time.

The CAPolicy.inf file is a very important file that configures and sets the default values for the ADCS configuration and certificate. But when you are installing a Root CA on Windows Server 2003 (or Windows 2000), there is a issue if you have no CAPolicy.inf file in the %WINDIR% directory. If you have no CAPolicy.inf file the root certificate will have both CDP and AIA extensions in the root certificate itself!

This behavior (you may call it a bug) can be a problem I many cases. One of the issues that I have encountered several times is when you have strong CRL checking enabled and your clients MUST validate all CDP extensions that are available in the certificate chain! I have decommissioned many PKI structures because the person who installed the CA had no idea about what he or she was doing when the Root CA was installed!

A CAPolicy.inf file on a Windows Server 2003 should (at least) contain the following settings to exclude the CDP and AIA extensions before the root certificate gets created by the certificate services wizard :

[CRLDistributionPoint]
Empty=True

[AuthorityInformationAccess]
Empty=True

Now you might ask; Shouldn’t a root certificate contain CDP and AIA extensions? NO!

A root certificate is self signed. Therefor there is no other CA above in the hierarchy that can validate the identity and integrity of the certificate. That’s why we should have no CDP attribute in the root certificate itself!

How about the AIA extension then? Well, the AIA extension is used to easily distribute the trust of the structure by providing a URL to the CA’s above in the chain that has issued the certificate. However, since the root certificate itself is the trust for the structure, there is no other certificate that can be populated into the AIA extension since you apparently already have the root certificate itself.

This behavior was fixed in Windows Server 2008 and above. Root CA’s that are created on Windows Server 2008 or 2008 R2 do not require a CAPolicy.inf file to be able to remove these extensions from the certificate – they are not included by default!

However, my favorite Root CA’s certificates are generated by ADCS in Windows Server 2008 R2 since their key usage is flagged as critical by default.

// Fredrik “DXter” Jonsson

No related posts.

Last night, I did a quite fun test. I tested ADCS in 2008 R2 from a compatibility view. I installed a Windows 2000 mixed mode domain (schema version 13) and installed an Enterprise Root on a domain member running Windows 2008 R2 without adprep or anything.

The ADCS installation itself completed with one error.

The CA could not populate the Certificate Templates container with its templates. “No worries” was my immediate thought, so I opened up certutil and tried to recreate the templates manually, hardcore style.

Certutil could not do that.

But I immediately remember that the Windows 2003 schema extended the Active Directory schema with the attributes ms-PKI-Cert-Template-OID, ms-PKI-Template-Minor-Revision and ms-PKI-Template-Schema-Version (and the class ms-PKI-Enterprise-Oid). These extensions are used by certificate templates so I had to extend my schema to at least Windows Server 2003 (schema version 30).

Said and done, I ran adprep /forestprep from a Windows Server 2003 CD.

After I had done that, I could immediately recreate my certificate templates in Active Directory with certutil from the CA-server!

I ran the exact same command again, after I had extended the schema, and this time it worked!

Everything I tested regarding enrollment of certificates (including V3 templates) and everything just worked fine as usual!

All templates are populated in the Certificate Templates container, inclusive the OCSP Response Signing template, which is an V3 template.

So what did we learn after this? Well…

* You can, without any problem, run an 2008 R2 Enterprise CA without the need of any 2003/2008/2008 R2 DC’s.

* ADCS is not dependent on any forest or domain functional level, regardless of which role service we want to use.

* The most significant changes in ADDS (for ADCS) did Windows Server 2003 which introduced 19 new attributes and three new classes for ADCS.

* You don’t need to run adprep for 2008/2008 R2 to be able to run 2008/2008 R2 Enterprise CA’s.

* 37 of the 43 attributes for ADCS exists in the 2003 schema. Three new ones came with Windows Server 2008 and three more came with Windows Server 200 8R2.

* ADDS has, since Windows 2000, only had tree new classes in the schema that are related to ADCS and these came with Windows Server 2003.

* Credential Roaming requires 2008 schema (it depends on the three new attributes that Windows Server 2008 extended the schema with for ADCS).

* ADCS Certificate Enrollment Web Services requires 2008 R2 schema.

* If ADDS can handle V2 templates, it can also handle V3 templates.

Even if you don’t need 2008 R2 DC’s from a strict ADCS perspective, I strongly recommend them anyway! But always remember to keep your forest prepared for at least the same OS as your CA’s and you won’t need to read and remember blog posts like this one.

// Fredrik “DXter” Jonsson

No related posts.

Last week, I discussed with dear pal Stefan Schörling at http://www.msfaq.se/ regarding some questions about how to do a complete backup and restore of an Enterprise CA in a disaster recovery scenario without using a full machine backup. In other words, how to do a complete backup of only ADCS itself, not the entire operating system. After we were done, Stefan said “well, that wasn’t so difficult”.

The following morning on the train on my way to work, I thought about Stefan’s comment while doing some PowerShell scripting for ADCS. My conclusion from the previous evenings discussion and Stefan’s comments was very simple: backup for ADCS shouldn’t be difficult!

Now, why is backup of ADCS different from backup up a system state backup on server X? Well, three problems with system state backups and ADCS are that a system state backups relatively huge, are quite time consuming and does NOT take everything! Not many people are aware of the fact that system state backups does not backup the private key of the CA if you are running it on 2008/2008R2 (and you should)!

Even if I did write a very popular post about backup and restore for Active Directory Certificate Services last year, I understood after mine and Stefan’s conversation that the issue had not been clarified to the “big mass of non ADCS geeks”.

ADCS is very different from many other servers or services in our corporate network. It is a critical service from a security and identity perspective since possession of the private keys of an Enterprise CA gives us possibilities to impersonate any user or computer in our forest.

Another thing that is quite special with ADCS is that it’s data and configuration is shattered among many different locations both inside and outside the CA:

* You have the CAPolicy.inf in the local %WINDIR% directory which controls the creation and renewal of the CA’s CSR’s, certificates and keys for the CA itself.

* The CA’s certificates are stored in the computers certificate store. Private keys are sometimes stored locally in %systemdrive%\ProgramData\Microsoft\Crypto\Keys and sometimes (and preferably) in an external HSM.

* The ADCS database and it’s log files contains all information about your requests and your issued and revoked certificates (and may contain private keys if you have key archival enabled). Please remember that the ADCS database holds all the information required that ADCS needs to populate into the CRL’s.

* ADCS stores it’s configuration about the CA, such as CDP/AIA/OCSP/etc. locally in the CA’s registry.

* Furthermore, for Enterprise CA’s, we have multiple objects in the Public Key Services container in Active Directory that holds trusts, certificate templates and configuration.

Since all this is quite confusing for a “non ADCS geek” at the first peek, I decided to simply the process of doing complete ADCS backups without doing full machine backups.

I started to write on my ADCS Backup Tool which does a complete backup of the CA’s certificate + private key, database + log files, CAPolicy.inf file and all ADCS configuration that is stored in the registry.

It is a small PowerShell script that just needs two switches to backup the CA. –backupdir and –pfxpassword, both switches are quite self explaining.

The script is creating a backup folder if needed and backup up all data to it. As you might see, I included some “PowerShell Bling” like Write-Progress, etc.

However, if the backup folder is existing, the script will not try to create that one.

I also included a simple counter to keep track of the backup time.

I would like to give my thanks to three people who helped me with this tool.

First of all, I would like to thank my dear, old pal Mattias Åslund at GraFu for his excellency in application development! You have amazing eyes and ideas my friend, but I am sorry, I can’t implement everything that you suggest, even if it is good stuff…

Then I want thank our intern @ work, Fredrik “Le Mumin” Holmström for his very cleaver ideas regarding error code management and that he helped me to implement them!

Last, but not least, I would like to thank my dear friend, and soon colleague, Per “Nimmsis” Sjökvist that beta tested the script and immediately discovered the “pfxpassword bug” in my code.

Thank you guys!

The script can be found below!

// Fredrik “DXter” Jonsson

#ADCS Backup Tool
#Made by Fredrik "DXter" Jonsson (dxter@poweradmin.se) 2011-03-31
#http://www.poweradmin.se

#Get input strings
param(
  [string]$backupdir=$(throw "Mandatory parameter -backupdir missing, for example ""C:\Backup"""),
  [string]$pfxpassword=$(throw "Mandatory parameter -pfxpassword missing, for example ""secretpassword""")
)

#Start stopwatch
$totalTime = New-Object -TypeName System.Diagnostics.Stopwatch
$totalTime.Start()

#Set variables
$CAPOLICY = "$ENV:SystemRoot\CAPolicy.inf"
$CERTUTIL = "$ENV:SystemRoot\System32\certutil.exe"
$REG = "$ENV:SystemRoot\System32\reg.exe"
$REGFILE= "adcs_registry_backup.reg"

#Credits
Write-Host
Write-Host "ADCS Backup Tool" -ForegroundColor "Yellow"
Write-Host "by Fredrik ""DXter"" Jonsson (dxter@poweradmin.se)" -ForegroundColor "Yellow"
Write-Host

#Function to backup CA
function Backup-ADCS
{
if (Test-Path –Path $BACKUPDIR)
{
    Write-Progress -Activity "ADCS Backup Tool" -Status "Backup directory $BACKUPDIR exists!" -PercentComplete 10
    Write-Host "Backup directory $BACKUPDIR exists!" -ForegroundColor Yellow
    Start-Sleep -Seconds 1
    Write-Host
}
else
{
    Write-Host "Creating backup directory $BACKUPDIR!" -ForegroundColor Yellow
    New-Item -Path $BACKUPDIR -ItemType Directory
if ($? -eq $true)
{
    Write-Host "Backup directory $BACKUPDIR created!" -ForegroundColor Yellow
}
else
{
    Write-Host "Backup directory $BACKUPDIR failed to create!" -ForegroundColor Yellow
}
    Write-Host
}

#Verify certutil installation
Test-Path $CERTUTIL
if (Test-Path –Path $CERTUTIL)
{
    Write-Progress -Activity "ADCS Backup Tool" -Status "Backing up ADCS private key + certificate!" -PercentComplete 20
    Write-Host "Backing up ADCS private key + certificate!" -ForegroundColor Yellow
    Start-Sleep -Seconds 1
    .$CERTUTIL -f -backupKey -p $PFXPASSWORD $BACKUPDIR
if ($? -eq $true)
{
    Write-Progress -Activity "ADCS Backup Tool" -Status "ADCS private key + certificate backed up!" -PercentComplete 30
    Write-Host "ADCS private key + certificate backed up!" -ForegroundColor Yellow
}
else
{
    Write-Host "ADCS private key + certificate not backed up!" -ForegroundColor Red
}
    Start-Sleep -Seconds 1
    Write-Host
    Write-Progress -Activity "ADCS Backup Tool" -Status "Backing up ADCS database + log files!" -PercentComplete 40
    Write-Host "Backing up ADCS database + log files!" -ForegroundColor Yellow
    Start-Sleep -Seconds 1
    .$CERTUTIL -f -backupDB $BACKUPDIR KeepLog
if ($? -eq $true)
{
    Write-Progress -Activity "ADCS Backup Tool" -Status "ADCS database + log files backed up!" -PercentComplete 50
    Write-Host "ADCS database + log files backed up!" -ForegroundColor Yellow
}
else
{
    Write-Host "ADCS database + log files not backed up!" -ForegroundColor Red
}
    Start-Sleep -Seconds 1
    Write-Host
}
else
{
    Write-Host "Certutil not installed!" -ForegroundColor Red
    Write-Host
}

#Copy CAPolicy.inf
if (Test-Path –Path $CAPOLICY)
{
    Write-Progress -Activity "ADCS Backup Tool" -Status "Backing up CAPolicy.inf" -PercentComplete 60
    Write-Host "Backing up CAPolicy.inf!" -ForegroundColor Yellow
    Start-Sleep -Seconds 1
    Copy-Item $CAPOLICY -Destination $BACKUPDIR\CAPolicy.inf -Force
if ($? -eq $true)
{
    Write-Progress -Activity "ADCS Backup Tool" -Status "CAPolicy.inf backed up!" -PercentComplete 70
    Write-Host "CAPolicy.inf backed up!" -ForegroundColor Yellow
}
else
{
    Write-Host "CAPolicy.inf not backed up!" -ForegroundColor Red
}
    Start-Sleep -Seconds 1
    Write-Host
}
else
{
    Write-Host "CAPolicy.inf does not exist. Skipping!" -ForegroundColor Yellow
    Write-Host
}

#Export registry
if (Test-Path –Path $REG,HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration)
{
    Write-Progress -Activity "ADCS Backup Tool" -Status "Backing up ADCS configuration from registry!" -PercentComplete 80
    Write-Host "Backing up ADCS configuration from registry!" -ForegroundColor Yellow
    Start-Sleep -Seconds 1
    .$REG export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration $BACKUPDIR\$REGFILE /y
if ($? -eq $true)
{
    Write-Progress -Activity "ADCS configuration exported from registry!" -Status "ADCS configuration exported from registry!" -PercentComplete 90
    Write-Host "ADCS configuration exported from registry!" -ForegroundColor Yellow
}
else
{
    Write-Host "ADCS configuration not exported from registry!" -ForegroundColor Red
}
    Start-Sleep -Seconds 1
    Write-Host
}
else
{
    Write-Host "ADCS configuration not existent!" -ForegroundColor Red
    Write-Host
}
}

#Run backup
Backup-ADCS | Out-Null
if ($? -eq $true)
{
    Write-Progress -Activity "ADCS Backup Tool" -Status "CA backup completed successfully!" -PercentComplete 100
    Write-Host "ADCS backup completed successfully!" -ForegroundColor Yellow
    Start-Sleep -Seconds 1
    Write-Host
}
else
{
    Write-Host "ADCS backup not completed successfully!" -ForegroundColor Red
    Write-Host
}

#Stop stopwatch
$totalTime.Stop()
$ts = $totalTime.Elapsed
$totalTime = [system.String]::Format("{0:00}:{1:00}:{2:00}",$ts.Hours, $ts.Minutes, $ts.Seconds)
Write-Host "Process total time: $totalTime" -ForegroundColor Yellow
Write-Host

No related posts.