Windows Does Not Have Enough Information to Verify This Certificate: Diagnose the Certificate Chain

What the message means

Windows validates certificates by building a chain from the certificate being checked to a trusted certification authority. Windows certificate stores include separate locations for trusted roots and intermediate certification authorities, and applications can operate in Current User or Local Machine contexts. A certificate can therefore exist on the PC without Windows having the chain information or trust needed by the process that is validating it.

This is why “the certificate is installed” is not enough evidence. The relevant questions are: which certificate is being validated, who issued it, whether the required intermediate can be found or retrieved, whether the root is trusted in the appropriate store, and whether time/revocation/usage policy succeeds in the same process context as the original failure.

Step 1 — identify the exact certificate and issuer

On the certificate's Details tab, record the Subject, Issuer, validity dates, thumbprint and intended purposes. Do not download a certificate merely because its common name looks similar to the issuer.

Verify: The issuer shown on the leaf should correspond to the next CA certificate in the Certification Path.

Step 2 — verify the chain with CertUtil

Export or obtain the affected public certificate as a certificate file, then use Windows' built-in CertUtil diagnostic command. Microsoft documents -verify specifically for verifying certificates and certificate chains.

If you intentionally want CertUtil to attempt URL retrieval of chain and revocation information during diagnosis, use:

Verify: Compare normal -verify with -urlfetch. If only URL retrieval changes the result, that is evidence about missing/reachable external validation data—not proof that the original application/service can retrieve the same data. Read which URL/object failed before changing trust.

Step 3 — missing issuer? separate intermediate discovery from revocation

If the leaf was issued by an intermediate CA, Windows must be able to obtain the appropriate issuer certificate to construct the path. Check the certificate stores and, when relevant, the certificate's issuer-information retrieval path rather than importing the leaf into a trust store. Keep this separate from CRL/OCSP revocation retrieval: both can involve network URLs, but they answer different questions.

For a machine-wide service or server application, inspect Computer account → Intermediate Certification Authorities → Certificates. For a user-scoped application, also inspect the Current User context.

Verify: The intermediate certificate's Subject should match the issuer expected by the certificate below it, and its own issuer should lead toward the correct root.

Step 4 — check the Trusted Root store, but do not add arbitrary roots

Windows uses the Trusted Root Certification Authorities store as a trust anchor. If the chain reaches a legitimate public or organization-managed root that should be trusted but is absent in the required context, obtain the correct root through the CA's official distribution method or your organization's administrator.

For managed/private PKI, the required root may be distributed through Group Policy, MDM or another enterprise mechanism. Fixing that distribution is usually better than manually installing the root on one affected workstation.

Verify: Reopen the leaf certificate after the trusted chain is correctly available. Certification Path should build to the expected root without the original trust error.

Step 5 — distinguish Current User from Local Machine

Windows has separate Current User and Local Machine certificate stores. A certificate visible to your signed-in account is not automatically evidence that a Windows service or server process is using the same store context.

If the problem occurs only in one application or service, identify which account and store that process uses before moving or duplicating certificates. For IIS, services, device/driver validation and enterprise applications, machine context can matter.

Verify: Test again from the same application/service that originally failed, not only by double-clicking the certificate in Explorer.

Step 6 — if the chain is complete, check validity and revocation

A complete-looking chain can still fail validation. Confirm that the system clock is correct, each relevant certificate is within its validity period, the certificate is valid for the intended usage/policy, and the validating context can reach required certificate-status locations when revocation policy requires them.

Use the CertUtil output to distinguish chain-building problems from revocation or policy problems. AIA/issuer retrieval and CRL/OCSP status retrieval are not interchangeable. On corporate networks, proxies, service-account networking, TLS inspection, offline servers or restricted outbound access can make the diagnostic shell and the failing service see different validation data.

Verify: After correcting the specific retrieval or policy problem, rerun certutil -verify and retest the original application.

Step 7 — if it is a website or server certificate, verify the server sends the chain it should

If multiple client machines report the same certificate-chain problem against one website or server, do not repair every client first. Inspect the server's configured certificate and intermediate chain. A recurring SERP pattern is that a certificate can look healthy in one MMC context while IIS still reports that Windows lacks enough information; that makes store/service context and the IIS binding useful discriminators. A server-side chain problem can create client-side trust symptoms even when client root stores are healthy.

If only one machine fails while other comparable machines validate the same endpoint correctly, compare that machine's certificate stores, policy and network path with a known-good machine.

Still seeing “Windows does not have enough information to verify this certificate”?

At this point, preserve the evidence instead of trying additional broad fixes. The same Windows message can represent different PKI failures, so the chain and application context matter more than the wording alone.

Why this diagnostic order is safer

Certificate trust is security-sensitive. The shortest-looking fix—adding something to the Trusted Root store—can also be the riskiest if you have not identified what Windows is actually missing. Starting with the Certification Path and CertUtil keeps the first steps observational, then narrows any change to the intermediate, root, store scope or validation path that evidence identifies.

Official references