ERR_SPDY_PROTOCOL_ERROR Nginx !!

Thu Aug 3 21:01:28 UTC 2017

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>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Aug 3, 2017 at 9:13 PM, shahzaib mushtaq <shahzaib.cb at 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 at 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_1565204697939808308_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Thu, Aug 3, 2017 at 12:27 PM, Francis Daly <francis at 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 at daoine.org
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170804/63b3cd13/attachment-0001.html>