-
Notifications
You must be signed in to change notification settings - Fork 9.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test lighthouse on website with invalid certificate fails #7292
Comments
We bail completely if we see an insecure security certificate. There is some discussion happening to disable this behavior for sites hosted locally - see #6655. I've never seen WPT used this way, very cool that it's possible to route requests for a domain to somewhere else. I assume this is a staging environment you are wanting to audit? Until we work out what we want to do re: #6655, I think your best bet would be to host your staging environment on a subdomain (or even a different domain), one that has a valid security certificate. As a bonus, you wouldn't need muck with the DNS at all (if your site was https://staging.lemonde.fr, you could just audit that). If that wouldn't be viable please share why, would like to better understand your constraints. note: unfortunately the |
Our use case is to to audit the website through a front end optimizer (Fasterize in our case) that rewrites pages to apply different front end optimizations. |
I'm also having problems running Lighthouse with invalid certificates. Use Case: One solution might be to inject a step beforehand, to copy the certificates over to the store in the container, but that's a bit of a hassle. I've obviously tried setting I later tried going more low level to the Devtools protocol, and set the
My original assumption was this would change the security state of Chrome and Lighthouse would use that. But now I'm thinking that this state is lost when Lighthouse connects as a new Devtools client, so must be done within Lighthouse itself. |
Just in case this is helpful to others, my solution to this problem was copying certificate to the container so that the web app appears secure to the Lighthouse client. The two steps are as follows:
Example: |
I managed to work around this issue by installing an older version of lighthouse, in my case I did
which you can then launch with
that finished without throwing the ERR_CERT_COMMON_NAME_INVALID error. |
We may merge a feature that would resolve this. see #7574. |
With #8865, |
Sorry for the noise, we thought |
This bug has been found via Webpagetest. I also did some tests with the command line.
Provide the steps to reproduce
The following possibilities instruct Chrome to ignore certificate errors and resolve www.lemonde.fr to IP 62.210.77.17. Note that the server 62.210.77.17 doesn't have a valid certificate for www.lemonde.fr.
Three possibilities :
Ref : http://wpt.fasterize.com/result/190221_X6_R/
What is the current behavior?
The report is not launched whereas the page is correctly displayed on Chrome
Full log :
What is the expected behavior?
Lighthouse should launch the report.
Environment Information
Related issues
The text was updated successfully, but these errors were encountered: