Known issues

Chrome Devices

Chrome device won't accept correct password

Known issue:

We’ve received reports that some users cannot sign in to their managed Chrome device, even when they’re using the correct password.

We’ve also received reports that on startup, some Chrome Kiosks are showing the Chrome OS sign-in page instead of auto-launching their applications.

Steps to resolve issue:

Here are the two methods that users have reported as resolving these issues:

  • Remove the user account from the Chrome device, and then recreate the user account on the affected device. Try now to sign in to the Chrome device.
  • If that fails, wipe and re-enroll the Chrome device.

We are actively looking into these issues, and will update this Known Issue with more detailed information soon.

 

Last updated: September 19, 2018

"A registration certificate could not be obtained" error message

Error message: "A registration certificate could not be obtained"

You will see this error message when forced re-enrollment is enabled on a Chrome device. This error occurs when auto re-enrollment fails because the device is connected to a network with SSL inspection that does not have the hostname "chromeos-ca.gstatic.com" whitelisted.

Workaround:

Users can switch to the manual re-enrollment screen by clicking X in the top-right corner of the error screen. Or, the administrator can whitelist the hostname chromeos-ca.gstatic.com on the proxy server to allow Chrome devices to automatically re-enroll.

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 crbug.com/577993 - "FR: Support for more hidden SSIDs than the hardware supports".

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

Kiosk

Chrome Kiosk won't launch. I'm seeing the sign-in screen instead

Known issue:

We’ve received reports that on startup, some Chrome Kiosks are showing the Chrome OS sign-in page instead of auto-launching the kiosk app.

Steps to resolve issue:

Here is a method some users have reported as resolving this issue:

We are actively looking into this issue, and will update this Known Issue with more detailed information and instructions soon.

 

Last updated: September 19, 2018

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.

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:

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.

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.

Changes not recorded in admin audit log

Currently, changes to Chrome devices using the Directory API and third party tools are not recorded in admin audit logs.
Was this article helpful?
How can we improve it?