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

Comments

Post a Comment

Popular posts from this blog

Email Sending through O365 using OAuth Protocol

-
  Microsoft Office365 EWS servers have been extended to support authorization via the industry-standard OAuth 2.0 protocol. Using OAUTH protocol, user can do authentication by Microsoft Web OAuth instead of inputting user and password directly in application Microsoft / Office 365 OAuth + EWS We can use the OAuth authentication service provided by Azure Active Directory to enable our application to connect with IMAP, POP or SMTP protocols to access Exchange Online in Office 365. To use OAuth with our application we need to register application on Azure Active directory and other steps also we need to do to get the access token back. Below are the steps   To use Microsoft/Office365 OAUTH in your application, you must create an application in  https://portal.azure.com . Sign into the Azure portal using either a work or school account or a personal Microsoft account. If your account gives you access to more than one tenant, select your account in the top ...
Read more

IoT Technology

-
Image
IoT technology The Internet of Things (IoT) is a system of interrelated computing devices, mechanical and digital machines.  IoT is a network of sensors where data is exchanged, using different connectivity protocols, with systems. This set up can be leveraged to create a new business application or to enhance an existing process. The exchange of the data can be bi-directional between sensors and systems Examples of sensors can be temperature sensors, motion sensors, flow meters, heart meter monitors, biometric devices, smoke detectors, & etc Examples of connectivity can be wifi, radio, GPRS, GSM, LAN, WAN, & etc. Examples of systems can be a remote health monitoring applications, SCADA applications, etc Look at next slide about the complete flow of IoT process Examples A doctor in US would like to monitor the heart rate and ECG of a patient in Hyderabad. This is done with the patient having sensors attached to him that collect the ECG data and the hea...
Read more

What is reverse proxy?

-
Image
  What is a reverse proxy? A reverse proxy is a server that sits in front of web servers and forwards client (e.g. web browser) requests to those web servers. Reverse proxies are typically implemented to help increase  security ,  performance , and reliability . In order to better understand how a reverse proxy works and the benefits it can provide, let’s first define what a proxy server is. What’s a proxy server? A forward proxy, often called a proxy, proxy server, or web proxy, is a server that sits in front of a group of client machines. When those computers make requests to sites and services on the Internet, the proxy server intercepts those requests and then communicates with web servers on behalf of those clients, like a middleman. For example, let’s name 3 computers involved in a typical forward proxy communication: A: This is a user’s home computer B: This is a forward proxy server C: This is a website’s origin server (where the website data is stored) In a stand...
Read more