This site can’t be reached: “mail.google.com is currently unreachable”











up vote
8
down vote

favorite
1












I am having a weird issue with my Chrome browser and I can't find how to fix it. Each time I try to access my Gmail email I got the following message:




This site can’t be reached



mail.google.com is currently unreachable.



Try:



Checking the connection
Checking the proxy and the firewall



ERR_SSL_VERSION_INTERFERENCE




I have tried the following:




  • Settings > Advanced > Reset

  • Settings > Advanced > Clear Browsing Data (from the beginning of the times)


None of them works and I got exactly the same issue after give it another try.



This is a work connection and does not affect any other browser. I have tried Firefox and the email works properly. At first I blame the connection but now seeing that it works on Firefox I can't do that. I am not behind any proxy.



Can any help me?










share|improve this question




















  • 4




    May be interesting: chromium.googlesource.com/chromium/src.git/+/…
    – Dave
    Jun 8 '17 at 12:21










  • What kind of connection is this? (At work? At Home?) has it ever worked on this connection? DO you have a proxy setup? Is your clock correct?
    – djsmiley2k
    Jun 8 '17 at 12:21










  • Does it affect other browsers?
    – Dave
    Jun 8 '17 at 12:21










  • @Dave I've edit the OP take a look again ... thx
    – ReynierPM
    Jun 8 '17 at 12:24















up vote
8
down vote

favorite
1












I am having a weird issue with my Chrome browser and I can't find how to fix it. Each time I try to access my Gmail email I got the following message:




This site can’t be reached



mail.google.com is currently unreachable.



Try:



Checking the connection
Checking the proxy and the firewall



ERR_SSL_VERSION_INTERFERENCE




I have tried the following:




  • Settings > Advanced > Reset

  • Settings > Advanced > Clear Browsing Data (from the beginning of the times)


None of them works and I got exactly the same issue after give it another try.



This is a work connection and does not affect any other browser. I have tried Firefox and the email works properly. At first I blame the connection but now seeing that it works on Firefox I can't do that. I am not behind any proxy.



Can any help me?










share|improve this question




















  • 4




    May be interesting: chromium.googlesource.com/chromium/src.git/+/…
    – Dave
    Jun 8 '17 at 12:21










  • What kind of connection is this? (At work? At Home?) has it ever worked on this connection? DO you have a proxy setup? Is your clock correct?
    – djsmiley2k
    Jun 8 '17 at 12:21










  • Does it affect other browsers?
    – Dave
    Jun 8 '17 at 12:21










  • @Dave I've edit the OP take a look again ... thx
    – ReynierPM
    Jun 8 '17 at 12:24













up vote
8
down vote

favorite
1









up vote
8
down vote

favorite
1






1





I am having a weird issue with my Chrome browser and I can't find how to fix it. Each time I try to access my Gmail email I got the following message:




This site can’t be reached



mail.google.com is currently unreachable.



Try:



Checking the connection
Checking the proxy and the firewall



ERR_SSL_VERSION_INTERFERENCE




I have tried the following:




  • Settings > Advanced > Reset

  • Settings > Advanced > Clear Browsing Data (from the beginning of the times)


None of them works and I got exactly the same issue after give it another try.



This is a work connection and does not affect any other browser. I have tried Firefox and the email works properly. At first I blame the connection but now seeing that it works on Firefox I can't do that. I am not behind any proxy.



Can any help me?










share|improve this question















I am having a weird issue with my Chrome browser and I can't find how to fix it. Each time I try to access my Gmail email I got the following message:




This site can’t be reached



mail.google.com is currently unreachable.



Try:



Checking the connection
Checking the proxy and the firewall



ERR_SSL_VERSION_INTERFERENCE




I have tried the following:




  • Settings > Advanced > Reset

  • Settings > Advanced > Clear Browsing Data (from the beginning of the times)


None of them works and I got exactly the same issue after give it another try.



This is a work connection and does not affect any other browser. I have tried Firefox and the email works properly. At first I blame the connection but now seeing that it works on Firefox I can't do that. I am not behind any proxy.



Can any help me?







google-chrome https






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jun 8 '17 at 12:23

























asked Jun 8 '17 at 12:17









ReynierPM

1901215




1901215








  • 4




    May be interesting: chromium.googlesource.com/chromium/src.git/+/…
    – Dave
    Jun 8 '17 at 12:21










  • What kind of connection is this? (At work? At Home?) has it ever worked on this connection? DO you have a proxy setup? Is your clock correct?
    – djsmiley2k
    Jun 8 '17 at 12:21










  • Does it affect other browsers?
    – Dave
    Jun 8 '17 at 12:21










  • @Dave I've edit the OP take a look again ... thx
    – ReynierPM
    Jun 8 '17 at 12:24














  • 4




    May be interesting: chromium.googlesource.com/chromium/src.git/+/…
    – Dave
    Jun 8 '17 at 12:21










  • What kind of connection is this? (At work? At Home?) has it ever worked on this connection? DO you have a proxy setup? Is your clock correct?
    – djsmiley2k
    Jun 8 '17 at 12:21










  • Does it affect other browsers?
    – Dave
    Jun 8 '17 at 12:21










  • @Dave I've edit the OP take a look again ... thx
    – ReynierPM
    Jun 8 '17 at 12:24








4




4




May be interesting: chromium.googlesource.com/chromium/src.git/+/…
– Dave
Jun 8 '17 at 12:21




May be interesting: chromium.googlesource.com/chromium/src.git/+/…
– Dave
Jun 8 '17 at 12:21












What kind of connection is this? (At work? At Home?) has it ever worked on this connection? DO you have a proxy setup? Is your clock correct?
– djsmiley2k
Jun 8 '17 at 12:21




What kind of connection is this? (At work? At Home?) has it ever worked on this connection? DO you have a proxy setup? Is your clock correct?
– djsmiley2k
Jun 8 '17 at 12:21












Does it affect other browsers?
– Dave
Jun 8 '17 at 12:21




Does it affect other browsers?
– Dave
Jun 8 '17 at 12:21












@Dave I've edit the OP take a look again ... thx
– ReynierPM
Jun 8 '17 at 12:24




@Dave I've edit the OP take a look again ... thx
– ReynierPM
Jun 8 '17 at 12:24










5 Answers
5






active

oldest

votes

















up vote
14
down vote













I'm one of the people working on SSL/TLS for Chrome.



We're experimenting with draft versions of TLS 1.3, the next revision of the TLS protocol. Unfortunately, we're seeing issues with buggy middleware (antivirus, firewalls, proxies, etc.) which break when TLS 1.3 is enabled. ERR_SSL_VERSION_INTERFERENCE means we've detected one of these cases.



Would you mind filing a bug at https://crbug.com/new? We can then take it from there. Anyone else seeing this issue, please do also file a bug.



Thanks!






share|improve this answer





















  • Hi David, the error is gone now but if I get it again I'll be opening a bug as requested. Sorry for the delay this only happen at work and you caught me at weekend. (I'll leave this open for now if by the end of the week I doesn't have the error anymore I'll accept your answer and close this)
    – ReynierPM
    Jun 12 '17 at 12:20








  • 1




    If you have any MITM proxies (i.e. devices that attempt to intercept HTTPS connections at work), the manufacturer and firmware version would be interesting to know. Also, you may be able to more reliably reproduce by disabling "Experimental QUIC protocol" and setting "Maximum TLS version enabled." to TLS 1.3 in chrome://flags.
    – agl
    Jun 12 '17 at 16:15












  • Hi there, today I am running in the same issue once again I have open an issue here however as @user737958 said putting back TLS to 1.2 make everything to work.
    – ReynierPM
    Jun 19 '17 at 12:21


















up vote
7
down vote













For me. I just disable the tls 1.3 and google mail works again. @_@
enter image description here






share|improve this answer





















  • Yep that worked for me. Glad there was another answer mentioning chrome://flags though or I wouldn't have known where to find this setting.
    – Adrian Larson
    Dec 12 '17 at 19:38










  • Ooowh....I forgot to mention chrome://flags... :)
    – Hyosoka Poipo
    Dec 13 '17 at 2:10










  • Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
    – Navin
    May 5 at 18:09




















up vote
2
down vote













I got the same issue recently at work after updating Chrome. I tried to set TLS version to 1.2 in chrome://flags and it works again.






share|improve this answer

















  • 1




    Please provide more specifics.
    – Ramhound
    Jun 12 '17 at 20:40






  • 1




    If you set the max version as a workaround, please file a bug at crbug.com/new. That means there is a problem with something on your network that we need to get to the bottom of.
    – David Benjamin
    Jun 14 '17 at 16:59


















up vote
0
down vote













Certainly, if you have google-chrome stable 63.0.3239.84 or upper, you can get your self-signed certificates working again (in my case, to access my Canon Printer configuration) with the red triangle on the left thorough: chrome://flags, looking for TLS and disabling TLS 1.3.



Instead, you can, of course, regenerate your certificates to be TLS 1.3 compatible.



TLS 1.3 certainly have advantages in security and performance (mainly about the handshake process).



It is worth mentioning that firefox 52.5.0 ESR worked as expected before. No proxy, and navigating, as previously said, my Canon printer in the LAN. It was only a "problem" with google-chrome (64bit) in Linux.






share|improve this answer



















  • 1




    Can you confirm the model and firmware version of the printer with which you're having issues? Another report suggested a PIXMA MX495, but they don't seem to be immediately available. If it also happens with a current model, we'll get one this week and see if we can identify the issue with these devices.
    – agl
    Dec 10 '17 at 3:00










  • It is a Canon Pixma MG3650. I've just upgraded the firmware from the 2.040 to the 2.050 version a few days ago. After that, I regenerated the self-signed certificate but the new one still gives a version mismatch with TLS 1.3 thorough google-chrome. I could generate TLS 1.3 certificates outside the printer and load them to it but I use Gentoo Linux and TLS 1.3 support is still masked (thorough OpenSSL 1.1.0).
    – Miguel A. RO
    Dec 11 '17 at 8:11








  • 1




    Thanks for the details. I don't believe that it's the certificates that are likely to be the problem here. Rather something is likely wrong in Canon's TLS implementation that prevents it from correctly parsing Chrome 63's ClientHello message. For now, you can likely fix this by forcing chrome://flags/#tls13-variant to Disabled. I'm getting a PIXMA printer shipped so that we can investigate this further.
    – agl
    Dec 11 '17 at 17:34












  • Thanks a lot for taking into account user problems. This is the real meaning of Linus Torvalds' motto: "Breaking user programs simple isn't acceptable" even when other like likely Canon in this case seem to be responsable for the problems.
    – Miguel A. RO
    Dec 12 '17 at 18:03






  • 1




    We've found that Canon's TLS stack (which appears to be BSAFE) implements an unofficial TLS extension as extension 40. However, that collides with the key_share extension from TLS 1.3, resulting in this inter-op issue. We've alerted Canon and will let the IETF know. Hopefully the IETF can renumber key_share around this. The TLS 1.3 experiment in Chrome will be discontinued on the 19th, at which point this problem disappears, at least for the moment.
    – agl
    Dec 13 '17 at 19:08




















up vote
0
down vote













See if you can fix this error by applying three solutions:




  • Reverse your recent changes in the proxy settings

  • Disable TLS 1.3 from chrome flag settings

  • Uncheck Automatic Detect option from Internet Options > Internet Properties > LAN Settings > Connection


One of above solution will surely fix ssl version error on your pc.






share|improve this answer





















  • To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
    – JUNED MEMON
    Nov 10 at 8:37










protected by Community Nov 22 at 12:11



Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



Would you like to answer one of these unanswered questions instead?














5 Answers
5






active

oldest

votes








5 Answers
5






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
14
down vote













I'm one of the people working on SSL/TLS for Chrome.



We're experimenting with draft versions of TLS 1.3, the next revision of the TLS protocol. Unfortunately, we're seeing issues with buggy middleware (antivirus, firewalls, proxies, etc.) which break when TLS 1.3 is enabled. ERR_SSL_VERSION_INTERFERENCE means we've detected one of these cases.



Would you mind filing a bug at https://crbug.com/new? We can then take it from there. Anyone else seeing this issue, please do also file a bug.



Thanks!






share|improve this answer





















  • Hi David, the error is gone now but if I get it again I'll be opening a bug as requested. Sorry for the delay this only happen at work and you caught me at weekend. (I'll leave this open for now if by the end of the week I doesn't have the error anymore I'll accept your answer and close this)
    – ReynierPM
    Jun 12 '17 at 12:20








  • 1




    If you have any MITM proxies (i.e. devices that attempt to intercept HTTPS connections at work), the manufacturer and firmware version would be interesting to know. Also, you may be able to more reliably reproduce by disabling "Experimental QUIC protocol" and setting "Maximum TLS version enabled." to TLS 1.3 in chrome://flags.
    – agl
    Jun 12 '17 at 16:15












  • Hi there, today I am running in the same issue once again I have open an issue here however as @user737958 said putting back TLS to 1.2 make everything to work.
    – ReynierPM
    Jun 19 '17 at 12:21















up vote
14
down vote













I'm one of the people working on SSL/TLS for Chrome.



We're experimenting with draft versions of TLS 1.3, the next revision of the TLS protocol. Unfortunately, we're seeing issues with buggy middleware (antivirus, firewalls, proxies, etc.) which break when TLS 1.3 is enabled. ERR_SSL_VERSION_INTERFERENCE means we've detected one of these cases.



Would you mind filing a bug at https://crbug.com/new? We can then take it from there. Anyone else seeing this issue, please do also file a bug.



Thanks!






share|improve this answer





















  • Hi David, the error is gone now but if I get it again I'll be opening a bug as requested. Sorry for the delay this only happen at work and you caught me at weekend. (I'll leave this open for now if by the end of the week I doesn't have the error anymore I'll accept your answer and close this)
    – ReynierPM
    Jun 12 '17 at 12:20








  • 1




    If you have any MITM proxies (i.e. devices that attempt to intercept HTTPS connections at work), the manufacturer and firmware version would be interesting to know. Also, you may be able to more reliably reproduce by disabling "Experimental QUIC protocol" and setting "Maximum TLS version enabled." to TLS 1.3 in chrome://flags.
    – agl
    Jun 12 '17 at 16:15












  • Hi there, today I am running in the same issue once again I have open an issue here however as @user737958 said putting back TLS to 1.2 make everything to work.
    – ReynierPM
    Jun 19 '17 at 12:21













up vote
14
down vote










up vote
14
down vote









I'm one of the people working on SSL/TLS for Chrome.



We're experimenting with draft versions of TLS 1.3, the next revision of the TLS protocol. Unfortunately, we're seeing issues with buggy middleware (antivirus, firewalls, proxies, etc.) which break when TLS 1.3 is enabled. ERR_SSL_VERSION_INTERFERENCE means we've detected one of these cases.



Would you mind filing a bug at https://crbug.com/new? We can then take it from there. Anyone else seeing this issue, please do also file a bug.



Thanks!






share|improve this answer












I'm one of the people working on SSL/TLS for Chrome.



We're experimenting with draft versions of TLS 1.3, the next revision of the TLS protocol. Unfortunately, we're seeing issues with buggy middleware (antivirus, firewalls, proxies, etc.) which break when TLS 1.3 is enabled. ERR_SSL_VERSION_INTERFERENCE means we've detected one of these cases.



Would you mind filing a bug at https://crbug.com/new? We can then take it from there. Anyone else seeing this issue, please do also file a bug.



Thanks!







share|improve this answer












share|improve this answer



share|improve this answer










answered Jun 9 '17 at 19:10









David Benjamin

1412




1412












  • Hi David, the error is gone now but if I get it again I'll be opening a bug as requested. Sorry for the delay this only happen at work and you caught me at weekend. (I'll leave this open for now if by the end of the week I doesn't have the error anymore I'll accept your answer and close this)
    – ReynierPM
    Jun 12 '17 at 12:20








  • 1




    If you have any MITM proxies (i.e. devices that attempt to intercept HTTPS connections at work), the manufacturer and firmware version would be interesting to know. Also, you may be able to more reliably reproduce by disabling "Experimental QUIC protocol" and setting "Maximum TLS version enabled." to TLS 1.3 in chrome://flags.
    – agl
    Jun 12 '17 at 16:15












  • Hi there, today I am running in the same issue once again I have open an issue here however as @user737958 said putting back TLS to 1.2 make everything to work.
    – ReynierPM
    Jun 19 '17 at 12:21


















  • Hi David, the error is gone now but if I get it again I'll be opening a bug as requested. Sorry for the delay this only happen at work and you caught me at weekend. (I'll leave this open for now if by the end of the week I doesn't have the error anymore I'll accept your answer and close this)
    – ReynierPM
    Jun 12 '17 at 12:20








  • 1




    If you have any MITM proxies (i.e. devices that attempt to intercept HTTPS connections at work), the manufacturer and firmware version would be interesting to know. Also, you may be able to more reliably reproduce by disabling "Experimental QUIC protocol" and setting "Maximum TLS version enabled." to TLS 1.3 in chrome://flags.
    – agl
    Jun 12 '17 at 16:15












  • Hi there, today I am running in the same issue once again I have open an issue here however as @user737958 said putting back TLS to 1.2 make everything to work.
    – ReynierPM
    Jun 19 '17 at 12:21
















Hi David, the error is gone now but if I get it again I'll be opening a bug as requested. Sorry for the delay this only happen at work and you caught me at weekend. (I'll leave this open for now if by the end of the week I doesn't have the error anymore I'll accept your answer and close this)
– ReynierPM
Jun 12 '17 at 12:20






Hi David, the error is gone now but if I get it again I'll be opening a bug as requested. Sorry for the delay this only happen at work and you caught me at weekend. (I'll leave this open for now if by the end of the week I doesn't have the error anymore I'll accept your answer and close this)
– ReynierPM
Jun 12 '17 at 12:20






1




1




If you have any MITM proxies (i.e. devices that attempt to intercept HTTPS connections at work), the manufacturer and firmware version would be interesting to know. Also, you may be able to more reliably reproduce by disabling "Experimental QUIC protocol" and setting "Maximum TLS version enabled." to TLS 1.3 in chrome://flags.
– agl
Jun 12 '17 at 16:15






If you have any MITM proxies (i.e. devices that attempt to intercept HTTPS connections at work), the manufacturer and firmware version would be interesting to know. Also, you may be able to more reliably reproduce by disabling "Experimental QUIC protocol" and setting "Maximum TLS version enabled." to TLS 1.3 in chrome://flags.
– agl
Jun 12 '17 at 16:15














Hi there, today I am running in the same issue once again I have open an issue here however as @user737958 said putting back TLS to 1.2 make everything to work.
– ReynierPM
Jun 19 '17 at 12:21




Hi there, today I am running in the same issue once again I have open an issue here however as @user737958 said putting back TLS to 1.2 make everything to work.
– ReynierPM
Jun 19 '17 at 12:21












up vote
7
down vote













For me. I just disable the tls 1.3 and google mail works again. @_@
enter image description here






share|improve this answer





















  • Yep that worked for me. Glad there was another answer mentioning chrome://flags though or I wouldn't have known where to find this setting.
    – Adrian Larson
    Dec 12 '17 at 19:38










  • Ooowh....I forgot to mention chrome://flags... :)
    – Hyosoka Poipo
    Dec 13 '17 at 2:10










  • Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
    – Navin
    May 5 at 18:09

















up vote
7
down vote













For me. I just disable the tls 1.3 and google mail works again. @_@
enter image description here






share|improve this answer





















  • Yep that worked for me. Glad there was another answer mentioning chrome://flags though or I wouldn't have known where to find this setting.
    – Adrian Larson
    Dec 12 '17 at 19:38










  • Ooowh....I forgot to mention chrome://flags... :)
    – Hyosoka Poipo
    Dec 13 '17 at 2:10










  • Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
    – Navin
    May 5 at 18:09















up vote
7
down vote










up vote
7
down vote









For me. I just disable the tls 1.3 and google mail works again. @_@
enter image description here






share|improve this answer












For me. I just disable the tls 1.3 and google mail works again. @_@
enter image description here







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 12 '17 at 2:27









Hyosoka Poipo

17912




17912












  • Yep that worked for me. Glad there was another answer mentioning chrome://flags though or I wouldn't have known where to find this setting.
    – Adrian Larson
    Dec 12 '17 at 19:38










  • Ooowh....I forgot to mention chrome://flags... :)
    – Hyosoka Poipo
    Dec 13 '17 at 2:10










  • Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
    – Navin
    May 5 at 18:09




















  • Yep that worked for me. Glad there was another answer mentioning chrome://flags though or I wouldn't have known where to find this setting.
    – Adrian Larson
    Dec 12 '17 at 19:38










  • Ooowh....I forgot to mention chrome://flags... :)
    – Hyosoka Poipo
    Dec 13 '17 at 2:10










  • Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
    – Navin
    May 5 at 18:09


















Yep that worked for me. Glad there was another answer mentioning chrome://flags though or I wouldn't have known where to find this setting.
– Adrian Larson
Dec 12 '17 at 19:38




Yep that worked for me. Glad there was another answer mentioning chrome://flags though or I wouldn't have known where to find this setting.
– Adrian Larson
Dec 12 '17 at 19:38












Ooowh....I forgot to mention chrome://flags... :)
– Hyosoka Poipo
Dec 13 '17 at 2:10




Ooowh....I forgot to mention chrome://flags... :)
– Hyosoka Poipo
Dec 13 '17 at 2:10












Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
– Navin
May 5 at 18:09






Eww, this only fixes the symptoms. The cause is some network device screwing with your connection.
– Navin
May 5 at 18:09












up vote
2
down vote













I got the same issue recently at work after updating Chrome. I tried to set TLS version to 1.2 in chrome://flags and it works again.






share|improve this answer

















  • 1




    Please provide more specifics.
    – Ramhound
    Jun 12 '17 at 20:40






  • 1




    If you set the max version as a workaround, please file a bug at crbug.com/new. That means there is a problem with something on your network that we need to get to the bottom of.
    – David Benjamin
    Jun 14 '17 at 16:59















up vote
2
down vote













I got the same issue recently at work after updating Chrome. I tried to set TLS version to 1.2 in chrome://flags and it works again.






share|improve this answer

















  • 1




    Please provide more specifics.
    – Ramhound
    Jun 12 '17 at 20:40






  • 1




    If you set the max version as a workaround, please file a bug at crbug.com/new. That means there is a problem with something on your network that we need to get to the bottom of.
    – David Benjamin
    Jun 14 '17 at 16:59













up vote
2
down vote










up vote
2
down vote









I got the same issue recently at work after updating Chrome. I tried to set TLS version to 1.2 in chrome://flags and it works again.






share|improve this answer












I got the same issue recently at work after updating Chrome. I tried to set TLS version to 1.2 in chrome://flags and it works again.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jun 12 '17 at 20:13









user737958

311




311








  • 1




    Please provide more specifics.
    – Ramhound
    Jun 12 '17 at 20:40






  • 1




    If you set the max version as a workaround, please file a bug at crbug.com/new. That means there is a problem with something on your network that we need to get to the bottom of.
    – David Benjamin
    Jun 14 '17 at 16:59














  • 1




    Please provide more specifics.
    – Ramhound
    Jun 12 '17 at 20:40






  • 1




    If you set the max version as a workaround, please file a bug at crbug.com/new. That means there is a problem with something on your network that we need to get to the bottom of.
    – David Benjamin
    Jun 14 '17 at 16:59








1




1




Please provide more specifics.
– Ramhound
Jun 12 '17 at 20:40




Please provide more specifics.
– Ramhound
Jun 12 '17 at 20:40




1




1




If you set the max version as a workaround, please file a bug at crbug.com/new. That means there is a problem with something on your network that we need to get to the bottom of.
– David Benjamin
Jun 14 '17 at 16:59




If you set the max version as a workaround, please file a bug at crbug.com/new. That means there is a problem with something on your network that we need to get to the bottom of.
– David Benjamin
Jun 14 '17 at 16:59










up vote
0
down vote













Certainly, if you have google-chrome stable 63.0.3239.84 or upper, you can get your self-signed certificates working again (in my case, to access my Canon Printer configuration) with the red triangle on the left thorough: chrome://flags, looking for TLS and disabling TLS 1.3.



Instead, you can, of course, regenerate your certificates to be TLS 1.3 compatible.



TLS 1.3 certainly have advantages in security and performance (mainly about the handshake process).



It is worth mentioning that firefox 52.5.0 ESR worked as expected before. No proxy, and navigating, as previously said, my Canon printer in the LAN. It was only a "problem" with google-chrome (64bit) in Linux.






share|improve this answer



















  • 1




    Can you confirm the model and firmware version of the printer with which you're having issues? Another report suggested a PIXMA MX495, but they don't seem to be immediately available. If it also happens with a current model, we'll get one this week and see if we can identify the issue with these devices.
    – agl
    Dec 10 '17 at 3:00










  • It is a Canon Pixma MG3650. I've just upgraded the firmware from the 2.040 to the 2.050 version a few days ago. After that, I regenerated the self-signed certificate but the new one still gives a version mismatch with TLS 1.3 thorough google-chrome. I could generate TLS 1.3 certificates outside the printer and load them to it but I use Gentoo Linux and TLS 1.3 support is still masked (thorough OpenSSL 1.1.0).
    – Miguel A. RO
    Dec 11 '17 at 8:11








  • 1




    Thanks for the details. I don't believe that it's the certificates that are likely to be the problem here. Rather something is likely wrong in Canon's TLS implementation that prevents it from correctly parsing Chrome 63's ClientHello message. For now, you can likely fix this by forcing chrome://flags/#tls13-variant to Disabled. I'm getting a PIXMA printer shipped so that we can investigate this further.
    – agl
    Dec 11 '17 at 17:34












  • Thanks a lot for taking into account user problems. This is the real meaning of Linus Torvalds' motto: "Breaking user programs simple isn't acceptable" even when other like likely Canon in this case seem to be responsable for the problems.
    – Miguel A. RO
    Dec 12 '17 at 18:03






  • 1




    We've found that Canon's TLS stack (which appears to be BSAFE) implements an unofficial TLS extension as extension 40. However, that collides with the key_share extension from TLS 1.3, resulting in this inter-op issue. We've alerted Canon and will let the IETF know. Hopefully the IETF can renumber key_share around this. The TLS 1.3 experiment in Chrome will be discontinued on the 19th, at which point this problem disappears, at least for the moment.
    – agl
    Dec 13 '17 at 19:08

















up vote
0
down vote













Certainly, if you have google-chrome stable 63.0.3239.84 or upper, you can get your self-signed certificates working again (in my case, to access my Canon Printer configuration) with the red triangle on the left thorough: chrome://flags, looking for TLS and disabling TLS 1.3.



Instead, you can, of course, regenerate your certificates to be TLS 1.3 compatible.



TLS 1.3 certainly have advantages in security and performance (mainly about the handshake process).



It is worth mentioning that firefox 52.5.0 ESR worked as expected before. No proxy, and navigating, as previously said, my Canon printer in the LAN. It was only a "problem" with google-chrome (64bit) in Linux.






share|improve this answer



















  • 1




    Can you confirm the model and firmware version of the printer with which you're having issues? Another report suggested a PIXMA MX495, but they don't seem to be immediately available. If it also happens with a current model, we'll get one this week and see if we can identify the issue with these devices.
    – agl
    Dec 10 '17 at 3:00










  • It is a Canon Pixma MG3650. I've just upgraded the firmware from the 2.040 to the 2.050 version a few days ago. After that, I regenerated the self-signed certificate but the new one still gives a version mismatch with TLS 1.3 thorough google-chrome. I could generate TLS 1.3 certificates outside the printer and load them to it but I use Gentoo Linux and TLS 1.3 support is still masked (thorough OpenSSL 1.1.0).
    – Miguel A. RO
    Dec 11 '17 at 8:11








  • 1




    Thanks for the details. I don't believe that it's the certificates that are likely to be the problem here. Rather something is likely wrong in Canon's TLS implementation that prevents it from correctly parsing Chrome 63's ClientHello message. For now, you can likely fix this by forcing chrome://flags/#tls13-variant to Disabled. I'm getting a PIXMA printer shipped so that we can investigate this further.
    – agl
    Dec 11 '17 at 17:34












  • Thanks a lot for taking into account user problems. This is the real meaning of Linus Torvalds' motto: "Breaking user programs simple isn't acceptable" even when other like likely Canon in this case seem to be responsable for the problems.
    – Miguel A. RO
    Dec 12 '17 at 18:03






  • 1




    We've found that Canon's TLS stack (which appears to be BSAFE) implements an unofficial TLS extension as extension 40. However, that collides with the key_share extension from TLS 1.3, resulting in this inter-op issue. We've alerted Canon and will let the IETF know. Hopefully the IETF can renumber key_share around this. The TLS 1.3 experiment in Chrome will be discontinued on the 19th, at which point this problem disappears, at least for the moment.
    – agl
    Dec 13 '17 at 19:08















up vote
0
down vote










up vote
0
down vote









Certainly, if you have google-chrome stable 63.0.3239.84 or upper, you can get your self-signed certificates working again (in my case, to access my Canon Printer configuration) with the red triangle on the left thorough: chrome://flags, looking for TLS and disabling TLS 1.3.



Instead, you can, of course, regenerate your certificates to be TLS 1.3 compatible.



TLS 1.3 certainly have advantages in security and performance (mainly about the handshake process).



It is worth mentioning that firefox 52.5.0 ESR worked as expected before. No proxy, and navigating, as previously said, my Canon printer in the LAN. It was only a "problem" with google-chrome (64bit) in Linux.






share|improve this answer














Certainly, if you have google-chrome stable 63.0.3239.84 or upper, you can get your self-signed certificates working again (in my case, to access my Canon Printer configuration) with the red triangle on the left thorough: chrome://flags, looking for TLS and disabling TLS 1.3.



Instead, you can, of course, regenerate your certificates to be TLS 1.3 compatible.



TLS 1.3 certainly have advantages in security and performance (mainly about the handshake process).



It is worth mentioning that firefox 52.5.0 ESR worked as expected before. No proxy, and navigating, as previously said, my Canon printer in the LAN. It was only a "problem" with google-chrome (64bit) in Linux.







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 9 '17 at 11:17

























answered Dec 9 '17 at 11:05









Miguel A. RO

11




11








  • 1




    Can you confirm the model and firmware version of the printer with which you're having issues? Another report suggested a PIXMA MX495, but they don't seem to be immediately available. If it also happens with a current model, we'll get one this week and see if we can identify the issue with these devices.
    – agl
    Dec 10 '17 at 3:00










  • It is a Canon Pixma MG3650. I've just upgraded the firmware from the 2.040 to the 2.050 version a few days ago. After that, I regenerated the self-signed certificate but the new one still gives a version mismatch with TLS 1.3 thorough google-chrome. I could generate TLS 1.3 certificates outside the printer and load them to it but I use Gentoo Linux and TLS 1.3 support is still masked (thorough OpenSSL 1.1.0).
    – Miguel A. RO
    Dec 11 '17 at 8:11








  • 1




    Thanks for the details. I don't believe that it's the certificates that are likely to be the problem here. Rather something is likely wrong in Canon's TLS implementation that prevents it from correctly parsing Chrome 63's ClientHello message. For now, you can likely fix this by forcing chrome://flags/#tls13-variant to Disabled. I'm getting a PIXMA printer shipped so that we can investigate this further.
    – agl
    Dec 11 '17 at 17:34












  • Thanks a lot for taking into account user problems. This is the real meaning of Linus Torvalds' motto: "Breaking user programs simple isn't acceptable" even when other like likely Canon in this case seem to be responsable for the problems.
    – Miguel A. RO
    Dec 12 '17 at 18:03






  • 1




    We've found that Canon's TLS stack (which appears to be BSAFE) implements an unofficial TLS extension as extension 40. However, that collides with the key_share extension from TLS 1.3, resulting in this inter-op issue. We've alerted Canon and will let the IETF know. Hopefully the IETF can renumber key_share around this. The TLS 1.3 experiment in Chrome will be discontinued on the 19th, at which point this problem disappears, at least for the moment.
    – agl
    Dec 13 '17 at 19:08
















  • 1




    Can you confirm the model and firmware version of the printer with which you're having issues? Another report suggested a PIXMA MX495, but they don't seem to be immediately available. If it also happens with a current model, we'll get one this week and see if we can identify the issue with these devices.
    – agl
    Dec 10 '17 at 3:00










  • It is a Canon Pixma MG3650. I've just upgraded the firmware from the 2.040 to the 2.050 version a few days ago. After that, I regenerated the self-signed certificate but the new one still gives a version mismatch with TLS 1.3 thorough google-chrome. I could generate TLS 1.3 certificates outside the printer and load them to it but I use Gentoo Linux and TLS 1.3 support is still masked (thorough OpenSSL 1.1.0).
    – Miguel A. RO
    Dec 11 '17 at 8:11








  • 1




    Thanks for the details. I don't believe that it's the certificates that are likely to be the problem here. Rather something is likely wrong in Canon's TLS implementation that prevents it from correctly parsing Chrome 63's ClientHello message. For now, you can likely fix this by forcing chrome://flags/#tls13-variant to Disabled. I'm getting a PIXMA printer shipped so that we can investigate this further.
    – agl
    Dec 11 '17 at 17:34












  • Thanks a lot for taking into account user problems. This is the real meaning of Linus Torvalds' motto: "Breaking user programs simple isn't acceptable" even when other like likely Canon in this case seem to be responsable for the problems.
    – Miguel A. RO
    Dec 12 '17 at 18:03






  • 1




    We've found that Canon's TLS stack (which appears to be BSAFE) implements an unofficial TLS extension as extension 40. However, that collides with the key_share extension from TLS 1.3, resulting in this inter-op issue. We've alerted Canon and will let the IETF know. Hopefully the IETF can renumber key_share around this. The TLS 1.3 experiment in Chrome will be discontinued on the 19th, at which point this problem disappears, at least for the moment.
    – agl
    Dec 13 '17 at 19:08










1




1




Can you confirm the model and firmware version of the printer with which you're having issues? Another report suggested a PIXMA MX495, but they don't seem to be immediately available. If it also happens with a current model, we'll get one this week and see if we can identify the issue with these devices.
– agl
Dec 10 '17 at 3:00




Can you confirm the model and firmware version of the printer with which you're having issues? Another report suggested a PIXMA MX495, but they don't seem to be immediately available. If it also happens with a current model, we'll get one this week and see if we can identify the issue with these devices.
– agl
Dec 10 '17 at 3:00












It is a Canon Pixma MG3650. I've just upgraded the firmware from the 2.040 to the 2.050 version a few days ago. After that, I regenerated the self-signed certificate but the new one still gives a version mismatch with TLS 1.3 thorough google-chrome. I could generate TLS 1.3 certificates outside the printer and load them to it but I use Gentoo Linux and TLS 1.3 support is still masked (thorough OpenSSL 1.1.0).
– Miguel A. RO
Dec 11 '17 at 8:11






It is a Canon Pixma MG3650. I've just upgraded the firmware from the 2.040 to the 2.050 version a few days ago. After that, I regenerated the self-signed certificate but the new one still gives a version mismatch with TLS 1.3 thorough google-chrome. I could generate TLS 1.3 certificates outside the printer and load them to it but I use Gentoo Linux and TLS 1.3 support is still masked (thorough OpenSSL 1.1.0).
– Miguel A. RO
Dec 11 '17 at 8:11






1




1




Thanks for the details. I don't believe that it's the certificates that are likely to be the problem here. Rather something is likely wrong in Canon's TLS implementation that prevents it from correctly parsing Chrome 63's ClientHello message. For now, you can likely fix this by forcing chrome://flags/#tls13-variant to Disabled. I'm getting a PIXMA printer shipped so that we can investigate this further.
– agl
Dec 11 '17 at 17:34






Thanks for the details. I don't believe that it's the certificates that are likely to be the problem here. Rather something is likely wrong in Canon's TLS implementation that prevents it from correctly parsing Chrome 63's ClientHello message. For now, you can likely fix this by forcing chrome://flags/#tls13-variant to Disabled. I'm getting a PIXMA printer shipped so that we can investigate this further.
– agl
Dec 11 '17 at 17:34














Thanks a lot for taking into account user problems. This is the real meaning of Linus Torvalds' motto: "Breaking user programs simple isn't acceptable" even when other like likely Canon in this case seem to be responsable for the problems.
– Miguel A. RO
Dec 12 '17 at 18:03




Thanks a lot for taking into account user problems. This is the real meaning of Linus Torvalds' motto: "Breaking user programs simple isn't acceptable" even when other like likely Canon in this case seem to be responsable for the problems.
– Miguel A. RO
Dec 12 '17 at 18:03




1




1




We've found that Canon's TLS stack (which appears to be BSAFE) implements an unofficial TLS extension as extension 40. However, that collides with the key_share extension from TLS 1.3, resulting in this inter-op issue. We've alerted Canon and will let the IETF know. Hopefully the IETF can renumber key_share around this. The TLS 1.3 experiment in Chrome will be discontinued on the 19th, at which point this problem disappears, at least for the moment.
– agl
Dec 13 '17 at 19:08






We've found that Canon's TLS stack (which appears to be BSAFE) implements an unofficial TLS extension as extension 40. However, that collides with the key_share extension from TLS 1.3, resulting in this inter-op issue. We've alerted Canon and will let the IETF know. Hopefully the IETF can renumber key_share around this. The TLS 1.3 experiment in Chrome will be discontinued on the 19th, at which point this problem disappears, at least for the moment.
– agl
Dec 13 '17 at 19:08












up vote
0
down vote













See if you can fix this error by applying three solutions:




  • Reverse your recent changes in the proxy settings

  • Disable TLS 1.3 from chrome flag settings

  • Uncheck Automatic Detect option from Internet Options > Internet Properties > LAN Settings > Connection


One of above solution will surely fix ssl version error on your pc.






share|improve this answer





















  • To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
    – JUNED MEMON
    Nov 10 at 8:37















up vote
0
down vote













See if you can fix this error by applying three solutions:




  • Reverse your recent changes in the proxy settings

  • Disable TLS 1.3 from chrome flag settings

  • Uncheck Automatic Detect option from Internet Options > Internet Properties > LAN Settings > Connection


One of above solution will surely fix ssl version error on your pc.






share|improve this answer





















  • To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
    – JUNED MEMON
    Nov 10 at 8:37













up vote
0
down vote










up vote
0
down vote









See if you can fix this error by applying three solutions:




  • Reverse your recent changes in the proxy settings

  • Disable TLS 1.3 from chrome flag settings

  • Uncheck Automatic Detect option from Internet Options > Internet Properties > LAN Settings > Connection


One of above solution will surely fix ssl version error on your pc.






share|improve this answer












See if you can fix this error by applying three solutions:




  • Reverse your recent changes in the proxy settings

  • Disable TLS 1.3 from chrome flag settings

  • Uncheck Automatic Detect option from Internet Options > Internet Properties > LAN Settings > Connection


One of above solution will surely fix ssl version error on your pc.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 10 at 8:36









JUNED MEMON

11




11












  • To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
    – JUNED MEMON
    Nov 10 at 8:37


















  • To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
    – JUNED MEMON
    Nov 10 at 8:37
















To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
– JUNED MEMON
Nov 10 at 8:37




To refer to detail step by step solution you can refer to https://wildtricks.com/chrome/err_ssl_version_interference/
– JUNED MEMON
Nov 10 at 8:37





protected by Community Nov 22 at 12:11



Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



Would you like to answer one of these unanswered questions instead?



Popular posts from this blog

QoS: MAC-Priority for clients behind a repeater

Ивакино (Тотемский район)

Can't locate Autom4te/ChannelDefs.pm in @INC (when it definitely is there)