I've noticed that its related to the orders of virtual host files. For
example if vhost of mydomain.com comes first than yourdomain.com then SSL
CN (common name) for both domains will be *.mydomain.com.

And if vhost of yourdomain.com comes before than mydomain.com then common
name for both domains is yourdomain.com .



On Fri, Aug 4, 2017 at 2:01 AM, shahzaib mushtaq <shahzaib.cb@gmail.com>
wrote:

> Update:
>
> Now i removed vhost for mydomain.com and yourdomain.com is now showing
> correct Common name. So there's some kind of overlapping in vhosts.
>
>
>
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free.
> www.avast.com
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
> <#m_-2776267015937845177_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Thu, Aug 3, 2017 at 9:13 PM, shahzaib mushtaq <shahzaib.cb@gmail.com>
> wrote:
>
>> Hi,
>>
>> >>As far as I know, there are about half a dozen "latest" versions of
>> Google Chrome, and none of them are version 64 currently.
>>
>> Your're right sorry, the version latest is 60.
>>
>>
>> >>You have one client that reports an error message.What are the
>> specific circumstances under which that version of that
>> client can report that error message? That information may give a hint
>> as to where the problem is.
>>
>> Well, i can generate this issue without a problem all i've to do is
>> create a test.html page, put 5 x static video links (our server http2 mp4
>> video links) and play them simultaneously. For the first request they'll
>> start playing with *200* status in inspect element under *Network *tab
>> but for further chunk requests from chrome, it'll stuck in *pending *and
>> under *Console *tab spdy error will start to occur. Once i've disabled
>> HTTP2 that issue is gone but 'pending' status issue still was there which i
>> think is linked with my below issue :
>>
>> ------------------------------------------------------------
>> ----------------
>>
>> Now we think there's issue with one SSL certificate which we renewed
>> recently. Our server has actually two different domain SSL certificates
>> configured on same ip;
>>
>> *.mydomain.com
>> *.yourdomain.com (*Renewed*)
>>
>> We've configured both these certificates vhosts in
>> /usr/local/etc/nginx/vhosts/ directory. After installing certificate we
>> tested it with sslshopper and both were installed properly (CN,
>> Intermediate Chain etc were properly listed for each).
>>
>> Now here is the twist comes. Recently we've renewed the SSL certificate
>> for **.yourdomain.com http://yourdomain.com* from *Godaddy *and after
>> that sslshopper shows correct CN and intermediate chain for new certificate
>> (*.yourdomain.com) but openssl is showing the CN of *.yourdomain.com as
>> of *.mydomain.com.
>>
>> I repeat SSLshopper and SSLLabs shows proper CN (common name) but if i
>> use openssl command to verify it :
>>
>> [root@cw012 /usr/ports/security/ca_root_nss]# openssl s_client -connect
>> s4.yourdomain.com:443 |head -30depth=2 C = US, O = GeoTrust Inc., OU =
>> (c) 2008 GeoTrust Inc. - For authorized use only, CN = GeoTrust Primary
>> Certification Authority - G3verify return:1s_clidepth=1 C = US, O =
>> GeoTrust Inc., CN = RapidSSL SHA256 CA - G2verify return:1head depth=0 CN = **.mydomain.com
>> http://mydomain.com*
>>
>> Here you can see that CN is *.mydomain.com instead of *.yourdomain.com.
>>
>> ==============================================
>>
>> Now for testing i had disabled vhost for yourdomain.com and used only
>> single mydomain.com after which requests for serving files improved
>> drastically before that, if we would had hit a page, it'll first go to
>> 'pending' status in chrome inspect element and after few time it'll show
>> 200 status but now it goes directly to 200 status.
>>
>> I'm really confused on what's happening right now but if someone has
>> faced this experience before please let me know, on first i thought there
>> could be nginx config issue but the problem is SSLshopper and ssllabs are
>> showing proper CName so now i think maybe its related to chrome
>>
>>
>> Thanks for your help.
>> Shahzaib
>>
>>
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free.
>> www.avast.com
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
>> <#m_-2776267015937845177_m_1565204697939808308_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Thu, Aug 3, 2017 at 12:27 PM, Francis Daly <francis@daoine.org> wrote:
>>
>>> On Wed, Aug 02, 2017 at 01:17:06PM +0500, shahzaib mushtaq wrote:
>>>
>>> Hi there,
>>>
>>> > Thanks for response well i've tried lot more things, updated FreeBsd,
>>> > updated openssl but issue is still there. Do you think is there any
>>> > possibility it is linked with Nginx ?
>>>
>>> You have one client that reports an error message.
>>>
>>> What are the specific circumstances under which that version of that
>>> client can report that error message? That information may give a hint
>>> as to where the problem is.
>>>
>>> Is the problem repeatable? As in: if you do a fresh install with no
>>> historical information of the client browser (a new "profile" or under
>>> a new user account), do you see the same behaviour?
>>>
>>> In a later mail, you suggest that you have two test nginx instances,
>>> and one client reports the error against one instance and not against
>>> the other.
>>>
>>> "nginx -V" on each could be used to identify any differences in the
>>> compile-time settings. "nginx -T" on each could be used to identify any
>>> difference in the run-time configuration.
>>>
>>> > https://pastebin.com/gaVWfWJv
>>> >
>>> > >>There is more than one version of google chrome. Some web reports
>>> suggest
>>> > that SPDY support was going to be removed in version 51.
>>> >
>>> > Chrome version is 64 latest which has removed spdy and supports HTTP2 i
>>> > guess.
>>>
>>> As far as I know, there are about half a dozen "latest" versions of
>>> Google Chrome, and none of them are version 64 currently.
>>>
>>> If you ask for help in a Google Chrome mailing list, you may want to
>>> provide the specific version number there to allow them to identify what
>>> exactly you are running.
>>>
>>> Good luck with it,
>>>
>>> f
>>> --
>>> Francis Daly francis@daoine.org
>>> _______________________________________________
>>> nginx mailing list
>>> nginx@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx
>>>
>>
>>
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx