As announced in February 2026, Chrome will not add traditional X.509 certificates containing post-quantum cryptography to its root store. Instead, Chrome will rely on Merkle Tree Certificates (MTCs) to mitigate the impact of post-quantum key and signature size increases while integrating transparency directly into the issuance process.
To support development and interoperability with Chrome, we are providing a mechanism to submit non-production cosigners for inclusion in Chrome to be used for general testing and validation. Applications will begin in July 2026, and will be open to any organization currently operating either traditional root CAs or CT logs included in Chrome.
This FAQ aims to provide clarity on the test and validation trust store.
Yes. Beginning in Chrome 150, Chrome supports ML-DSA in private PKI hierarchies, making it possible to test non-MTC post-quantum X.509 certificates locally or within enterprise environments.
We are offering a dedicated MTC root store explicitly for the purposes of end-to-end testing and validation. This test root store will be delivered to Chrome clients, but not trusted for production use. Instead, Chrome clients can be individually configured to enable trust of MTCs from these specific test issuers. Chrome M152 is expected to have support for testing Standalone and Landmark-relative MTCs.
Additionally, Chrome may monitor the logs included in this testing phase for availability and correctness, similar to how it currently monitors CT logs.
Organizations currently operating either traditional root CAs or CT logs included in Chrome can request the inclusion of testing cosigners by creating a new issue in the Chromium Issue Tracker (use the New Test MTC CA Operator template).
Chrome will begin processing requests starting July 31, 2026, and aim to include these cosigner keys in the test root store within two weeks of reviewing the request. We will follow up on the issue tracker once the root store has been updated.
The testing root store is only supported in Chrome 152 or later (currently Chrome Canary).
You can enable the experimental features using chrome://flags:
chrome://flags.verify-mtcstest-root-storeMTC test root store anchors and cosigner metadata are updated dynamically via Chrome’s Component Updater:
chrome://components.To verify that your site successfully established a connection using MTCs:
F12 or Cmd + Option + I).ML-DSA-44 (or different)X25519MLKEM768 (ML-KEM)cosigners.json to include?The JSON can be found at: https://www.gstatic.com/mtcs/cosigners/v1/cosigners.json.
Yes. Testing certificates will be subject to the same validation logic as production certificates. This includes restrictions to 7-day or 47-day maximum validity. For both Mirroring and CA Cosigners, we will accept only ML-DSA-44 (OID: 2.16.840.1.101.3.4.3.17, RFC 9881) cosigning keys. There is no equivalent key restriction on the test Subscriber certificates.
Though not technically enforced by the client, practices such as the use of strict domain control validation or the use of Hardware Security Modules are encouraged to maximize the value of this testing infrastructure.
Yes. As Chrome will be enforcing realistic cosigner requirements (e.g., requiring mirroring cosignatures on Standalone certificates), we ask that participants in the testing phase contribute a Mirroring Cosigner usable by all CA Cosigners to ensure adequate and realistic mirroring capacity is available.
The CA Cosigner issuance log should implement the API endpoints, cryptographic formats, and Merkle Tree structures defined in the MTC specification (specifically draft-ietf-plants-merkle-tree-certs-05) and the tlog-tiles specification. The Mirroring Cosigner should implement the API endpoints, cryptographic formats, and validation logic defined in the MTC specification and the tlog-mirror specification.
Chrome clients will enforce the same cosignature requirements to validate a certificate in the testing phase as with production certificates. Standalone certificates must have at least two cosignatures. One must be from the MTC CA Operator, and one must be from a Mirroring Cosigner recognized by the Chrome test root store. Chrome's servers will similarly ensure that issuer logs are mirrored before trusting subtrees for Landmark-relative certificates.
Chrome’s compliance monitoring infrastructure may continuously query both the test MTC CA issuance logs and Mirroring Cosigner endpoints throughout their lifetime. The monitoring would focus on uptime metrics, cryptographic integrity, and adherence to technical specifications, intending to be a feedback loop for MTC CA Operators from Chrome.
Development on Chrome's monitoring infrastructure is ongoing, but Operators can expect that Chrome would monitor for availability and uptime by looking for:
Operators should also expect that Chrome monitors would verify that:
Chrome may send notifications to the Operator when availability and correctness failures are observed. During the testing phase, these notifications are purely to support Operators in developing robust implementations, and we encourage (but do not require) sharing postmortems and development challenges or milestones to mtcs@chromium.org so that everyone can benefit from lessons learned.
Please share your implementation experiences and challenges on mtcs@chromium.org! The hope is that everyone in the ecosystem can benefit from these learnings.
The test setup can persist at the MTC CA Operators' discretion. We will maintain Chrome's testing infrastructure until Chrome accepts the first Phase 3 eligible MTC CA Operators.
Notably, cosigner keys accepted as part of the testing trust store will not be accepted for production use in Chrome. MTC CA Operators will need to generate new cosigner keys and fully adhere to the CQRP Policy to be included in Phase 2 or later launches.
cosigners.json?All cosigners approved for the testing phase are included in cosigners.json with a realm property of "UNTRUSTED_VALIDATION_ONLY". This explicitly distinguishes test cosigners from production CAs ("PUBLICLY_TRUSTED"), ensuring Chrome clients restrict test keys to validation testing only and never trust them for production certificate validation.