Cypress can't connect to local HTTPS in 7.4.4

[steveworkman]

Hi, we we ran into this problem today where cypress in CI could no longer connect to a local HTTPS vite app with the NODE_TLS_REJECT_UNAUTHORIZED: 0 environment variable. We are running Node 24.20.0

Note, downgrading to 7.4.3 fixed this issue, so the root cause it likely to be the fix for #1869

Run cypress-io/github-action@v7
  with:
    start: npm run preview
    wait-on: https://localhost:8080/root/user/settings/
    wait-on-timeout: 180
    record: false
    browser: chrome
    component: false
    package-manager-cache: true
    publish-summary: true
  env:
    GITHUB_TOKEN: ***
    NODE_TLS_REJECT_UNAUTHORIZED: 0
    SPLIT: 3
    SPLIT_INDEX: 0
(node:2151) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
(Use `node --trace-warnings ...` to show where the warning was created)
.....
  ➜  Local:   https://localhost:8080/root/user/settings/
https://localhost:8080/root/user/settings/ timed out after 21 retries, elapsed 223214ms, limit 210000ms
Error: self-signed certificate; if the root CA is installed locally, try running Node.js with --use-system-ca

[MikeMcC399]

Thanks for your report! Issue sindresorhus/got#2177 indicates that this was a breaking change in got@12, and we have just had to upgrade to got@16 to fix #1873 occurring in Node.js >=24.20.0. got@11 is no longer supported, and therefore there was no fix available for this version to allow it to work with Node.js >=24.20.0.

Under normal circumstances, since cypress-io/github-action@v7.4.4 turns out to be a breaking change for your set up, we should revert the commit that upgraded to got@16 #1874 and release a new v7 version. That would however mean that @v7 action users of the simple form of the wait-on parameter on GitHub-hosted runners would find it stops working when the GitHub runner is updated to Node.js >=24.20.0, probably some time later this month.

Suggestions

See https://github.com/cypress-io/github-action#wait-on

1. Use the wait-on package:

 wait-on: "npx wait-on --timeout 60000 https://localhost:8080/root/user/settings/"

2. Let your localhost server expose also http so that you can do an availability check using:

wait-on: http://localhost:8080/root/user/settings/

3. Consider if you can have your vite app use only http for testing purposes

   This would correspond to the example https://github.com/cypress-io/github-action/tree/master/examples/wait-on-vite which is tested in https://github.com/cypress-io/github-action/blob/master/.github/workflows/example-wait-on.yml

Note

The Node.js CLI documentation states:

NODE_TLS_REJECT_UNAUTHORIZED=value

If value equals '0', certificate validation is disabled for TLS connections. This makes TLS, and HTTPS by extension, insecure. The use of this environment variable is strongly discouraged.

[MikeMcC399]

You may also try removing the wait-on parameter completely. Cypress is tolerant of a slightly slower server startup, and it may work without explicitly waiting.

[steveworkman]

Thanks for the quick response.

We need to use HTTPS for the dev server due to the app code performing OAUTH logins and all redirect origins must be HTTPS so even localhost has to be on that protocol, even if we then unsafely ignore the certificate.
I will give wait-on a go, as this is clearly not going to be fixed upstream

[MikeMcC399]

I was able to reproduce the issue after modifying the vite example to use https.

Creating a self-signed certificate and making it known through NODE_EXTRA_CA_CERTS, instead of trying to bypass a missing certificate with NODE_TLS_REJECT_UNAUTHORIZED, seems to allow this to work.

I'm not experienced in this area though, so I can't say if that would be appropriate for your environment.

[yhy-1]

We are also experiencing the same issue in our company. Will this be fix or do we also need to implement the wait-on workaround? @MikeMcC399

[MikeMcC399]

@yhy-1

I'm sorry that you've also been impacted! Unfortunately we don't have the option to keep the action the way it was previously, so the comments I have given to @steveworkman apply to other users as well.

Node.js is not going to revert the change they made in Node.js 24.20.0 and got is no longer supporting the got@11 version we were previously using.

You can try the workarounds, or you can provide a self-signed certificate through NODE_EXTRA_CA_CERTS.

If there are many reports of this issue I would propose to add an example of vite with https so it's clear how it can work.

[steveworkman]

@MikeMcC399 I've tried the solutions that you've provided:

• We were already using the wait-on parameter in our yaml

      - name: Cypress run
        uses: cypress-io/github-action@v7.4.4
        with:
          wait-on: "https://localhost:8080/root/user/settings/"
          wait-on-timeout: 180

This fails to connect in 7.4.4 - it connects in 7.4.3 with the NODE_TLS_REJECT_UNAUTHORIZED flag that is now rejected because of the got update

• We have tried using a self-signed certificate. The vite project uses https://github.com/vitejs/vite-plugin-basic-ssl and we now expose the certificate that it creates. We pass that to the NODE_EXTRA_CA_CERTS environment variable for the cypress action, but the server still does not connect to the server.

We now don't have a choice:

• stick with version 7.4.3 of this action and continue on HTTPS
• Use HTTP in development

I don't think this is a patch change in this action, it's a full breaking change. Self-signed certs are no longer supported

[MikeMcC399]

@steveworkman

Did you also try the following?

1. Use the wait-on package:

 wait-on: "npx wait-on --timeout 60000 https://localhost:8080/root/user/settings/"

This is independent of got. Even though it uses the same text, wait-on executed by npx is calling the separate package wait-on from the npm registry.

[steveworkman]

@steveworkman

Did you also try the following?

1. Use the wait-on package:

wait-on: "npx wait-on --timeout 60000 https://localhost:8080/root/user/settings/"
This is independent of got. Even though it uses the same text, wait-on executed by npx is calling the separate package wait-on from the npm registry.

Yes, I get the same error, it can't connect