PKI Hints - Troubleshooting CertSvc Event ID 42 on an Enterprise CA in Windows 2000 and 2003

shawnrab — Sat, 12 Aug 2006 02:55:00 GMT

I am going to tell you a story about SOX. Not Sarbanes Oxley, but S-O-X. In Microsoft Support, we are partly responsible for writing the Microsoft Knowledge Base articles at http://support.microsoft.com One of the ways we used to be able to get KB's out there was to write solution objects. In our case management database, customer cases were prefixed with SRX (or SRZ for a web issue or SR(letter), with a different letter for global regions). You open a case with Microsoft in North America and you get an SRX number which is SRX(year)(month)(date)6(daily case ID). So the 43,750th case for today would be SRX060811643750. SR stands for Service Request. When we would fix issues we would try to link a KB article to the solution. If we created the solution without documented support, we were responsible for creating solution objects, which are prefixed with SOX. So if you ever meet a Microsoft Support person and they talk about seeing an SOX, now you know what they're talking about. Anyway, if an SOX is linked to three cases, it gets raised to become a KB. "They" probably figure one time is a fluke, two times is a trend and three times is a real problem. I wrote a couple hundred of these things and have had a couple dozen raised. That leaves, well, a couple hundred SOX's that no one sees outside of Microsoft and I will try to sanitize them and post them. Hopefully you find them useful.

TITLE: How to Troubleshoot CertSvc Event ID 42 on an Enterprise CA

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

How to Troubleshoot CertSvc Event ID 42 on an Enterprise CA

Event Type: Error
Event Source: CertSvc
Event Category: None
Event ID: 42
Date: 10/29/2002
Time: 1:03:29 PM
User: N/A
Computer: SERVER
Description:
Certificate Services did not start: Could not build CA certificate chain for <ca
name>. Cannot find object or property. 0x80092004 (-2146885628).

OR

Event Type: Error
Event Source: CertSvc
Event Category: None
Event ID: 42
Date: 10/29/2002
Time: 1:03:29 PM
User: N/A
Computer: SERVER
Description:
Certificate Services did not start: Could not build CA certificate chain for <ca
name>. Keyset does not exist. 0x80090016 (-2146893802) .

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
*** Resolution ***

The certificate service relies on the CACertHash value present in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<ca
name>
The easiest way to determine this value is to run the following command:

certutil -getreg ca\CACertHash

Take note of the values. An example is:

CACertHash               REG_MULTI_SZ =
    0: a3 44 19 90 30 41 5e c4 7b 0f d4 4d ea 47 d7 30 ef 0c 58 49
    1: ac 4e 6f d6 32 fd 6a 00 72 34 4f 9d b7 33 96 f4 71 3a ab 44

The next step is to verify that the Local Machine Personal Store has a correct
association with these keys:

certutil -f -repairstore my "a3 44 19 90 30 41 5e c4 7b 0f d4 4d ea 47 d7 30 ef 0c 58 49"
certutil -f -repairstore my "ac 4e 6f d6 32 fd 6a 00 72 34 4f 9d b7 33 96 f4 71 3a ab 44"

If these commands are not completing successfully, you are likely receiving the
first above event (cannot find object or property)

This is likely caused by deleting one of the CA certificates out of the local
machine store. To check to see if one of these is missing look in
HKEY_LOCAL_MACHINE/Software/Microsoft/SystemCertificates/My

The associated keys are the Certificate Hashes or Thumbprints. Check to see if all
of the hashes in the CACertHash value are present. If one or more is missing, this
is the cause of the event. To get the certificates back try running at the
following command:

ldifde –d “CN=<ca name>,CN=AIA,CN=Public Key
Services,CN=Services,CN=Configuration,DC={domain},DC={com}” –v –f ldifde.txt
look in the ldifde.txt
The output may look similar to this:

--snip--
dn: CN=ca name,CN=AIA,CN=Public Key
Services,CN=Services,CN=Configuration,DC=domain,DC=com
changetype: add
authorityRevocationList:: AA==
cACertificate::
MIIEXTCCA8agAwIBAgIQSnXfyRlA8IxIzC8VlL+qbjANBgkqhkiG9w0BAQUFADCBmjEhMB8GCSqGSI
b3DQEJARYSZ2FzZXRhQGNwcWQuY29tLmJyMQswCQYDVQQGEwJCUjESMBAGA1UECBMJU2FvIFBBdWxv
MREwDwYDVQQHEwhDYW1waW5hczENMAsGA1UEChMEQ1BxRDEYMBYGA1UECxMPU2Vydmlkb3JlcyBNYW
lsMRgwFgYDVQQDEw9DUHFEIEVudHJpc2UwHhcNMDMwNzE1MTkwMzM1WhcNMDUwNzE0MTkxMjI1
WjCBmjEhMB8GCSqGSIb3DQEJARYSZ2FzZXRhQGNwcWQuY29tLmJyMQswCQYDVQQGEwJCUjESMBAGA1
UECBMJU2FvIFBBdWxvMREwDwYDVQQHEwhDYW1waW5hczENMAsGA1UEChMEQ1BxRDEYMBYGA1UECxMP
U2Vydmlkb3JlcyBNYWlsMRgwFgYDVQQDEw9DUHFEIEVudGVycHJpc2UwgZ8wDQYJKoZIhvcNAQEBBQ
ADgY0AMIGJAoGBALxm6c/JjBUu+xrOEwALCug3MP/MeXe/lw+SyIy/Y4dZbQfI3zlOAAUxe5QxtK2z
sZ7yqzjsj9CEft9qjAdN93jojW1QKiNiPlFoHR9mdmM+wYDQupHAZb/BTbqxvzxO0W0NKIpSNISYbU
jGxJg2Ie9CLW88PDHgj3wVHJ0rHrftAgMBAAGjggGgMIIBnDATBgkrBgEEAYI3FAIEBh4EAEMAQTAL
BgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU2wGybzDbNPE9SX+z9oH37jEDMV
0wggEyBgNVHR8EggEpMIIBJTCB06CB0KCBzYaBymxkYXA6Ly8vQ049Q1BxRCUyMEVudGVycHJpc2Uo
MSksQ049c2FydW1hbixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZX
MsQ049Q29uZmlndXJhdGlvbixEQz1hcXVhcml1cyxEQz1jcHFkLERDPWNvbSxEQz1icj9jZXJ0aWZp
Y2F0ZVJldm9jYXRpb25MaXN0P2Jhc2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwTa
BLoEmGR2h0dHA6Ly9zYXJ1bWFuLmFxdWFyaXVzLmNwcWQuY29tLmJyL0NlcnRFbnJvbGwvQ1BxRCUy
MEVudGVycHJpc2UoMSkuY3JsMBIGCSsGAQQBgjcVAQQFAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAAI
H/45gc6pvksDMspXzS4tcB3GQ3NgVGGzUcfRYKzCsWIq+6RNhXLYiS4477WEr8iwqvWgmo4BMlNGiH
fQqQ9ZL3V7vB4eHtxVa99LqG1Ed8wQUg4iT1FA5yRS2ICI5vOf1vFDZHWXjH97heXSjyzfVt6/GwXH
fJ6QqvctSVXxI=
cACertificate::
MIID0DCCA3qgAwIBAgIQapi0c7lUwahPM9e1PZAHRjANBgkqhkiG9w0BAQUFADCBmjEhMB8GCSqGSI
b3DQEJARYSZ2FzZXRhQGNwcWQuY29tLmJyMQswCQYDVQQGEwJCUjESMBAGA1UECBMJU2FvIFBBdWxv
MREwDwYDVQQHEwhDYW1waW5hczENMAsGA1UEChMEQ1BxRDEYMBYGA1UECxMPU2Vydmlkb3JlcyBNYW
lsMRgwFgYDVQQDEw9DUHFEIEVudGVycHJpc2UwHhcNMDEwNzIzMTMzMzM2WhcNMDMwNzIzMTM0MjI2
WjCBmjEhMB8GCSqGSIb3DQEJARYSZ2FzZXRhQGNwcWQuY29tLmJyMQswCQYDVQQGEwJCUjESMBAGA1
UECBMJU2FvIFBBdWxvMREwDwYDVQQHEwhDYW1waW5hczENMAsGA1UEChMEQ1BxRDEYMBYGA1UECxMP
U2Vydmlkb3JlcyBNYWlsMRgwFgYDEw9DUHFEIEVudGVycHJpc2UwXDANBgkqhkiG9w0BAQEFAA
NLADBIAkEAv+tSVhSJyoG3oUGNDMMsUvCYH7KCF+DgQvSwb4txyxM5V9pixBTg0hOntGQF5jul
qcXHxSZBLADrbE50yQIDAQABo4IBmDCCAZQwEwYJKwYBBAGCNxQCBAYeBABDAEEwCwYDVR0PBAQDAg
EGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPIxi5fiD+6eELg94lAzp/WJXUByMIIBLAYDVR0f
BIIBIzCCAR8wgdCggc2ggcqGgcdsZGFwOi8vL0NOPUNQcUQlMjBFbnRlcnByaXNlLENOPXNhcnVtYW
4sQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3Vy
YXRpb24sREM9YXF1YXJpdXMsREM9Y3BxZCxEQz1jb20sREM9YnI/Y2VydGlmaWNhdGVSZXZvY2F0aW
9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MEqgSKBGhkRodHRwOi8v
c2FydW1hbi5hcXVhcml1cy5jcHFkLmNvbS5ici9DZXJ0RW5yb2xsL0NQcUQlMjBFbnRlcnByaXNlLm
NybDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQUFAANBAJ3GZkvWu1H3kUlkZZnl/g4pVm8P
5FcLUJJdV99feIlBYafuA0CIS5hM2IZuz4plqggINpVRlW8VqeDLc9D3lZE=
certificateRevocationList:: AA==
cn: ca name
instanceType: 4
--end snip--

Copy the data within the caCertificates attribute and paste it into text files.
Rename the text files to have a *.cer extension. Open the CER files and look at
the Thumbprint attribute, these attributes should line up with the above CACertHash
Values.   Find the CER file with the Thumbprint associated with the missing hash
and import the certificate into the Local Machine Personal Store. Open the
certificates mmc for local computer and double click on the Personal certificate
store, right click on certificates and go to Import certificate and select the CER
file associated with the missing hash.

Then run

certutil -f -repairstore my "{HASH}"

against the newly imported certificate and attempt service start.

To verify that the Keys are valid run the following command

certutil -verifykeys

If the verifykeys command fails - you are likely receiving the second error message
(Keyset does not exist)

If the key that is failing in the verifykeys command is associated with a
certificate that is not the most recent certificate, identify the certificate and
find the Thumbprint value and populate the caCertHash value with the correct sequence of thumbprints.

You may also want to check the permissions on the %allusersprofile%\Application Data\Microsoft\Crypto\RSA\Machinekeys folder to ensure that SYSTEM has permission on the private keys.

This posting is provided "AS IS" with no warranties, and confers no rights.

RWPT + PKI Hints - BAD TROUBLESHOOTING 101 (part 2 of many) Certification Authorities on a Domain Controller

shawnrab — Tue, 16 May 2006 11:29:00 GMT

I blogged last week on User Profile troubleshooting and that was one of my biggest pet peeves. Now it is time for my BIGGEST pet peeve. I almost feel bad that I am on entry number 4 of this blog and I can't save this one for later, but I need to hopefully spread the word and stop the bleeding.

This really isn't much of a blog entry on troubleshooting, but often times I have seen people stand up a temporary CA to get things like Live Communications Server or Outlook Web Access to work, so I guess technically you could look at it that way. I don't know where it started or who first said it was OK, but I am going to say it now... DO NOT INSTALL AN ENTERPRISE ROOT CA ON A DOMAIN CONTROLLER. This is a bad idea. A really bad idea. First of all, if I was a hacker and I wanted to target a server, I would target a DC. If I was a mean hacker and I wanted to send e-mail that was digitally signed by the CEO saying that everyone is fired, I would be happy to know that the DC I just attacked also had the private key of the root CA on it. That only touches the surface of what you could do if you had the private key. And there would be no means of revocation. Second of all, the biggest dependency of the Certificate Service is the computer name. There are hooks in DCPromo.exe to check to see if the computer is a CA. You would have to backup the CA using the CA snap-in, demote the DC or decommission the DC and move the CA backup to a server with the same name (How to move a certification authority to another server - http://support.microsoft.com/default.aspx?scid=kb;en-us;298138). Now, what if the DC goes down? I hope you have a backup (http://blogs.technet.com/shawnrab/archive/2006/05/10/427905.aspx) because if we go into Directory Services Restore mode, we can't take a backup of the CA's private key. With no backup of the CA, if the computer is toast, so are the certificates you issued.

The Microsoft Best Practice of a three-tier CA with an offline root is the way to go. And with support for Certificate Services on Windows Server 2003 SP1 on Virtual Server 2005 R2, there's really no excuse. If you have an enterprise subordinate CA that issued 100,000 certificates that is compromised, all you have to do is revoke one single certificate to deem the CA and the certificates it issued inoperable. If you add a Hardware Storage Module (HSM) for the private keys, you're in better shape. You'll thank me. Your auditor will thank me. Your CEO will thank me. OK, maybe not - you've likely made any potential problem go away.

Certificate Services and PKI is 95% planning and 5% doing. If you stand up a temporary CA for one or two certificates as a short-term solution, I am *almost* OK with that as long as you come in behind that CA with a full-blown PKI and you don't install the CA on a DC. With the guidance of the Best Practices for Implementing Windows Server 2003 PKI (http://technet2.microsoft.com/WindowsServer/en/Library/091cda67-79ec-481d-8a96-03e0be7374ed1033.mspx?mfr=true) and my two three-tier webcasts (http://support.microsoft.com/default.aspx?kbid=896733 and http://support.microsoft.com/default.aspx?kbid=896737), you could set up a temporary three-tier PKI using Virtual Server 2005 R2 and Windows Server 2003 SP1 and have quick and cheap practice for a full-blown PKI.

You can install a parallel PKI to the temporary PKI and have it work almost independant to the existing PKI. The only thing they will share is the Certificate Templates, which are in the Configuration NC in Active Directory.

Once you are ready to decommission the temporary PKI, you can use a quick command to remove the remnants of the temporary PKI from Active Directory. For a CA with friendly name Temp-CA-1, you can run this command: certutil.exe -dsdel Temp-CA-1

So all in all, just say NO to a CA on a DC.

This posting is provided "AS IS" with no warranties, and confers no rights.

Shawn's MIIS/ILM Tricks, PKI Hints, and Résumé Writing Prevention Tips : PKI

PKI Hints - Troubleshooting CertSvc Event ID 42 on an Enterprise CA in Windows 2000 and 2003

RWPT + PKI Hints - BAD TROUBLESHOOTING 101 (part 2 of many) Certification Authorities on a Domain Controller