Is this Chrome on Linux you're testing?

This is due to the SSLCommonNameMismatchHandling feature ( issue 507454 ). If the site serves a certificate that isn't valid for the requested name but is valid for the name without the www (or vice versa), chrome will switch to the working name. The CNAME redirect is not followed.

There is a message logged in the dev tools console when this occurs:
"Redirecting navigation www.webservices.nic.in -> webservices.nic.in because the server presented a certificate valid for webservices.nic.in but not for www.webservices.nic.in. To disable such redirects launch Chrome with the following flag: --disable-features=SSLCommonNameMismatchHandling"

No it didn't worked for me . I launched crome as you guided said with the switch you said ..same situation not blocking even now ..
And as you said a technically incorrect statement "IF SSL OF WWW IS PROVIDED SWITCHING BETWEEN WWW<----> NON WWW WILL BE SEEN cname redirect will not be followeed .

As per my understanding browser will first lookup dns ..got redirected by CNAME and the the tls handhake begins and SAN will be looked for domain in request and that is the CNAME redirected one

We are facing a potential secrurity issue owing to it ...plz get it resolved 

> As per my understanding browser will first lookup dns ..got redirected by CNAME and the the tls handhake begins and SAN will be looked for domain in request and that is the CNAME redirected one

No, this is incorrect.

The browser is told to load https://www.webservices.nic.in. It gets an IP, by way of the webservices.nic.in CNAME, but it checks for www.webservices.nic.in, NOT webservices.nic.in. www.webservices.nic.in is mis-configured, so this fails.

As a workaround for such mis-configured servers, Chrome notices that the www-less version of the name, webservices.nic.in, is in the certificate. This triggers workaround logic to load https://webservices.nic.in, starting over from the very top. It loads a new URL, makes a new DNS lookup, a new TLS handshake, and verifies a new certificate.

This is not triggered by the CNAME. Chrome doesn't even know there was a CNAME. It's purely based on the "www." prefix and does not happen for arbitrary names in the certificate. It's as if a user saw an error and decided to delete the "www." prefix in the URL to see if that one worked instead.

(Adding Enamel folks as the feature comes from that end of the stack.)

Why would I want that to happen ? I don't want my www to have any such previledge to get it's parent landing page..
Neither Firefox ,wget ssllabs is doing such unwanted help.

Ok you told me to use some switch while launching the chrome...it should stop this redirection ??? Why it's not stopping...you want video for this ??

according to you replies


i launched chrome according to your way to disable this workaround  , still
nothing happens

As the status of this case was closed when i observed it , i have opened a
new one , please do merge them according to your convenience ..