cy.visit secure error when _ used in hostname

[MikePopov]

Current behavior:

When I try to visit my app, which located in JenkinsCI, I encounter an error:

This site can’t provide a secure connection someadresss.tk doesn't adhere to security standards.
ERR_SSL_SERVER_CERT_BAD_FORMAT

When I put URL in the browser app open, this error only in Cypress sandbox

Versions

Operating System: Ubuntu 16.04
Cypress Version: 3.1.3
Browser Version: Chrome 70

[masiulis]

Could you try setting "chromeWebSecurity": false in cypress.json?

You can always set other flags directly #715 (comment), but I think disabling chromeWebSecurity should work in your case.

[MikePopov]

I did this first

but it did not help

[alexbridge]

We also have same issue with wildcard certificate, issued by Letsencrypt, when we try to run tests against subdomain.

After researches, found out, that underscore _ in subdomain name produced this error with Electron browser.
Switching to subdomain with hyphen - instead, fixed issue.

[jennifer-shehane]

@alexbridge Thanks so much for leaving a comment!

This does appear to be the root of the issue. I believe this is a legitimate error due to _ being used in the hostname, which is invalid as described in RFC 952

A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period. A host which serves as a GATEWAY should have
"-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as
Internet gateways should not use "-GATEWAY" and "-GW" as part of
their names. A host which is a TAC should have "-TAC" as the last
part of its host name, if it is a DoD host. Single character names
or nicknames are not allowed.

[laerteneto]

I just wanna say that the _ was the issue for my problem. After hours, I found this simple solution in here.
So, the URL was adapted and now I can move on.
Thanks :)

@alexbridge Thanks so much for leaving a comment!

This does appear to be the root of the issue. I believe this is a legitimate error due to _ being used in the hostname, which is invalid as described in RFC 952

A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period. A host which serves as a GATEWAY should have
"-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as
Internet gateways should not use "-GATEWAY" and "-GW" as part of
their names. A host which is a TAC should have "-TAC" as the last
part of its host name, if it is a DoD host. Single character names
or nicknames are not allowed.

[DuncanHills]

@jennifer-shehane underscores are perfectly valid in sub-domains, which is the reported issue, and also one we encountered. Underscores are not valid in hostnames, but that should be obvious because no one would be able to get a hostname on a network or in a registered domain. A concise summary of the distinction can be found here: https://stackoverflow.com/a/2183140

Can this issue be re-opened?

[jennifer-shehane]

@DuncanHills Do you have a situation where an underscore in the subdomain is causing an error? Can you give more detail?

[DuncanHills]

@jennifer-shehane a Cypress test harness is getting cert errors when used against with a subdomain that contains underscores, covered by a public wildcard cert. I can follow up with more details soon.

[Benjaminhu]

+1 We ran into the same problem. (wildcard certificate, and underscore _ in subdomain name)

[AshrafShaik001]

@Benjaminhu Did you find any solution?

[Benjaminhu]

@AshrafShaik001 Yes, we changed the name of the host (fortunately, the developer address only).

[coy123]

+1 Just encountered this issue.

According to this: https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it
subdomains can have underscore(_).

This should be fixed. Until it is fixed, I am forced to change the url, which is not ideal.

[MiguelTolosa]

This just blocked the company I work at from being able to implement cypress at all. We can't change subdomain names that have an underscore, and subdomains with an underscore are valid. This issue needs to be addressed.

[jennifer-shehane]

The RFC has a preferred name syntax outlined here.

Note that while upper and lower case letters are allowed in domain
names, no significance is attached to the case. That is, two names with
the same spelling but different case are to be treated as if identical.

The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.

Additionally SSL certs are no longer issued to subdomains with underscores for this exact reason. See this link.

It's clearly strongly recommended to not use underscores in subdomains, but it is not uniformly enforced across browsers.

We haven't personally spent time to look into why this is not working, but would be open to a pull request that allows URLs with underscores to display as they would in a normal browser.

Example test

it('runs', () => {
  cy.visit('https://my_sarisari_store.typepad.com/');
});

[cypress-app-bot]

This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.

[laerteneto]

I can confirm the issue persists. We changed our subdomains to overcome it, but it would be nice if Cypress could handle this natively.