Zoho Banner September 2011

Archive for the ‘Certificate Authority’ Category

I had an interesting one recently when submitting a certificate request to a Windows Certificate Authority using certreq.exe.  The error that came back was:

The disposition message is “Error Parsing Request The request subject name is invalid or too long. 0×80094001 (-2146877439)”

I found several links to possible solutions but, as it turns out, the problem in my case was the subject name (specified an X.500 DistinguishedName) was too long.  It seems that the CA limits the subject name field to 64 characters.  Mine was around 80 characters, which is not unusual for a DN.

The workaround is to remove the 64 character limit by running the following command:

certutil -setreg ca\EnforceX500NameLengths 0

The CA service needs to be restarted after running the command.

The Microsoft TechNet article that provides more detail can be found here.

Here’s something I put together to handle bulk certificate requests for submission to an Enterprise CA using certreq.exe.  Enjoy!

#########################################################
#
# Name: Request-Certificates.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 4/12/2012
# Comment: PowerShell script to submit certificate 
# requests in bulk using certreq.exe
#
#########################################################

# Specify the location of the request files
$csrdir = "C:\Certs\Requests\"
###

$files = Get-ChildItem $csrdir
$csrs = $files | ? {$_.extension -eq ".csr"}

# Parameters
$template = "WebServer" # must always use concatenated name format
$CA = "MyCAServer.mydomain.com\MyCAName"

foreach ($csr in $csrs)
{
    write-host "Requesting certificate $csr ..."
    $basename = $csr.basename
    # Specify the command line parameters for certreq.exe
    $parameters = "-config $CA -submit -attrib CertificateTemplate:$template " `
    + "$csrdir" + "$basename" + ".csr " +  "$csrdir" + "$basename" + ".cer " `
    +  "$csrdir" + "$basename" + ".p7b"
    # Start certreq.exe and pass in the parameters
    $request = [System.Diagnostics.Process]::Start( "certreq",$parameters )
    $request.WaitForExit()
    write-host "Finished request $csr"
    #sleep 10
} # end foreach

Something you may have noticed in your journey on the road to AD enlightenment is that if you deploy a new Microsoft Enterprise Certificate Authority (CA) and publish the default templates, your Domain Controllers will automatically enroll for a certificate.  The template used is the DomainController V1 certificate, which has been around since Windows 2000 days.

cert3

But what if you wanted to assign a different certificate based on the most recent template designed for use with DCs (KerberosAuthentication)? Easy, you would think, given that the DCs have this in-built autoenrollment capability. All I would need to do is unpublish the old DomainController template, publish the new KerberosAuthentication template, ensure that DCs have autoenroll permissions on the template and then perform a Certutil –pulse command on the DCs. Right? Wrong. It’s actually not that straightforward. From what I have managed to infer (no one will provide me with a definitive answer) it seems the in-built auto-enrollment feature of Domain Controllers is tied specifically to the legacy DomainController template. In other words it will only work with the DomainController template and no other.

The only way I can get the DCs to successfully autoenroll for a certificate based on the KerberosAuthentication template is to follow the steps shown below.

1. Ensure the Domain Controllers group has permissions on the KerberosAuthentication template (it has by default).

cert4

2. Modify the properties of the KerberosAuthentication template to add the DomainController, DirectoryEmailReplication and DomainControllerAuthentication templates to the list of superseded templates

cert5

3. Publish the KerberosAuthentication template

4. Modify a GPO linked to the Domain Controllers OU to enable the “Certificate Services Client – Auto-Enrollment setting as shown below.

cert1

cert2

5. Wait for policy to apply to the DCs (or run gpupdate /force).

6. Run certutil –pulse from an elevate CMD prompt to force re-enrollment.

7. Confirm that a new certificate has been issued based on the KerberosAuthentication template and that the old certificate based on the DomainController template has been automatically removed.

The other day I was in an environment where I had to find what Certification Authorities (CAs) were in place.  With nobody immediately available to help me out, I stumbled around for bit before I worked out how to find them.

Method 1

Query the membership of the Cert Publishers group.  Cert Publishers is a built-in AD group.  When you create a new CA on a member server or a DC, the computer will be added to the group membership.

cert-publishers.jpg

While it worked for me in terms of identifying the server names the CAs were hosted on, it did not provide me with the CA names themselves.   In any case, I’m not convinced this is wholly reliable method of finding servers that host CAs, because there is always the potential for someone with permissions to manually edit the Cert Publishers group membership.  Also, I’m not sure what happens if someone does an ugly decommissioning of a CA.  Does the membership get cleaned up?  Probably not.

Method 2.

Search Active Directory for objects with an objectClass of certificationAuthority.  These are stored in the Configuration partition under CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,<ForestRootDN>.  Here’s an example of how to find them using adfind.exe.

C:\>adfind -b “CN=Certification Authorities,CN=Public Key Services,CN=Services,C
N=Configuration,DC=widget,DC=com” -f (objectclass=certificationAuthority) 1.1

The problem with looking in AD is that it provides you with the name of the CA, but not the server that’s hosting it.  Ok, in my example the server name is part of the CA name, but this may not always be the case.   The server name is probably buried within the cACertificate attribute of the certificationAuthority object, which is unfortunately not human-readable.

Method 3.

Open a command prompt and type certutil – dump.  You will see output similar to that shown below.

 Entry 0: (Local)
  Name:                    `widget-ADLDS1-CA’
  Organizational Unit:     `’
  Organization:            `’
  Locality:                `’
  State:                   `’
  Country/region:          `’
  Config:                  `ADLDS1.widget.com\widget-ADLDS1-CA’
  Exchange Certificate:    `’
  Signature Certificate:   `ADLDS1.widget.com_widget-ADLDS1-CA.crt’
  Description:             `’
  Server:                  `ADLDS1.widget.com’
  Authority:               `widget-ADLDS1-CA’
  Sanitized Name:          `widget-ADLDS1-CA’
  Short Name:              `widget-ADLDS1-CA’
  Sanitized Short Name:    `widget-ADLDS1-CA’
  Flags:                   `13′

Entry 1:
  Name:                    `widget-RWDC1-CA’
  Organizational Unit:     `’
  Organization:            `’
  Locality:                `’
  State:                   `’
  Country/region:          `’
  Config:                  `RWDC1.widget.com\widget-RWDC1-CA’
  Exchange Certificate:    `’
  Signature Certificate:   `’
  Description:             `’
  Server:                  `RWDC1.widget.com’
  Authority:               `widget-RWDC1-CA’
  Sanitized Name:          `widget-RWDC1-CA’
  Short Name:              `widget-RWDC1-CA’
  Sanitized Short Name:    `widget-RWDC1-CA’
  Flags:                   `1′
CertUtil: -dump command completed successfully.

This shows me that I have two CAs and provides me with information about the CA names and what servers they are hosted on.  But what if I wanted to find out what type of CA they are (i.e. Enterprise or Stand Alone and whether it is a root or subordinate CA)?  The certutil.exe tool can help with that too.  Here’s an example using certutil with the -cainfo parameter.

C:\>certutil -cainfo -config RWDC1.widget.com\widget-RWDC1-CA type

CA type: 0 — Enterprise Root CA
    ENUM_ENTERPRISE_ROOTCA — 0
CertUtil: -CAInfo command completed successfully.

This tells me that my CA running on server RWDC1.widget.com is an Enteprise Root CA.

The syntax of the certutil.exe tool takes a bit of getting used to, but otherwise seems to do the job nicely!

Tony