Cypress invalid proxy certificate affects disk cache

[jsantha]

Current behavior:

Information that certificate error is purely cosmetic problem as specified here docs.cypress.io/faq/questions/using-cypress-faq.html is misleading.

Chrome, as reported here bugs.chromium.org/p/chromium/issues/detail?id=110649 ignores http caching when any error with ssl certificate occurs. This means that the application under the test is affected and not behaving as intended (http caching is fully disabled, app load time can be significantly slower...).

Desired behavior:

1) Inform about this potential problem in FAQ 2) Maybe inform that this problem can be resolved by importing CypressProxyCA from cy/production/proxy/certs/ca.pem to the Trusted Root Certification Authority store

Test code to reproduce

https://github.com/jsantha/cypress-invalid-cert

Versions

Chrome from version ~16 to actual (81) Windows 10 Cypress 4.5.0

[flotwig]

This means that the application under the test is affected and not behaving as intended (http caching is fully disabled, app load time can be significantly slower...).

Have you been able to observe this behavior in Cypress? I have not noticed cache behaving oddly, but it's possible I have not been working on enough HTTPS stuff to see it. We do pass arguments to Chrome to force them to permit invalid certs, so it could also be affecting this behavior.

I ask because this comment seems to imply that caching DOES work, but it is in-memory, not written to disk.

---

Maybe inform that this problem can be resolved by importing CypressProxyCA from cy/production/proxy/certs to the Trusted Root Certification Authority store

Hmm, this would technically work, but some users will not want Cypress to touch their CA store. Also, this will probably break in any managed environment with antivirus/GPO setups that prevent malicious CAs being installed.

It would be a security issue too. Although the test runner's CA keys are not shared pubicly (they are generated locally per-computer and cached), it's possible that malware on a user's computer could read the CA file and use it to intercept HTTPS traffic without the user's knowledge (if Cypress were added to the CA store)

[jsantha]

I ask because this comment seems to imply that caching DOES work, but it is in-memory, not written to disk.

Quick peek into chromium source code shows that this behavior (cache not work with invalid cert) is intended and cannot be prevented with browser arguments: /net/http/http_cache_transaction.cc

Anyway, I have made a quick test:

Chrome 81 Windows 10 Cypress 4.5.0

1) invalid certificate = no caching

2) trusted certificate = caching works as expected

Our application leverages http caching for some quite heavy REST API calls and since I have rewritten some of our e2e tests from Selenium to Cypress, I have immediately noticed that Cypress test cases run much slower than those running via Selenium.

It would be a security issue too. Although the test runner's CA keys are not shared pubicly (they are generated locally per-computer and cached), it's possible that malware on a user's computer could read the CA file and use it to intercept HTTPS traffic without the user's knowledge (if Cypress were added to the CA store)

I'm not really familiar with internal working of those certificates and theirs potential security issues but we could perhaps inspire at .NET Core SDK that provides a CLI option to make its own development certificate trusted Trust the ASP.NET Core HTTPS development certificate on Windows and macOS and in addition, we could inform users about the potential security risk you mentioned.

[jennifer-shehane]

Can you provide the full repo/code for your reproduction of the caching issue?

I was not able to verify the behavior that caching is effected from within Cypress when SSL certificate errors are present.

The cache is cleared in Cypress before each run of a spec file. So there will not be any caching on the first run of a test, but the subsequent runs of tests, resources should be cached.

You can observe this with the following test:

it('test', () => {
 cy.visit('https://reactjs.org/docs/getting-started.html')
});

it('test2', () => {
 cy.visit('https://reactjs.org/docs/getting-started.html')
});

When looking at the network tab (filtering by Img), the first test has the 'search.svg' with a 200 status. The second test, the request has the 'search.svg' return as status 304 Not Modified. It is returning with the cached image.

[jsantha]

@jennifer-shehane You have chosen wrong file to check caching, the search.svg has max-age=0 and utilizing etag - this request always hits the server but skips response download when etag matches (304). I created a disk cache scenario here https://github.com/jsantha/cypress-invalid-cert

[jennifer-shehane]

Yeah, it does seem that the invalid certificate will affect disk cache. Thanks for providing the repo.

We could maybe fix this by implementing the certificate override at the remote debugger protocol level (if Chromium’s comment is true).

[MichelleSNG20]

I am using cypress 7.1 and facing this invalid certificate issue.

Should I take this as solution "Maybe inform that this problem can be resolved by importing CypressProxyCA from cy/production/proxy/certs to the Trusted Root Certification Authority store"

Can anyone please advise how to access this 'cy/production/proxy/certs'? thanks

[valter11111]

I agree with the original post, this is not only the cosmetic problem. Chromium browsers also block webRTC access (media devices are disabled) if there is "Not secure" connection.

Using Cypress 7.3

[valter11111]

@jsantha

2. Maybe inform that this problem can be resolved by importing CypressProxyCA from cy/production/proxy/certs to the Trusted Root Certification Authority store

I tried this solution, but certificate

But chrome still suggests its "Not secure" connection.

[jsantha]

@valter11111 I've just tried this workaround again for latest cypress version and it still works, follow these steps:

• import AppData/Roaming/Cypress/cy/production/proxy/certs/ca.pem
• restart chrome (check for no background chrome processes in task manager)
• run tests again and invalid cert warning should disappear

[sara444]

@valter11111 I've just tried this workaround again for latest cypress version and it still works, follow these steps:

• import AppData/Roaming/Cypress/cy/production/proxy/certs/ca.pem
• restart chrome (check for no background chrome processes in task manager)
• run tests again and invalid cert warning should disappear

In addition to the above steps, you also need to clear the Site Settings, Data etc using Ctrl+Shift+Delete (on windows) while chrome is openned via Cypress. Otherwise, chrome keeps caching the trust (untrusted certificate) as usual.

[karlamieses]

• AppData/Roaming/Cypress/cy/production/proxy/certs/ca.pem

how can I import AppData/Roaming/Cypress/cy/production/proxy/certs/ca.pem @valter11111

[flotwig]

This should no longer be an issue on the latest version of Cypress, is anyone experiencing this on 10.1.0?

[karlamieses]

This should no longer be an issue on the latest version of Cypress, is anyone experiencing this on 10.1.0?

I having the following issue with Cypress latest versions when running in the CI, I thought this is related to the issue we are talking here, what do you think?

[1119:0616/211249.791930:ERROR:cert_verify_proc_builtin.cc(681)] CertVerifyProcBuiltin for dashboard.stripe.com failed:
--
620 | ----- Certificate i=0 (OU=Cypress Proxy Server Certificate,O=Cypress Proxy CA,L=Internet,ST=Internet,C=Internet,CN=dashboard.stripe.com) -----
621 | ERROR: No matching issuer found

[shammlo]

@flotwig, my Cypress version is "cypress": "^10.8.0", and im still having this error, still receiving "Not secure".

[andrii-lundiak]

I've recently migrated from Cypress v7.x to v9.7.0 and this issue (ERROR: No matching issuer found) happens on my CI only (Azure, Ubuntu). Sometimes it's NOT happening.

I read a few threads and it seems issue was fixed in v10.2.0 which I anticipate to upgrade yet. @MichaelDimmitt refers here: https://github.com/cypress-io/cypress/discussions/22128

But I also see that @shammlo refers above to v10.8.0 as also not working version.

@jsantha, as author of this issue which is still open in Jan-2023, how about you?

[awerlang]

@flotwig @karlamieses @andrii-lundiak I believe the issue you have in mind is unrelated (ERROR: No matching issuer found)

If Cypress could import the ca.pem file automatically, it would improve the experience running on the cloud.

[amenk]

• Would it work to deploy an own valid certificate via https://docs.cypress.io/guides/references/client-certificates or does client certificates really mean client here and has no effect on the cypress proxy-server?
• What is the path of AppData/Roaming/Cypress/cy/production/proxy/certs/ca.pem on Linux? ** EDIT: it's ~/.config/Cypress/cy/production/proxy/certs/ca.pem
• It can be imported at chrome://settings/certificates -> Authorities in any chrome instance (it seems to be globally trusted than even Cypress uses another User Profile)
• I can confirm that importing that certificate solves the cache Problems in Cypress with Chrome 113

[nagash77]

Are folks on this thread still experiencing this issue on the latest version of Cypress?

[amenk]

We see the issue in Cypress 12.11.0

[martin-pikalek]

Importing CA certificate solved caching issue for me for local testing but could someone help me, how could I import same certificate in CICD within cypress docker image environment?

Also could be this solved somehow globally within cypress app @jennifer-shehane ? Seems that this issue is known for nearly 3 years and disabled disk cache may quite hard affect testing speeds for apps where developers intentionally utilise browser client cache to speed up loading of assets and reduce HTTP traffic.

[amenk]

@martin-pikalek maybe something like this could work https://thomas-leister.de/en/how-to-import-ca-root-certificate/ And yes, it would be good if this would be in the cypress/browsers docker images.

[amenk]

The Chrome Cert file to import to seems to be /root/.pki/nssdb/cert9.db I am wondering if Cypress' ca.pem is always generated freshly and we need to import it after running cypress the first time or we could incude it statically in the Docker image.

EDIT: I am trying to prepend something like this to my run command:

        - docker-compose run cypress "yarn cypress install && apt update && apt install -y libnss3-tools && certutil -A -n Cypress -t 'TCu,Cu,Tu' -i /root/.config/Cypress/cy/production/proxy/certs/ca.pem -d sql:/root/.pki/nssdb/ && yarn cypress run --browser $BROWSER --spec cypress/e2e/index.cy.js"

but getting

certutil: function failed: SEC_ERROR_BAD_DATABASE: security library: bad database.

Also we might need to run cypress with an empty spec at first to generate the pa.pem

EDIT2: I have to remove the file name

-d sql:/root/.pki/nssdb works

[amenk]

That's the final command we use as a workaround in our CI:

      - $COMPOSE_CMD run cypress bash -c "yarn cypress install && touch cypress/e2e/empty.cy.js && yarn cypress run --browser $BROWSER --spec cypress/e2e/empty.cy.js || true && apt update && apt install -y libnss3-tools && certutil -A -n Cypress -t 'TCu,Cu,Tu' -i /root/.config/Cypress/cy/production/proxy/certs/ca.pem -d sql:/root/.pki/nssdb && yarn cypress run --browser $BROWSER --spec $SPEC"

Are there chances to add an option --auto-import-ca to cypress ?

[marktnoonan]

Glad you got a work around @amenk! --auto-import-ca seems like a good idea to me, would you mind opening a feature request issues linking back to this comment and the other context in this thread? It will help keep the request separate from the longer conversation in this issue.

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

[amenk]

Okay, can be followed up in https://github.com/cypress-io/cypress/issues/26744 then

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

[cypress-app-bot]

This issue has been closed due to inactivity.