Some Chromebook batteries don't recharge after prolonged storage
- CTL J2 / J4 Chrome for education device
- CDI eduGear Chromebook K Series
- HiSense Chromebook 11
- Poin2 Chromebook 11
We recommend that you charge these devices to between 60% and 80% and cut off the power before placing them in a cool location for storage over the summer.
To cut off power, first shutdown device, then hold F3 (refresh key) + power button and unplug the charger at the same time. Check that your device does not power on without the charger plugged in. When you want to power back on the device, just plug the charger in again. If you run into any issues or have further questions about these devices, please directly contact your device manufacturer.
Limitation on number of saved hidden SSID networks a Chrome device can scan and connect to
The number of manually saved and managed hidden SSID networks that a Chrome device can scan and connect to is limited by what the WLAN chipset supports, which can vary between Chrome device models.
This can be verified on a Chrome device in dev mode with the following command:
$ /usr/sbin/iw phy | grep -i ssid
As an example, entering this command on an Acer Chromebook C720 would result in the following:
$ /usr/sbin/iw phy | grep -i ssid
max # scan SSIDs: 4
In this example with an C720 gives us the answer 4. One is consumed by the scan, so it is advised to have a maximum of three hidden SSID networks saved on the device, either by managed network policy or manually added.
We encourage customers not to use hidden SSID on their access points.
Important: Please tag these cases with crbug.com/577993 - "FR: Support for more hidden SSIDs than the hardware supports".
Do not remove the power cord of the Chromebit for at least 10 minutes during the first run of the kiosk app
When you first run the Chromebit kiosk app, you must not remove the power cord for at least 10 minutes; removing the cord before 10 minutes may result in an ungraceful shutdown, and there's a chance the kiosk app will hang on subsequent startup. This is applicable only for the first run of the kiosk app. The second run and future runs of the app will work without issue (if you remove the power cord during the kiosk session). A fix for this issue is coming soon. Please check this page for updates. If you do need to shut down during the first 10 minutes of the first run, you can do so from the Chrome Management Console.
"Determining device configuration" error message
If your screen gets stuck on a message that says "Determining device configuration" while you're setting up your Chromebook for the first time, you may need to reboot your system:
- Press and hold the power button until your Chromebook shuts down.
- Turn your Chromebook back on.
If the error message still appears, contact Google Support.
The login window is blank
Chrome devices on version 44 and above may not properly load the login window if the connected network blocks access to accounts.gstatic.com.
To fix the issue, allow access to this domain on your network. The complete list of recommended host names to whitelist is available here.
Chrome for business
Error: SSL_HANDSHAKE_ERROR or ERR_CONNECTION_CLOSED
Chrome 56 enables support for TLS 1.3 for enhanced security. However, some firewalls and proxy servers are not compatible with TLS 1.3 and break the connection. This error may show on Google domains as well as Cloudflare-hosted sites.
We have made an update to Chrome 56 to disable TLS 1.3. However, some browsers and devices may be stuck in a bad state where they cannot receive the update to disable TLS 1.3.
To solve this issue, please work with your firewall or proxy vendor to update to a version that is compatible with TLS 1.3. A future version of Chrome will re-enable TLS 1.3.
If you need other short--term workarounds, see this Chromium bug.
In Chrome browser version 48, support for the RC4 cipher suite was removed. As a result, enterprise deployments might see some servers that require RC4 fail and return the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error.
To fix the problem:
Update your server configuration to enable a different cipher suite. For more information, see Intent to deprecate: RC4.
- Temporarily enable the RC4 cipher suite in TLS policy. The policy is only a temporary solution. It will be removed around Sep 2016, and the RC4 cipher suite will no longer be available.
Error: "Subject Alternative Name Missing" or NET::ERR_CERT_COMMON_NAME_INVALID or "Your connection is not private"
During Transport Layer Security (TLS) connections, Chrome browser checks to make sure the connection to the site is using a valid, trusted server certificate.
For Chrome 58 and later, only the subjectAlternativeName extension, not commonName, is used to match the domain name and site certificate. The certificate subject alternative name can be a domain name or IP address. If the certificate doesn’t have the correct subjectAlternativeName extension, users get a NET::ERR_CERT_COMMON_NAME_INVALID error letting them know that the connection isn’t private. If the certificate is missing a subjectAlternativeName extension, users see a warning in the Security panel in Chrome DevTools that lets them know the subject alternative name is missing.
Some public key infrastructures (PKIs), legacy systems, and older versions of network monitoring software use certificates without subjectAlternativeName extensions. If you’re having issues with any of these, contact the software vendor or administrator and ask them to generate a new certificate.
For Microsoft® Windows®, you can use the PowerShell Cmdlet New-SelfSignedCertificate and specify the DnsName parameter.
For OpenSSL, you can use the subjectAltName extension to specify the subject alternative name.
If needed, until Chrome 65, you can set the EnableCommonNameFallbackForLocalAnchors policy. This lets Chrome use the commonName of a certificate to match a hostname if the certificate is missing a subjectAlternativeName extension.
The user policies I configured for Chrome devices now apply to users who sign in to the Chrome browser on desktop or personal devices.
Google Chrome Management is now available as a service, and it has been enabled for G Suite and G Suite for Education domains that have opted into receiving new services automatically. Users in suborganizations that had user settings applied on Chrome Devices will see these same settings on their browsers when they sign in to Chrome.
If you do not wish to have these settings on some or all of your Chrome users at this time, please use one of the following workarounds.
Change the user settings back to default for the relevant suborganizations. You can collect a list of what policies are on the Chrome browser by typing about:policy in their Chrome address bar. You can then find the corresponding policy and change it to the default setting in your Admin console by going to Settings > Chrome Management > User Settings. Please keep in mind that this will also change the Chrome device settings for the users you specify.
If you have a subset of users who you do not wish to manage on either Chrome or Chrome Devices, you can move them to a separate suborganization. In the Admin console, go to Organization & Users > Services and disable Google Chrome Management. The users can then delete and recreate their Chrome profiles. Future policy changes will not affect these users until you re-enable Google Chrome Management and apply settings.
Chrome policies pushed from the Admin console can be overridden by Group Policies applied locally to corporate-managed devices. Use this mechanism if you want your user experience on Windows computers to be different than on Chrome devices.
Policies remain after Chrome management is disabled by the administrator
EnableSha1ForLocalAnchors policy has no affect on Chrome 54-56
For Chrome versions 54-56, setting the EnableSha1ForLocalAnchors policy does not change the behavior when loading an HTTPS site which utilizes a locally-anchored SHA-1 certificate. The omnibox will still show a red triangle indicating it's not secure and a red slash through the https portion of the URL.
When testing the EnableSha1ForLocalAnchors policy, we suggest testing against Chrome 57. Chrome 57 without the policy set will show an interstial warning to the user that the page is insecure. User must click through Advanced > Proceed to view the page. If the policy is set, no interstitial warning will be shown and the omnibox will show a neutral gray icon for the page.
User can't sign in even though they're on approved user list policy
Policies aren't applying to new users when "Require a change of password in the next sign in" is set
When users are signing in to their Chrome devices for the first time, they can be blocked from properly applying policies if Require a change of password in the next sign in is set on their account.
To ensure the policies are correctly applied, you should do either of the following:
- Have new users sign in to https://accounts.google.com/ to set their password before using a Chrome device for the first time.
- Instruct your users to sign in to their Google account at https://accounts.google.com/ using guest mode on a Chrome device.
This ensures the user has updated their password as required, and the user policies will be set as expected. Future sign-ins for that user on any Chrome device should work as intended, and your organization's policies in Chrome Management should be enforced on their device.