PKI Hints - Troubleshooting CertSvc Event ID 42 on an Enterprise CA in Windows 2000 and 2003
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 https://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.