Remote certificate has errors:, Certificate name mismatch., A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider root cause

During the ssl connection, windows update is invoked to update the Root Certificates. This needs internet connection. If the machine is connected to internet, no delay will be seen. If the machine is not connected to internet, 15 second delay is seen because that is the default timeout value for network retrieval of the updated Root Certificates. look at below for more details

The following sections provide summaries of how certificate revocation checking works. The summaries include:

• Basic Certificate Chain Validation
• Validating Revocation Information
• Network Retrieval and Caching

Basic Certificate Chain Validation

When CryptoAPI builds and validates a certificate chain, three distinct phases take place:

1. All possible certificate chains are built using locally cached certificates. If none of the certificate chains ends in a self-signed certificate, CryptoAPI then selects the best possible chain and attempt to retrieve issuer certificates specified in the authority information access extension to complete the chain. This process is repeated until a chain to a self-signed certificate is built.
2. For each chain that ends in a self-signed certificate in the trusted root store, revocation checking is performed.
3. Revocation checking is performed from the root CA certificate down to the evaluated certificate

Basic Certificate Chain Validation

When CryptoAPI builds and validates a certificate chain, three distinct phases take place:

1. All possible certificate chains are built using locally cached certificates. If none of the certificate chains ends in a self-signed certificate, CryptoAPI then selects the best possible chain and attempt to retrieve issuer certificates specified in the authority information access extension to complete the chain. This process is repeated until a chain to a self-signed certificate is built.
2. For each chain that ends in a self-signed certificate in the trusted root store, revocation checking is performed.
3. Revocation checking is performed from the root CA certificate down to the evaluated certificate

Certificate Validation

After CryptoAPI starts validating the individual certificates in the presented certificate chain(s), the following checks are performed:

1. CryptoAPI determines whether the certificate is included in the Untrusted certificate store. All certificates in the Untrusted certificate store are explicitly designated as disallowed certificates.
2. If the certificate included a stapled OCSP response and the stapled response is time valid, use the stapled OCSP response to valid the revocation status of the certificate.
3. If a CRL with the matching issuer name and optionally the same IDP is already in the CA store, use that version of the CRL.
4. If a stapled response or previously downloaded CRL is not available, then CryptoAPI must attempt URL retrieval to determine the revocation status of the certificate.
5. The URLs for OCSP and CDP are built in the following order:
1. OCSP URLs from Group Policy
2. OCSP URLs from the authority information access extension
3. CRL URLs from the CDP extension

Validating Revocation Information

When CryptoAPI determines the revocation status of a certificate, it is done by either examining the CRL or the OCSP response. In both cases, if the certificate is revoked, the revocation date is determined by comparing the current date with the RevocationDate field in the CRL or the OCSP response.

Determining Preference between OCSP and CRLs

Although the default behavior in Windows Vista is to prefer OCSP URLs in the authority information access extension to CRL distribution point URLs, it is not realistic to assume that OCSP will always be preferred over CRLs.

It is possible that a single server has issued several certificates that must be validated in the same revocation period. In this scenario, it may be less bandwidth intensive to download the CRL at the beginning of the revocation period than to request an OCSP response every time a certificate issued by the CA is validated.

For example, a typical OCSP response is 2 kilobytes (KBs). If smart card logon is enabled, a domain controller will cache approximately 100 megabytes (MBs) of OCSP responses after validating 50,000 user certificates during the logon process. In comparison, a CRL with 50,000 entries would be approximately 4 MBs (based on an assumption of 80 bytes per entry).

When CryptoAPI must validate a certificate for revocation status, the following algorithm is used:

1. If a stapled OCSP response that was returned by the TLS server or the DC is time valid, the stapled response is used to validate the certificate.
2. If the certificate being validated only includes either OCSP or CRL information, then the URLs are processed in the order in which they are presented in the certificate.
3. If both OCSP URLs and CDP URLs are present, the following routine is followed:
   1. The initial assumption is that OCSP is preferred over CRLs.
   2. When an OCSP response is cached, the URL is hashed and used as the prefix for the file name in the URL cache entry.
4. The total number of cached OCSP responses from a single OCSP responder URL is calculated, and then compared to a predefined value known as the magic count. The default magic count value is 50.
• If the number is less than or equal to the magic count, then the OCSP URLs are processed in the order dictated by the authority information access extension.
• If the number of is greater than the magic count, then the CRL URLs are processed in the order dictated by the CRL distribution point extension.
• If none of the OCSP URLs in the authority information access extension succeeds, then fall back to using CRLs.

Network Retrieval and Caching

When CryptoAPI performs network retrieval of revocation information, CryptoAPI first determines whether the required revocation information is already cached. The following sections provide details on how network retrieval is performed and how the results are cached.

Basic Operations

CryptoAPI first determines whether a time valid version of the revocation object exists in the CryptoAPI disk cache.

If a time-valid object is not found in the disk cache, the network retrieval process starts. For each URL that is available for retrieval, CryptoAPI starts a background thread to perform the network retrieval of that designated object. By default, the calling thread will wait up to 15 seconds for the retrieval to complete (as defined in Group Policy).

1. If the object takes longer than 15 seconds to download, then CryptoAPI will report the server as offline, even as the retrieval continues in the background. If the CRL distribution point specifies multiple working URLs, then CryptoAPI will start the download of the second URL 15 seconds after the URL retrieval began.
2. If the application performs a second certificate validation while the first background retrieval continues, then the retrieval for the second validation will fail immediately.

 Note

Most applications do not specify to CryptoAPI to use a cumulative time-out. If the cumulative time-out option is not enabled, CryptoAPI uses the CryptoAPI default setting which is a time-out of 15 seconds per URL. If the cumulative time-out option specified by the application, then CryptoAPI will use a default setting of 20 seconds as the cumulative timeout. The first URL receives a maximum timeout of 10 seconds. Each subsequent URL timeout is half of the remaining balance in the cumulative timeout value. 

CryptoAPI can prevent repeated fetching of objects that are located at unreachable URLs. For example, if the client is behind a firewall that blocks outgoing LDAP connections, no connections to an LDAP URL will succeed. To prevent continued attempts to unreachable URLs:

1. The unreachable URL is added to a list of unreachable URLs. The list of unreachable URLs is maintained on a per process basis.
2. CryptoAPI determines the earliest time that it will allow another attempt to retrieve the object at the unreachable URL. Until that time is reached, any attempt to retrieve the object will fail immediately with an offline error.
3. After the designated time is reached, CryptoAPI will attempt to connect to the URL again. If the connection fails, CryptoAPI will extend the time it will wait until another attempt is processed. The maximum time that it will wait is 30 minutes.
4. If the attempted connection is successful, then the interval is reset to 15 seconds