Tag Archives: Chrome

Sustaining Digital Certificate Security – Upcoming Changes to the Chrome Root Store

Posted by Chrome Root Program, Chrome Security Team

Note: Google Chrome communicated its removal of default trust of Chunghwa Telecom and Netlock in the public forum on May 30, 2025.

The Chrome Root Program Policy states that Certification Authority (CA) certificates included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion. It also describes many of the factors we consider significant when CA Owners disclose and respond to incidents. When things don’t go right, we expect CA Owners to commit to meaningful and demonstrable change resulting in evidenced continuous improvement.

Chrome's confidence in the reliability of Chunghwa Telecom and Netlock as CA Owners included in the Chrome Root Store has diminished due to patterns of concerning behavior observed over the past year. These patterns represent a loss of integrity and fall short of expectations, eroding trust in these CA Owners as publicly-trusted certificate issuers trusted by default in Chrome. To safeguard Chrome’s users, and preserve the integrity of the Chrome Root Store, we are taking the following action.

Upcoming change in Chrome 139 and higher:

This approach attempts to minimize disruption to existing subscribers using a previously announced Chrome feature to remove default trust based on the SCTs in certificates.

Additionally, should a Chrome user or enterprise explicitly trust any of the above certificates on a platform and version of Chrome relying on the Chrome Root Store (e.g., explicit trust is conveyed through a Group Policy Object on Windows), the SCT-based constraints described above will be overridden and certificates will function as they do today.

To further minimize risk of disruption, website operators are encouraged to review the “Frequently Asked Questions" listed below.

Why is Chrome taking action?

CAs serve a privileged and trusted role on the internet that underpin encrypted connections between browsers and websites. With this tremendous responsibility comes an expectation of adhering to reasonable and consensus-driven security and compliance expectations, including those defined by the CA/Browser Forum TLS Baseline Requirements.

Over the past several months and years, we have observed a pattern of compliance failures, unmet improvement commitments, and the absence of tangible, measurable progress in response to publicly disclosed incident reports. When these factors are considered in aggregate and considered against the inherent risk each publicly-trusted CA poses to the internet, continued public trust is no longer justified.

When will this action happen?

The action of Chrome, by default, no longer trusting new TLS certificates issued by these CAs will begin on approximately August 1, 2025, affecting certificates issued at that point or later.

This action will occur in Versions of Chrome 139 and greater on Windows, macOS, ChromeOS, Android, and Linux. Apple policies prevent the Chrome Certificate Verifier and corresponding Chrome Root Store from being used on Chrome for iOS.

What is the user impact of this action?

By default, Chrome users in the above populations who navigate to a website serving a certificate from Chunghwa Telecom or Netlock issued after July 31, 2025 will see a full page interstitial similar to this one.

Certificates issued by other CAs are not impacted by this action.

How can a website operator tell if their website is affected?

Website operators can determine if they are affected by this action by using the Chrome Certificate Viewer.

Use the Chrome Certificate Viewer

  • Navigate to a website (e.g., https://www.google.com)
  • Click the “Tune" icon
  • Click “Connection is Secure"
  • Click “Certificate is Valid" (the Chrome Certificate Viewer will open)
    • Website owner action is not required, if the “Organization (O)” field listed beneath the “Issued By" heading does not contain “Chunghwa Telecom" , “行政院” , “NETLOCK Ltd.”, or “NETLOCK Kft.”
    • Website owner action is required, if the “Organization (O)” field listed beneath the “Issued By" heading contains “Chunghwa Telecom" , “行政院” , “NETLOCK Ltd.”, or “NETLOCK Kft.”

What does an affected website operator do?

We recommend that affected website operators transition to a new publicly-trusted CA Owner as soon as reasonably possible. To avoid adverse website user impact, action must be completed before the existing certificate(s) expire if expiry is planned to take place after July 31, 2025.

While website operators could delay the impact of blocking action by choosing to collect and install a new TLS certificate issued from Chunghwa Telecom or Netlock before Chrome’s blocking action begins on August 1, 2025, website operators will inevitably need to collect and install a new TLS certificate from one of the many other CAs included in the Chrome Root Store.

Can I test these changes before they take effect?

Yes.

A command-line flag was added beginning in Chrome 128 that allows administrators and power users to simulate the effect of an SCTNotAfter distrust constraint as described in this blog post.

How to: Simulate an SCTNotAfter distrust

1. Close all open versions of Chrome

2. Start Chrome using the following command-line flag, substituting variables described below with actual values

--test-crs-constraints=$[Comma Separated List of Trust Anchor Certificate SHA256 Hashes]:sctnotafter=$[epoch_timestamp]

3. Evaluate the effects of the flag with test websites

Learn more about command-line flags here.

I use affected certificates for my internal enterprise network, do I need to do anything?

Beginning in Chrome 127, enterprises can override Chrome Root Store constraints like those described in this blog post by installing the corresponding root CA certificate as a locally-trusted root on the platform Chrome is running (e.g., installed in the Microsoft Certificate Store as a Trusted Root CA).

How do enterprises add a CA as locally-trusted?

Customer organizations should use this enterprise policy or defer to platform provider guidance for trusting root CA certificates.

What about other Google products?

Other Google product team updates may be made available in the future.

Timeline update: third-party autofill services support on Chrome on Android

Posted by Eiji Kitamura – Developer Advocate (@agektmr)

In October 2024, we announced that Chrome 131 will allow third-party autofill services on Android (like password managers) to natively autofill forms on websites. Reflecting on feedback from autofill service developers, we've decided to shift the schedule and allow the third-party autofill services from Chrome 135.

Native Chrome support for third-party autofill services on Android means that users will be able to use their preferred password manager or autofill service directly in Chrome, without having to rely on workarounds or extensions. This change is expected to improve the user experience and security for Android users who use third-party autofill services.

Based on developer feedback, we've fixed bugs, and have been working to make the new setting easier to discover. To support those goals, we've added the following capabilities:

    • An ability to query Chrome settings and learn whether the user wishes to use a third party autofill service
    • An ability to deep link to the Chrome settings page where users can enable third-party autofill services.

Read Chrome settings

Any app can read whether Chrome uses the 3P autofill mode that allows it to use Android Autofill. Chrome uses Android's ContentProvider to communicate that information. Declare in your Android manifest which channels you want to read settings from, e.g.:

<uses-permission android:name="android.permission.READ_USER_DICTIONARY"/>
<queries>
 <!-- To Query Chrome Beta: -->
 <package android:name="com.chrome.beta" />

 <!-- To Query Chrome Stable: -->
 <package android:name="com.android.chrome" />
</queries>

Then, use Android's ContentResolver to request that information by building the content URI as in this example code:

final String CHROME_CHANNEL_PACKAGE = "com.android.chrome";  // Chrome Stable.
final String CONTENT_PROVIDER_NAME = ".AutofillThirdPartyModeContentProvider";
final String THIRD_PARTY_MODE_COLUMN = "autofill_third_party_state";
final String THIRD_PARTY_MODE_ACTIONS_URI_PATH = "autofill_third_party_mode";

final Uri uri = new Uri.Builder()
                  .scheme(ContentResolver.SCHEME_CONTENT)
                  .authority(CHROME_CHANNEL_PACKAGE + CONTENT_PROVIDER_NAME)
                  .path(THIRD_PARTY_MODE_ACTIONS_URI_PATH)
                  .build();

final Cursor cursor = getContentResolver().query(
                  uri,
                  /*projection=*/new String[] {THIRD_PARTY_MODE_COLUMN},
                  /*selection=*/ null,
                  /*selectionArgs=*/ null,
                  /*sortOrder=*/ null);

cursor.moveToFirst(); // Retrieve the result;

int index = cursor.getColumnIndex(THIRD_PARTY_MODE_COLUMN);

if (0 == cursor.getInt(index)) {
  // 0 means that the third party mode is turned off. Chrome uses its built-in
  // password manager. This is the default for new users.
} else {
  // 1 means that the third party mode is turned on. Chrome uses forwards all
  // autofill requests to Android Autofill. Users have to opt-in for this.
}

Deep-link to Chrome settings

To deep-link to the Chrome settings page where users can enable third-party autofill services, use an Android Intent. Ensure to configure the action and categories exactly as in this example code:

Intent autofillSettingsIntent = new Intent(Intent.ACTION_APPLICATION_PREFERENCES);
autofillSettingsIntent.addCategory(Intent.CATEGORY_DEFAULT);
autofillSettingsIntent.addCategory(Intent.CATEGORY_APP_BROWSER);
autofillSettingsIntent.addCategory(Intent.CATEGORY_PREFERENCE);

// Invoking the intent with a chooser allows users to select the channel they want to 
// configure. If only one browser reacts to the intent, the chooser is skipped.
Intent chooser = Intent.createChooser(autofillSettingsIntent, "Pick Chrome Channel");
startActivity(chooser);

// If the caller knows which Chrome channel they want to configure, 
// they can instead add a package hint to the intent, e.g.
autofillSettingsIntent.setPackage("com.android.chrome");
startActivity(autofillSettingsInstent);

Updated timeline

To reflect the feedback and to leave time for autofill service developers to make relevant changes, we are shifting the plan. Users must select Autofill using another service in Chrome settings to ensure their autofill experience is unaffected. The new setting will become available in Chrome 135. Autofill services should encourage their users to toggle the setting, to ensure they have the best autofill experience possible with their service and Chrome on Android. Chrome plans to stop supporting the compatibility mode in summer 2025.

    • March 5th, 2025: Chrome 135 beta is available
    • April 1st, 2025: Chrome 135 is in stable
    • Summer 2025: Compatibility mode will no longer be available on Chrome

Curate and customize the Chrome Web Store for your organization

What’s changing

Admins can now customize the Chrome Web Store experience for their users with several new options, including:

  • Branding and custom messaging: Add company logos, custom welcome banners and announcement banners.
  • Curated collections: Organize specific extensions for your users, including recommended and private extensions. We have also introduced a new collection of extensions that displays all items that are allowlisted by IT administrators.
  • Category controls: Hide specific extension categories to help streamline the browsing experience for users.

Additionally, we've enhanced the Chrome Web Store search experience. In the search results. end-users can quickly notice blocked item tags, and they can benefit from more advanced filtering such as a “Private items” filter.  

Example of a customized Chrome Web Store


Who’s impacted

Admins and end users


Why it matters 

Every Google Workspace customer has unique users with unique needs – Chrome extensions can help improve their workflows and increase productivity. However, navigating the numerous available extensions can present challenges for both admins and end users. For admins, it is often a manual and time consuming process to vet which Chrome extensions they want to allow for their users. For end users, it can be frustrating to sift through a vast catalog of extensions to find relevant and admin-approved extensions.

This update significantly improves the Chrome Web Store experience for enterprises. Admins can customize, organize, and control the Chrome Web Store experience for their users. For end users, finding work-relevant and admin approved extensions becomes significantly easier cutting down on guesswork or wasted time searching for extensions that might be blocked.


Getting started

  • Admins: Four new Apps & Extensions settings have been added to the Chrome section of the Admin console. To find the new settings, go to Menu > Chrome Browser > Apps and extensions > Navigate to the “Settings” tab > Chrome Web Store settings. Visit the Help Center to learn more about customizing the Chrome Web Store for your users.



Rollout pace


Availability

  • Available for all Google Workspace customers with access to the Admin console

Resources