Known issues

Chrome Devices

Chrome devices are unable to connect to managed networks

Managed Chrome devices may have received invalid network policies and lost connectivity to passphrase-protected networks configured through admin policies.

We have addressed the root cause of this issue, but due to the nature of issue, the fix does not take effect until affected devices connect to networks and refresh policies.

We have published steps to address this issue in this help article.

If you still have questions concerning this issue, please contact the Google Cloud Support team.

Last updated on December 5, 2017

Some Chromebook batteries don't recharge after prolonged storage

 Lithium ion batteries  typically drain slowly when left uncharged for long periods of time (such as during school breaks). The Chromebook models below may discharge so deeply during storage that it affects the battery’s ability to be recharged:  
  • 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 - "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:

  1. Press and hold the power button until your Chromebook shuts down.
  2. 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

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 Enterprise

Users need to enter CAPTCHA challenge for Search

This issue can occur if your organization routes all search requests through a single IP using a proxy. Google Search might detect these requests as potential spam and abuse, which triggers a CAPTCHA challenge.

To try and fix the issue:

  • If you use the DefaultSearchProviderSuggestURL policy, change the URL to {google:baseURL}complete/search?output=chrome&q={searchTerms}.
  • Run a malware check on your network.
  • Stop users from using Hola VPN.

Related topics:


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.

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

When a domain administrator disables Google Chrome Management under Users > Services in the Google Admin console, Chrome does not delete or disable the policies it applied to users in the domain. To remove these policies, you need to remove the Chrome profile from the local computer and create a new browser user profile.

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.

Device management

Chrome devices are unable to connect to managed networks

Managed Chrome devices may have received invalid network policies and lost connectivity to passphrase-protected networks configured through admin policies.

We have addressed the root cause of this issue, but due to the nature of issue, the fix does not take effect until affected devices connect to networks and refresh policies.

We have published steps to address this issue in this help article.

If you still have questions concerning this issue, please contact the Google Cloud Support team.

Last updated on December 5, 2017

User can't sign in even though they're on approved user list policy

If users are receiving errors during sign-in stating that they aren't allowed to log in to the device due to a domain policy, this may be caused by SSL filtering. We've recently updated the list of URLs to whitelist for SSL filters, so please review and update the URLs to this list.

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:

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.

Unable to delegate Chrome OS admins by org unit

New admin roles with the "Chrome OS" section selected cannot be assigned to users for specific org units. For admin roles that have already been assigned to users, selecting the "Chrome OS" checkbox will display an error. Instead, select all the subsections under "Chrome OS" for the admin role prior to assigning it to any users.


Customized kiosk app policies do not apply

 If your app policies are not applying after adding a new kiosk app, please select the app from the Auto-Launch Kiosk App list in the Single App Kiosk settings.

In Chrome Sign Builder, when I add a Google Slides presentation and configure settings using Open presentation options, I see a Google Docs error

When you add the presentation URL in the Add new content window of Chrome Sign Builder, don’t click Open presentation options. Instead, change any needed settings in the Publish to the web window in Google Slides and use the published URL. For more information about this workaround, see this Chromium bug.