cypress: cy.visit() results in ERR_SSL_VERSION_OR_CIPHER_MISMATCH

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.

@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

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

Released in 3.5.0.

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.

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

1. Change your cy.visit command to

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

And you should be good to go! 😃

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))

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.

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

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

@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

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

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

@plutov Potentially related:

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

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

@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!

@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

@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.

@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.