cy.visit() results in ERR_SSL_VERSION_OR_CIPHER_MISMATCH

[jennifer-shehane]

Is this a Feature or Bug?

Bug

Current behavior:

In some circumstances, users encounter this error when visiting their application:

This site can't provide a secure connection
xxx uses an unsupported protocol
ERR_SSL_VERSION_OR_CIPHER_MISMATCH

If you encounter this bug, please try to paste any test code or information you can below as we have been unable to reproduce this issue.

Theory
The problem is likely the way the user's server is self signing the cert and it is confusing the Cypress proxy, which ultimately confuses the browser.

[jennifer-shehane]

Issues from gitter:
https://gitter.im/cypress-io/cypress?at=5996055576a757f808b65217
https://gitter.im/cypress-io/cypress?at=59bbfd21210ac26920361246
https://gitter.im/cypress-io/cypress?at=59e7ccdcd6c36fca316b4ce1

[radiovisual]

@jennifer-shehane , I believe I am having this same issue. If you don't think this is related, I can open a new issue.

I am using Cypress 1.0.3 on MacOS 10.13

It doesn't matter if I set "chromeWebSecurity" to true or false, when I try to run this test code:

describe('Should allow Chrome Extension to be injected', function() {
    beforeEach(function(){
        cy.visit('https://github.com/willklein/github-markdown-menu');
    });

    it('.should() - do something', function () {
        expect(true).to.equal(false);
    });
});

Instead of getting the expected assertion failure, Cypress tells me that there isn't any tests to run (after it tries to visit the url)

But if I change the URL to a domain that doesn't require https, then the test fails as expected:

describe('Should allow Chrome Extension to be injected', function() {
    beforeEach(function(){
        cy.visit('http://mrdoob.com');
    });

    it('.should() - find the extension', function () {
        expect(true).to.equal(false);
    });
});

[brian-mann]

@radiovisual the issue you're having is not related to the one that @jennifer-shehane opened.

Additionally, your issue has nothing to do with https as well. Https works just fine in Cypress. A quick test with cy.visit('https://example.com') proves that.

The problem that you're showing is that Github has security mechanisms in place that defeat the automation capabilities of Cypress. This has been documented and talked about on here many many times. When you visit Github these security features are redirecting Cypress. The code looks as simple as this:

if (window.top !== window.self) {
  window.location.back()
}

However, this problem is simple to work around. You shouldn't be testing sites that you don't control. Test your own applications - and if your own applications have these security mechanisms then you should disable them while in testing environment.

[brian-mann]

Here's a much more comprehensive answer that I've given for this exact scenario:

#392 (comment)

[radiovisual]

Thanks @brian-mann, I only put that test code up there as an example, but I do understand the importance of only testing apps that are under your control, I was trying to prepare a simpler test case to demonstrate the problem in #876, but then when it wouldn't run my simple use case, I ran into a problem that felt a lot like this issue, but yes, now I see that they are different.

Anyway, thanks for the input. 👍

[hskrtich]

I have made a small repo with a docker image that will setup apache with a self signed ssl cert that shows this error.

https://github.com/bskrtich/cypress-ssl-mismatch

Let me know if you have any questions.

[brian-mann]

@bskrtich oh thank you. this should be enough to figure it out.

[Graham42]

Does anyone have a workaround for this?

[jennifer-shehane]

@radiovisual Some updates to frame-busting changes we're making can be read here: #886

[zhnli]

This issue still exists in 2.0.0. It's a show stopper for us.

[joshdk]

I did some additional digging into what causes this issue, and it appears that this is triggered specifically by using cy.visit() to visit an IP address over HTTPS, where the resource returns a 200 OK status code with a content-type of text/html.

Inspired by @bskrtich's example, I have created joshdk/cypress-ssl-repro as a minimal repro with documentation.

Additionally, I had some observations while testing:

• Using the cy.request() function never caused this behavior.
• Changing the SSL certificate CN had no impact.
• Changing the Nginx server_name had no impact.
• Changing the Nginx ssl_protocols or ssl_ciphers had no impact.
• Changing the listening Nginx/Docker port had no impact.

I hope that this helps folks resolve the issue!

• Operating System: macOS High Sierra (Version 10.13.2 (17C88))
• Cypress Version: 2.0.0
• Browser Version: Chrome 64 - (64.0.3282.167 (Official Build) (64-bit))

[jennifer-shehane]

@joshdk This is great! I forked your repo and added the cypress tests so we can get it up and running more quickly.

In https://github.com/cypress-io/cypress-ssl-repro

• make sure you have docker running.
• run npm start
• run npm test

[anurbol]

I am also having this problem:

• self-signed certificates
• baseUrl: https://127.0.0.1
• both on Windows 7 and Linux (Debian 9.4)
• chrome

Seems that it is not a big problem, because switching from https://127.0.0.1 to http://127.0.0.1 fixes it. Do I have to worry? There should not be any differences between https/http in app behavior, am I correct?

[joshsleeper]

@anurbol
i'd say that changing the url to simply be insecure isn't an appropriate resolution.
if you're shipping a site or app designed to be accessed over https, testing it only over http really doesn't seem ideal.

the correct workaround for now iirc is switching https://127.0.0.1 to https://localhost, which works as expected.

[anurbol]

@joshsleeper Thanks for reply and your opinion 👍 I got https worked by using vhosts (https://myhost.lc instead of https://127.0.0.1).

[silversteez]

I'm having this problem as well and am stuck.

• self-signed cert via openssl
• most recent certificate created by running openssl req -newkey rsa:2048 -x509 -nodes -keyout apache.key -new -out apache.crt -subj /CN=172.16.0.100 -reqexts SAN -extensions SAN -config <(cat /etc/ssl/openssl.cnf <(printf '[SAN]\nsubjectAltName=DNS:172.16.0.100,IP:172.16.0.100')) -sha256 -days 3650
• url is https://172.16.0.100/
• served from apache inside docker inside virtualBox vm
• on Mac Os 10.12.5

Would love to push this tool at my org, but need some kind of solution or workaround...

[brian-mann]

@silversteez try setting your hosts file to point something named to 172.16.0.100

[silversteez]

@brian-mann Happy to report that that worked! I added 172.16.0.100 testing to local hosts file. When visiting https://testing/, Chrome no longer thinks the certificate I generated is valid, though it still associates the 172.16.0.100 cert with the "testing" domain. The Cypress Chrome instance shows the domain as insecure now, but doesn't seem to be bothered.

[anurbol]

@brian-mann In my opinion you can for sure close this issue, because solution is known and confirmed working:
in case of local testing using self-signed SSL certificates, do not use IP-based hosts e.g. https://127.0.0.1, but use named host (virtual host) instead e.g. https://localhost or https://myapp.lc.

P.S. I wanted to contribute to docs (https://docs.cypress.io/guides/references/error-messages.html#Browser-Errors) but my lack of english and contributing skills would not let me do that without worsening docs quality :) but maybe @jennifer-shehane may help

[joshsleeper]

@anurbol
I strongly disagree with that stance.
Just because a workaround is known and works hardly means that the issue (and it is an issue) is resolved.

[anurbol]

@joshsleeper Yours is definitely more responsible and correct way of dealing with issues, I agree. However it seems that it is not an issue of cypress, but rather of chrome, because manually opening website in chrome with https protocol and self-signed certs and ip as host gives you the same error. Therefore I doubted cypress team can do anything with this. That just what I was thinking, but you definitely have more experience, sorry for my probably monkey-patching-ish proposal :-)
P.S. I love cypress, wonderful software, the team is incredible! People should learn from you

[joshsleeper]

@anurbol
Sorry if that came off harsh, I've just had lots of experience with the open-source community at large eagerly closing issues such that they never actually get resolved!

If you're correct (which I'm thinking you might very well be) and it's truly a Chrome issue, it seems like the correct behavior from Cypress' side is to either:

• present an appropriate warning that explains what's wrong
• implement a workaround such that it works as expected

Currently, the way things fail there's no hint of any kind as to who's problem it is, which was the main frustration here. Coping with browser limitations/bugs like this is A-OK, but it'd be much nicer to know what the actual issue is and how to work around it without having to chase down github issues. ;)

Again, sorry for coming off like a punk, I didn't mean any harm. Just strong willed about eager-closing of issues is all!

[anurbol]

@joshsleeper :) that's a good points and principles, thanks for sharing them! Also, I don't mind for that kind of "harsh" as long as is it's on point, it saves time and reduces reading and that's important :-)

[SecondFlight]

I am experiencing this issue when connecting to a local web server via IP that has a self-signed certificate.

I'm happy to say, the workaround suggested by @brian-mann worked for me. I didn't pick up on it when skimming through this earlier, so here are the steps for Windows:

1. Open your hosts file, located in C:\Windows\System32\drivers\etc, in an editor with elevated privileges.
2. Add the following line, replacing the IP with your IP and website name with whatever you want:

123.45.67.89 some.website.com

3. Change your cy.visit command to

cy.visit('some.website.com');

And you should be good to go! 😃

[brian-mann]

It is actually on us (Cypress responsibility) to correctly handle ip addresses that are using a self signed cert. We don't, and that's why this error propagates out.

The workaround is assigning a virtual host to it due to the way we handle SNI, but we should be able to also handle the ip address.

[vambasta]

@brian-mann ..the workaround is working locally i.e. by mapping DNS to ip in /etc/hosts but when using docker + circleCi , can u pls tell how to map inside a container run by CI to manage /etc/hosts..

[SOMIASHARMA26]

I am beginner. Try to access IP address.

Getting error

This site can't provide a secure connection
xxx uses an unsupported protocol
ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

How I can handle this error

[vambasta]

I am beginner. Try to access IP address.

Getting error

This site can't provide a secure connection
xxx uses an unsupported protocol
ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

How I can handle this error

Not sure for this . But I kinda used the workaround mentioned in the trailing msgs . u can try that out.

[SOMIASHARMA26]

#771 (comment)

I tried all solution mentioned in trailing msgs.

[vambasta]

#771 (comment)

I tried all solution mentioned in trailing msgs.

I mapped the DNS for the VM in the /etc/hosts in mac and it worked both locally and in docker

[SOMIASHARMA26]

I don't have permission to mapped the DNS. Is other option

[SOMIASHARMA26]

@vambasta

I mapped DNS now I am getting
Error getaddrinfo enotfound

[vambasta]

getaddrinfo enotfound

The error generally comes when node.js canot find the server from DNS . We u map the DNS , did u use the same dns to refer to the IP ?
Also if using chrome try disabling chromesecurity in cypress.json and possibly use some flakes for the server.

[cypress-bot]

The code for this is done in cypress-io/cypress#4947, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

[cypress-bot]

Released in 3.5.0.