ERR_SPDY_PROTOCOL_ERROR Nginx !!
shahzaib.cb at gmail.com
Thu Aug 3 21:01:28 UTC 2017
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.
On Thu, Aug 3, 2017 at 9:13 PM, shahzaib mushtaq <shahzaib.cb at gmail.com>
> >>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;
> *.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
> 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.
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free.
> 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
>> > 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,
>> Francis Daly francis at daoine.org
>> nginx mailing list
>> nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx