PKI and certificate troubleshooting

Locate the failed operation

A certificate failure can occur while generating a key, requesting issuance, installing a response, selecting a certificate, establishing TLS, checking revocation, mapping an account or using a private key. Record the operation and exact error before changing the CA.

Keep the certificate thumbprint, issuer and serial in the incident record. Subjects and friendly names can be identical across several certificates. Record a working example as well as the failure, including OS build, service identity, network location and time.

Inspect the store the workload uses

On Windows, these commands inspect the local machine Personal store, current user’s Personal store and a public certificate file:

certutil -store My
certutil -user -store My
certutil -dump certificate.cer

A service does not automatically use the administrator’s Current User store. A remote interactive sign-in can also have different certificate/key state from the account running the service. The Certutil reference documents the store and file verbs; check the installed version’s help when an option differs.

For an inventory using the Windows PowerShell certificate provider:

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Subject,Thumbprint,NotBefore,NotAfter,HasPrivateKey,
        DnsNameList,EnhancedKeyUsageList

DnsNameList and EnhancedKeyUsageList expose useful interpreted properties. Inspect the certificate’s extensions when a non-DNS identity, template OID or unfamiliar usage matters. Certificate provider reference.

HasPrivateKey tells you a private key is associated with the certificate. The application’s identity may still be unable to open or use it. Check the provider, machine/user key context, service identity and application error. You don’t need to export an authentication private key just to identify its certificate.

Separate identity, usage and trust

Check subject/SAN names, EKUs/application policies, key usage, validity and chain. Then check the policy required by the relying application. A certificate valid for one usage is not automatically acceptable for another. Windows has distinct verification policies for TLS, code signing and NT authentication. Chain-policy reference.

For an HTTPS or LDAPS endpoint, compare the requested hostname with the certificate the endpoint actually presented. For a client certificate, inspect the client’s key and the server’s validation/mapping evidence. For smart-card sign-in, both the DC and client validate certificates at different points; inspect both sides rather than importing roots until the prompt disappears. Smart-card authentication flow.

Follow the key through enrollment

Request generation, CA issuance and response installation are separate stages. A returned public certificate must be associated with the matching private key on the correct requester. certreq -accept installs an issued response in that workflow; it does not recreate a lost private key. The Certreq reference describes the stages and machine/user context options.

Legacy CSPs and CNG key storage providers expose different provider models. Match the template’s provider, algorithm and usage to the requester, consuming application and any HSM. Copying a working template’s key settings into a different workload can break compatibility. Use a scoped template pilot and test actual private-key operations, not only whether issuance completes. Template design controls.

Check what LDAPS selected

AD DS can use the NTDS service’s Personal store or the Local Computer Personal store, preferring a suitable NTDS-store certificate. An eligible certificate needs a usable private key, Server Authentication usage, the expected DC DNS name and a trusted chain. When several eligible certificates exist, verify the actual presented certificate instead of assuming the most recently issued one won. LDAPS certificate configuration.

For certificate replacement, distinguish the store and documented refresh behavior. Microsoft’s LDAPS certificate KB describes NTDS-store updates and the renewServerCertificate RootDSE operation. It also contains historical request examples; their old key sizes and provider choices are not a current cryptographic baseline.

After replacement, open a new TLS connection from a representative client and compare the certificate thumbprint/name/chain. Then try the intended LDAP bind and search. A listening TCP port doesn’t test those operations.

Keep issuance and validation available separately

An offline root protects its signing key by reducing routine exposure, but still needs controlled signing/CRL operations and recoverable key material. Issuing CAs, enrollment services, templates and AIA/CDP/OCSP publication have distinct availability requirements. PKI design guidance.

A CA outage can stop enrollment while existing certificates keep working, until another validation dependency fails. A healthy issuing CA also can’t make an unreachable or expired parent CRL acceptable to clients. Test recovery for issuance and certificate use, and keep old publication locations available for certificates that still name them.