Cypress: 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:

https://github.com/cypress-io/cypress/issues/392#issuecomment-274987217

[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. 👍

[bskrtich]

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 :+1: 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.

[alexhvastovich]

I am having the same issue when trying to run tests on a remote company server, that QA doesn't have control over. Any update on the fix?

[SecondFlight]

Have you attempted the workaround above?

[sborland]

Has there been any update on this? The workaround works for us but it would be nice to not have to edit the hostfile to point to different ip addresses.

[reno1979]

Same here, using a self signed certificate and a client on which we can not edit the hosts file ...

[MatteoGioioso]

My domain is https://env.name.com. Cypress will start normally but then it will just redirect to the page simply stop.
Anybody is having the same experience? None of the workaround above is working for me.

[lakiefer]

Is there something new about this issue?

[reno1979]

Any updates on this?? Our product is going to use Workers, and because we can’t seem Cypress to run our secure site, the workers are not loaded.

[flotwig]

We added full support for proxies and improved HTTPS reliability in the latest version of Cypress (3.3.1). Is anyone still experiencing issues from this thread after upgrading?

[SecondFlight]

@flotwig I am still experiencing an issue with self-signed certificates in 3.3.1. When hitting an endpoint with HTTPS that signs its own certificates, we get this error, which is the same behavior as before:

[flotwig]

@SecondFlight Can you share a screenshot of chrome://policy in the Cypress browser? We disable SSL verification in the browser so that Chrome will accept Cypress's self-signed certs, but it seems like a system policy could be overriding this behavior for you. If that's not it, than this is probably related to us trying to sign a cert for an IP address.

[SecondFlight]

@flotwig Doesn't look like we have anything there:

[flotwig]

Hey @PWAlessi, that looks like a different issue than what's being tracked here (not being able to visit IP addresses via SSL), so let's move discussion to a new issue: #4394

[PWAlessi]

Hey @PWAlessi, that looks like a different issue than what's being tracked here (not being able to visit IP addresses via SSL), so let's move discussion to a new issue: #4394

I've deleted my original comment. Thanks for creating a new issue for this!

[ditek]

@flotwig I have just encountered this issue as well.

Platform: win32 (10.0.18362)
Cypress Version: 3.4.1

Tell me if you need any other logs.

[plutov]

II am having same issue when doing:

cy.visit('https://12traits.com/')

However this site works well in browser (SSL is issued by Let's Encrypt).

[jennifer-shehane]

@plutov I'm not able to recreate an error with the test provided. What is displaying on your screen when you run this visit? What version of Cypress are you using (please try latest)? Any PROXY settings?

[plutov]

@jennifer-shehane it's interesting, I found that it doesn't work with all Let's Encrypt certificates. I changed to RSA-2048 and it started to work! Thanks for checking it!

[flotwig]

@plutov Potentially related:

• #4368 - ECC ssl certificates not working
• #4394 - write EPROTO: SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure when visiting https site

[ditek]

I have an interesting observation. If I try to visit localhost first cy.visit('localhost'), I would be able to open a new tab and go to a remote host with a self-signed certificate without getting the SSL error.
However, when I call cy.visit('https://10.10.16.150') for example, I get the SSL error.

[SecondFlight]

@ditek That lines up with what others have fuond. You should be able to create an alias for 10.10.16.150 in your hosts file to get around this issue - see this comment for instructions.

[ditek]

@SecondFlight I'm aware of the workaround, but maybe you misunderstood my comment. If I do cy.visit('localhost'), I am magically able to access https://10.10.16.150 in the browser without the complaint about the self signed certificate.

Sorry if this is a known thing, but I haven't noticed any mention of it.

[SecondFlight]

Ah yes, I misread your comment. Thanks for clarifying!

[vambasta]

@ditek . Just to check . has the issue been resolved in the latest release of Cypress 3.4.1 ? Cos i still get the issue in present release.

[ditek]

@vambasta I am using the latest release and still have the issue

[vambasta]

@vambasta I am using the latest release and still have the issue

Thanks for confirmation

[mtc3bmtc3b]

Interesting tidbit that may be of use... I run into this problem if I follow the best practice of putting a baseUrl in cypress.json. However, if I cy.visit() or cy.request() using the full URL, I don't. That is, cy.visit('https://127.0.0.1:8443/home') works. Well, until I added auth to my app, then it breaks again. cy.request() still works this way, but that doesn't help much. I'm running version 3.4.1.

[flotwig]

@mtc3bmtc3b Yeah, the issue occurs only when Cypress intercepts the domain, which happens whenever there is a cy.visit. #4947 is awaiting review and contains a fix to the issue.

[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]

https://github.com/cypress-io/cypress/issues/771#issuecomment-527771326

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[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[bot]]

Released in 3.5.0.