Merge Nov 2020 CT Policy changes to master (#32)

Merging Nov 2020 CT Policy changes from the branch currently serving the current CT Policy (https://chromium.github.io/ct-policy/ct_policy.html) that's hosted on `draft-policy-changes-2020q4` now that the previous text has been archived on branch `archived-pre-nov-2020-ct-policy`

Co-authored-by: Andrew Whalley <awhalley@google.com>
This commit is contained in:
devonobrien 2021-07-09 12:55:10 -07:00 коммит произвёл GitHub
Родитель 004eaa1a94
Коммит 4fa79451e0
Не найден ключ, соответствующий данной подписи
Идентификатор ключа GPG: 4AEE18F83AFDEB23
16 изменённых файлов: 1138 добавлений и 271 удалений

Просмотреть файл

@ -1,4 +1,4 @@
# How to contribute
# How to Contribute
We'd love to accept your patches and contributions to this project. There are
just a few small guidelines you need to follow.
@ -6,13 +6,14 @@ just a few small guidelines you need to follow.
## Contributor License Agreement
Contributions to this project must be accompanied by a Contributor License
Agreement. You (or your employer) retain the copyright to your contribution,
this simply gives us permission to use and redistribute your contributions as
part of the project. Head over to <https://cla.developers.google.com/> to see
your current agreements on file or to sign a new one.
Agreement (CLA). You (or your employer) retain the copyright to your
contribution; this simply gives us permission to use and redistribute your
contributions as part of the project. Head over to
<https://cla.developers.google.com/> to see your current agreements on file or
to sign a new one.
You generally only need to submit a CLA once, so if you've already submitted
one (even if it was for a different project), you probably don't need to do it
You generally only need to submit a CLA once, so if you've already submitted one
(even if it was for a different project), you probably don't need to do it
again.
## Code reviews
@ -21,3 +22,8 @@ All submissions, including submissions by project members, require review. We
use GitHub pull requests for this purpose. Consult
[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
information on using pull requests.
## Community Guidelines
This project follows
[Google's Open Source Community Guidelines](https://opensource.google/conduct/).

Просмотреть файл

@ -1,3 +1,4 @@
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
@ -198,4 +199,4 @@
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
limitations under the License.

202
LICENSE.txt Normal file
Просмотреть файл

@ -0,0 +1,202 @@
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

115
README.md
Просмотреть файл

@ -1,105 +1,20 @@
# Chromium Certificate Transparency Policy
# Certificate Transparency in Chrome
This repository contains documents related Chromium's Certificate Transparency
policies, such as the [Certificate Transparency Log Policy](log_policy.md).
## Overview
Their contents can be discussed in the
[ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy)
forum.
Certificate Transparency (CT) is a protocol designed to fix several structural
flaws in the SSL/TLS certificate ecosystem. Described in
[RFC 6962](https://tools.ietf.org/html/rfc6962), it provides a public,
append-only data structure that can log certificates that are issued by
[certificate authorities](https://en.wikipedia.org/wiki/Certificate_authority) (CAs).
## For Certificate Authorities
By logging certificates, it becomes possible for the public to see what
certificates have been issued by a given CA. This allows site operators to
detect when a certificate has been issued for their domains, allowing them to
check for unauthorized issuance. It also allows browsers and root stores, and
the broader community, to examine the certificates a CA has issued and ensure
that the CA is complying with their expected or disclosed practices.
In order to help protect users of the Chromium Projects, CAs are expected to
support Certificate Transparency. This allows users, the Chromium Authors, and
the public to verifiably audit that CAs are conforming to the policies set out
in Chromium's [Root Certificate Policy](https://www.chromium.org/Home/chromium-security/root-ca-policy).
For more information about how Certificate Transparency works and its role in supporting the web PKI, you can find a helpful introduction to CT at [https://certificate.transparency.dev](https://certificate.transparency.dev/).
Chromium requires all publicly-trusted TLS certificates issued after April 30, 2018 to support CT as described in the [Certificate Transparency in Chrome Policy](ct_policy.md). Extended Validation (EV) TLS certificates issued before this date are also required to support CT in order to be recognized as an EV certificate in Chromium.
## For Log Operators
In order for a Log to be included within Chromium, it must meet the
requirements of the [Certificate Transparency Log Policy](log_policy.md). The
Log Policy describes the steps for Log Operators to submit Logs for inclusion
within Chromium.
## Recognized Logs
The following table includes information about the Certificate Transparency Logs
that are recognized by Chromium. It includes information about who operates the
log, the name the log has been given, and the URL that can be used for logging
certificates or inspecting the certificates that have been logged.
**_Note: The authoritative list is maintained in the [Chromium code base](https://cs.chromium.org/chromium/src/components/certificate_transparency/data/log_list.json). This is merely informational._**
### Qualified Logs
| Log Operator | Log Name | Log URL | MMD | Qualified In | Current State |
|-------------------------------------------|-----------------------------------------|--------------------------------------------|----------|---------------------------------------|---------------|
| [Google](https://www.google.com/) | Google 'Aviator' Log | https://ct.googleapis.com/aviator | 24 hours | [Chrome 35](https://crrev.com/237785) | Read Only |
| [Google](https://www.google.com/) | Google 'Pilot' Log | https://ct.googleapis.com/pilot/ | 24 hours | [Chrome 35](https://crrev.com/237785) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert's Certificate Transparency log | https://ct1.digicert-ct.com/log/ | 24 hours | [Chrome 41](https://crrev.com/309831) | Usable |
| [Google](https://www.google.com/) | Google 'Rocketeer' Log | https://ct.googleapis.com/rocketeer | 24 hours | [Chrome 43](https://crrev.com/325382) | Usable |
| [Google](https://www.google.com/) | Google 'Icarus' Log | https://ct.googleapis.com/icarus/ | 24 hours | [Chrome 55](https://crrev.com/429670) | Usable |
| [Google](https://www.google.com/) | Google 'Skydiver' Log | https://ct.googleapis.com/skydiver/ | 24 hours | [Chrome 55](https://crrev.com/429670) | Usable |
| [Sectigo](https://sectigo.com/) | Sectigo 'Mammoth' Log | https://mammoth.ct.comodo.com/ | 24 hours | [Chrome 60](https://crrev.com/482145) | Usable |
| [Sectigo](https://sectigo.com/) | Sectigo 'Sabre' Log | https://sabre.ct.comodo.com/ | 24 hours | [Chrome 60](https://crrev.com/482145) | Usable |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2020' Log | https://ct.cloudflare.com/logs/nimbus2020/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2021' Log | https://ct.cloudflare.com/logs/nimbus2021/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
| [Google](https://www.google.com/) | Google 'Argon2020' Log | https://ct.googleapis.com/logs/argon2020/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
| [Google](https://www.google.com/) | Google 'Argon2021' Log | https://ct.googleapis.com/logs/argon2021/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2020' Log | https://yeti2020.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2021' Log | https://yeti2021.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2022' Log | https://yeti2022.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2020' Log | https://nessie2020.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2021' Log | https://nessie2021.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2022' Log | https://nessie2022.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
| [Google](https://www.google.com/) | Google 'Xenon2020' Log | https://ct.googleapis.com/logs/xenon2020/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
| [Google](https://www.google.com/) | Google 'Xenon2021' Log | https://ct.googleapis.com/logs/xenon2021/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
| [Google](https://www.google.com/) | Google 'Xenon2022' Log | https://ct.googleapis.com/logs/xenon2022/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2022' Log | https://ct.cloudflare.com/logs/nimbus2022/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2023' Log | https://ct.cloudflare.com/logs/nimbus2023/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2023' Log | https://nessie2023.ct.digicert.com/log/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2023' Log | https://yeti2023.ct.digicert.com/log/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
| [Google](https://www.google.com/) | Google 'Xenon2023' Log | https://ct.googleapis.com/logs/xenon2023/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
| [Google](https://www.google.com/) | Google 'Argon2022' Log | https://ct.googleapis.com/logs/argon2022/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
| [Google](https://www.google.com/) | Google 'Argon2023' Log | https://ct.googleapis.com/logs/argon2023/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2020' Log | https://oak.ct.letsencrypt.org/2020/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2021' Log | https://oak.ct.letsencrypt.org/2021/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2022' Log | https://oak.ct.letsencrypt.org/2022/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2023' Log | https://oak.ct.letsencrypt.org/2023/ | 24 hours | [Chrome 87](https://crrev.com/800599) | Qualified |
| [TrustAsia](https://trustasia.com) | TrustAsia 'Log2020' | https://ct.trustasia.com/log2020/ | 24 hours | [Chrome 87](https://crrev.com/800599) | Qualified |
| [TrustAsia](https://trustasia.com) | TrustAsia 'Log2021' | https://ct.trustasia.com/log2021/ | 24 hours | [Chrome 87](https://crrev.com/800599) | Qualified |
| [TrustAsia](https://trustasia.com) | TrustAsia 'Log2022' | https://ct.trustasia.com/log2022/ | 24 hours | [Chrome 87](https://crrev.com/800599) | Qualified |
| [TrustAsia](https://trustasia.com) | TrustAsia 'Log2023' | https://ct.trustasia.com/log2023/ | 24 hours | [Chrome 87](https://crrev.com/800599) | Qualified |
### Once, but no longer, Qualified Logs
| Log Operator | Name | Log URL | MMD | Qualified In | Last Accepted SCT |
|-------------------------------------------|-----------------------------|--------------------------------------------|----------|---------------------------------------|------------------------------|
| [Certly](https://certly.io/) | Certly.IO Log | https://log.certly.io | 24 hours | [Chrome 43](https://crrev.com/325382) | 15 April 2016 00:00:00 UTC. |
| [Izenpe](https://www.izenpe.com/) | Izenpe Log | https://ct.izenpe.com | 24 hours | [Chrome 44](https://crrev.com/326301) | 30 May 2016 00:00:00 UTC. |
| [Venafi](https://www.venafi.com/) | Venafi CT Log Server | https://ctlog.api.venafi.com/ct/v1 | 24 hours | [Chrome 47](https://crrev.com/349170) | 28 Feb 2017 18:42:26 UTC. |
| [WoSign](https://www.wosign.com/) | WoSign Log | https://ctlog.wosign.com/ | 24 hours | [Chrome 54](https://crrev.com/414378) | 12 Feb 2018 23:59:59 UTC. |
| [StartCom](https://www.startssl.com/) | StartCom CT Log | https://ct.startssl.com/ | 24 hours | [Chrome 54](https://crrev.com/414440) | 12 Feb 2018 23:59:59 UTC. |
| [CNNIC](https://cnnic.cn/) | CNNIC CT Log | https://ctserver.cnnic.cn/ | 24 hours | [Chrome 53](https://crrev.com/396817) | 18 Sep 2018 00:00:00 UTC. |
| [DigiCert](https://www.digicert.com/) | Symantec Log | https://ct.ws.symantec.com | 24 hours | [Chrome 45](https://crrev.com/483625) | 16 Feb 2019 00:00:00 UTC. |
| [DigiCert](https://www.digicert.com/) | Symantec 'Vega' Log | https://vega.ws.symantec.com/ | 24 hours | [Chrome 50](https://crrev.com/376143) | 16 Feb 2019 00:00:00 UTC. |
| [DigiCert](https://www.digicert.com/) | Symantec 'Sirius' Log | https://sirius.ws.symantec.com/ | 24 hours | [Chrome 60](https://crrev.com/481160) | 16 Feb 2019 00:00:00 UTC. |
| [Google](https://www.google.com/) | Google 'Argon2018' Log | https://ct.googleapis.com/logs/argon2018/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2018' Log | https://ct.cloudflare.com/logs/nimbus2018/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2018' Log | https://yeti2018.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Rejected - Shard Expired |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2018' Log | https://nessie2018.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Rejected - Shard Expired |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2019' Log | https://ct.cloudflare.com/logs/nimbus2019/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2019' Log | https://yeti2019.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Rejected - Shard Expired |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2019' Log | https://nessie2019.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Rejected - Shard Expired |
| [Google](https://www.google.com/) | Google 'Argon2019' Log | https://ct.googleapis.com/logs/argon2019/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
| [Google](https://www.google.com/) | Google 'Xenon2019' Log | https://ct.googleapis.com/logs/xenon2019/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Rejected - Shard Expired |
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2019' Log | https://oak.ct.letsencrypt.org/2019/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Rejected - Shard Expired |
| [Venafi](https://www.venafi.com/) | Venafi Gen2 CT log | https://ctlog-gen2.api.venafi.com/ | 24 hours | [Chrome 59](https://crrev.com/471318) | Rejected - All Certs Expired |
| [DigiCert](https://www.digicert.com/) | DigiCert Log Server 2 | https://ct2.digicert-ct.com/log/ | 24 hours | [Chrome 60](https://crrev.com/481160) | 04 May 2020 00:00:40 UTC |
## Policy Version
Chromium Certificate Transparency Policy Version 1.0
Chrome requires all publicly-trusted TLS certificates issued after April 30, 2018 to support CT in order to be recognized as valid. This site provides details on what is required. Any questions should be directed to the [ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy) list.

2
_config.yml Normal file
Просмотреть файл

@ -0,0 +1,2 @@
theme: jekyll-theme-minimal
baseurl: /ct-policy

44
_layouts/default.html Normal file
Просмотреть файл

@ -0,0 +1,44 @@
<!DOCTYPE html>
<html lang="{{ site.lang | default: "en-US" }}">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
{% seo %}
<link rel="stylesheet" href="{{ "/assets/css/style.css?v=" | append: site.github.build_revision | relative_url }}">
<!--[if lt IE 9]>
<script src="https://cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv.min.js"></script>
<![endif]-->
</head>
<body>
<div class="wrapper">
<header>
<h1><a href="{{ "/" | absolute_url }}">Certificate Transparency<br>in Chrome</a></h1>
<h2 class="menu">Policies</h2>
<p class="menu"><a href="/ct-policy/ct_policy.html">Chrome CT Policy</a></p>
<p class="menu"><a href="/ct-policy/log_policy.html">Chrome CT Log Policy</a></p>
<h2 class="menu">Reference Material</h2>
<p class="menu"><a href="/ct-policy/log_states.html">Lifecycle of a CT Log</a></p>
<p class="menu"><a href="/ct-policy/site_operators.html">Information for site operators</a></p>
<p class="menu"><a href="/ct-policy/enterprises.html">Information for enterprises</a></p>
<p class="menu"><a href="/ct-policy/log_list.html">List of recognized CT Logs</a></p>
<!-- <p class="menu"><a href="/glossary.html">Glossary of CT Terms</a></p> -->
</header>
<section>
{{ content }}
</section>
<footer>
<p><a href="/ct-policy/CONTRIBUTING.md">contributing</a> | <a href="/ct-policy/LICENSE.txt">license</a></p>
</footer>
</div>
<script src="{{ "/assets/js/scale.fix.js" | relative_url }}"></script>
</body>
</html>

86
assets/css/style.scss Normal file
Просмотреть файл

@ -0,0 +1,86 @@
---
---
@import '{{ site.theme }}';
body {
padding: 10px;
}
.wrapper {
width: unset;
margin: unset;
}
a:hover,
a:focus {
font-weight: inherit;
text-decoration: underline;
}
p.menu {
padding-left: 1em;
margin: 0 0 5px;
}
h2.menu {
font-size: medium;
margin: 20px 0 5px;
}
li > ul {
margin: 0 0 0;
}
header {
width: 275px;
float: left;
position: fixed;
left: 25px;
}
section {
float: none;
width: 800px;
margin-left: 300px;
}
footer {
width: 275px;
left: 25px;
float: left;
position: fixed;
bottom: 25px;
}
@media print, screen and (max-width: 1175px) {
div.wrapper {
width: auto;
margin: 0;
}
header,
section,
footer {
float: none;
position: static;
width: auto;
}
section {
border: 1px solid #e5e5e5;
border-width: 1px 0;
padding: 20px 0;
margin: 0 0 20px;
}
header a small {
display: inline;
}
header ul {
position: absolute;
right: 50px;
top: 52px;
}
}

28
changes.md Normal file
Просмотреть файл

@ -0,0 +1,28 @@
### Chrome Policies
Chrome has gradually required Certificate Transparency for more and more
publicly-trusted certificates over the past few years.
* [Since 1 January 2015](https://github.com/chromium/ct-policy/blob/master/ct_policy.md),
Chrome has required that all Extended Validation certificates be disclosed via
Certificate Transparency. Certificates that were not properly disclosed would
be [stripped of their EV status](https://news.netcraft.com/archives/2015/08/24/thousands-short-changed-by-ev-certificates-that-dont-display-correctly-in-chrome.html),
but no warnings would be shown to visitors to sites that did not comply.
* [Since 1 June 2016](https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html),
Chrome has required that all new certificates issued by the set of root
certificates owned by Symantec Corporation are disclosed via Certificate
Transparency. Certificates that were not disclosed, or which were not disclosed
in a way consistent with RFC 6962, would be rejected as untrusted.
* For all new certificates issued after 30 April 2018, [Chrome will require that
the certificate be disclosed via Certificate
Transparency](https://groups.google.com/a/chromium.org/d/msg/ct-policy/wHILiYf31DE/iMFmpMEkAQAJ).
If a certificate is issued after this date and neither the certificate nor
the site supports CT, then these certificates will be rejected as untrusted, and
the connection will be blocked. In the case of a main page load, the user will
see a full page certificate warning page, with the error code
`net::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED`. If you receive this error, this
indicates that your CA has not taken steps to make sure your certificate
supports CT, and you should contact your CA's sales or support team to ensure
you can get a replacement certificate that works.

Просмотреть файл

@ -1,91 +1,72 @@
# Certificate Transparency in Chrome
_Questions: [ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy)_
# Chrome Certificate Transparency Policy
_Please direct any questions about this Policy to the CT Policy forum: [ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy)_
This document details the criteria for a certificate to be considered
*CT Qualified*.
When a websites TLS certificate is validated in modern versions of Chrome, it is
evaluated for compliance against the Chrome CT Policy, except in rare circumstances where [certain](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForCas) [enterprise](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForLegacyCas) [policies](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForUrls) are set by an administrator. Certificates that are accompanied by SCTs that satisfy this Policy are said to be *CT Compliant*.
Google Chrome requires that all Extended Validation (EV) certificates
issued after 1 Jan 2015 be CT Qualified in order to be recognized as EV,
and that all publicly-trusted TLS certificates issued after 30 April 2018
be CT Qualified in order to be recognized as valid.
CT Compliance is achieved by a certificate and set of accompanying SCTs meeting a set of technical requirements enforced by the Chrome browser during certificate validation, which are defined in this Policy. The issuance of certificates that are not CT compliant is **not** considered mis-issuance or a violation of Chromes root program; such certificates will simply fail to validate in CT-enforcing versions of Chrome.
In addition, Google Chrome allows for site operators to indicate that they
expect all publicly-trusted certificates for their domain, regardless of when
they were issued, be CT Qualified in order to be trusted.
---
Chromes current Certificate Transparency implementation is as follows:
## CT Log States
CT Compliance in Chrome is determined by evaluating SCTs from CT Logs and ensuring that these Logs are in the correct state(s) at time of check. The set of possible states a CT Log can be in is:
* `Pending`,
* `Qualified`,
* `Usable`,
* `ReadOnly`,
* `Retired`, and
* `Rejected`
1. Google runs three geographically diverse CT logs which accept all
certificates issued by CAs accepted by any major browser.
1. Google continues to invite other organisations to deploy CT logs in order
to improve robustness.
1. On 1 Jan 2015 Chrome created an allowlist of certificates that contained
EV policy OIDs included or pending inclusion in Chrome, that were logged
in a qualifying log, and that would not qualify via SCTs embedded in the
certificate (see below).
1. In March 2015 Chrome for desktop platforms ceased to show the EV
indicator for certificates not in the allowlist and not CT qualified
according to the criteria below.
In order to assist with understanding the requirements for CT compliance in Chrome, the definition of these states, the requirements of Logs in each state, as well as how these states impact Chrome behavior are described in detail in the [CT Log Lifecycle Explainer](log_states.md).
## Qualifying Logs
---
The criteria for qualifying logs can be found [here](log_policy.md).
## Qualifying Certificate
A certificate is “CT qualified” if it meets one of the following criteria:
1. An SCT from a log qualified at the time of check is presented via the TLS
extension OR is embedded within a stapled OCSP response;
## CT Compliant Certificates
A TLS certificate is *CT Compliant* if it is accompanied by a set of SCTs that satisfies at least one of the criteria defined below, depending on how the SCTs are delivered to Chrome. In CT-enforcing versions of Chrome, TLS certificates are required to be CT Compliant to successfully validate; however, certificates that are not logged to CT or have insufficient SCTs are not considered to be mis-issued or in violation of Chromes root program.
**AND** there is at least one SCT from a Google Log, qualified at the time
of check, presented via any method;
When evaluating a certificate for CT Compliance, Chrome considers several factors including how many SCTs are present, who operates the CT Log that issued the SCT, and what state the CT Log that issued the SCT was in, both at the time the certificate is being validated, and at the time the SCT was created by the CT Log.
**AND** there is at least one SCT from a non-Google Log, qualified at time
of check, presented via any method.
1. An Embedded SCT from a log qualified at the time of check is presented;
**CT Compliance is required in the following circumstances:**
* EV TLS certificates issued on-or-after 1 January 2015 are required to be CT Compliant in order to be recognized as EV in Chrome
* All TLS certificates issued on-or-after 1 May 2018 are required to be CT Compliant in order to successfully validate in Chrome
* TLS certificates, regardless of issuance date, for sites whose operators have opted into Expect-CT enforcement are required to be CT compliant to successfully validate in Chrome after first navigating to the site and caching the Expect-CT enforcement setting.
**AND** there is at least one Embedded SCT from a Google Log, once or
currently qualified;
Depending on how the SCTs are presented to Chrome, CT compliance can be achieved by meeting one of the following two criteria:
**AND** there is at least one Embedded SCT from a non-Google Log, once or
currently qualified;
**Embedded SCTs:**
1. At least one Embedded SCT from a CT Log that was `Qualified`, `Usable` or `ReadOnly` at the time of check; and
2. At least one Embedded SCT from a Google CT Log that was `Qualified`, `Usable`, `ReadOnly`, or `Retired` at the time of check; and
3. At least one Embedded SCT from a non-Google CT Log that was `Qualified`, `Usable`, `ReadOnly`, or `Retired` at the time of check; and
4. There are SCTs from at least N distinct CT Logs that were `Qualified`, `Usable`, `ReadOnly`, or `Retired` at the time of check, where N is defined in the following table:
**AND** there are Embedded SCTs from AT LEAST the number of logs once or
currently qualified shown in Table 1.
"Once or currently qualified" means that the log was qualified or pending
qualification at the time of certificate issuance, that the log was accepted
prior to the time of check, but that the log may have been disqualified
following acceptance, prior to the time of check.
"Embedded SCT" means an SCT delivered via an X.509v3 extension within the
certificate.
**Table 1**
| Lifetime of Certificate | Number of SCTs from distinct logs |
| Certificate Lifetime | Number of SCTs from distinct CT Logs |
|:---:|:---:|
| < 15 months | 2 |
| >= 15, <= 27 months | 3 |
| > 27, <= 39 months | 4<sup>[1](#footnote1)</sup> |
| >= 15 and <= 27 months | 3 |
| > 27 and <= 39 months | 4 |
| > 39 months | 5 |
<a name="footnote1"><sup>1</sup></a> EV certificates should never have a
lifetime over 27 months.
**SCTs delivered via OCSP or TLS:**
1. At least one SCT from a Google CT Log that was `Qualified`, `Usable`, or `ReadOnly` at the time of check; and
2. At least one SCT from a non-Google CT Log that was `Qualified`, `Usable`, or `ReadOnly` at time of check.
Note that, so long as one of the above conditions is met by some combination
of SCTs presented in the handshake, additional SCTs, regardless of the status
of the SCT, will not affect the CT Qualification status positively or
negatively.
**Important note: many TLS servers do not support OCSP Stapling or the TLS
extension, so CAs should be prepared to insert SCTs into issued EV
certificates to maintain the EV indication.**
### Important Notes
So long as one of the above CT Compliance criteria is met by some combination of SCTs presented in the handshake, additional SCTs, regardless of the status of the SCT, will not affect a certificates CT Compliance status positively or negatively.
## Timeouts
In order to contribute to a certificates CT Compliance, an SCT must have been issued before the Logs `Retired` timestamp, if one exists. Chrome uses the earliest SCT among all SCTs presented to evaluate CT compliance against CT Log `Retired` timestamps. This accounts for edge cases in which a CT Log becomes `Retired` during the process of submitting certificate logging requests.
The list of qualifying and once qualifying logs will be periodically refreshed
during regular Chrome releases. If the installed version of Chrome has not
applied security updates for a significant amount of time then CT checking
will be disabled.
"Embedded SCT" means an SCT delivered via the SignedCertificateTimestampList
X.509v3 extension within the certificate itself. Many TLS servers do not support OCSP Stapling or the TLS extension, so CAs should be prepared to embed SCTs into issued certificates to ensure successful validation and/or EV treatment in Chrome.
---
## How CT Logs are added to Chrome
The criteria for how CT Logs can become `Qualified`, as well as what circumstances can cause them to become `Retired`, can be found in the [Chrome CT Log Policy](log_policy.md).
---
## CT Enforcement Timeout
The list of CT Logs included in Chrome will be periodically refreshed during regular Chrome releases. If the installed version of Chrome has not applied security updates for 70 days (10 weeks) or more, then CT enforcement will be disabled.
This timeout provides a critical assurance to the CT ecosystem that new CT Logs are able to transition to `Usable` within a fixed amount of time after becoming `Qualified`. All CT-enforcing user agents are strongly encouraged to implement a similar enforcement timeout to maximize compatibility with the existing ecosystem.

153
enterprises.md Normal file
Просмотреть файл

@ -0,0 +1,153 @@
# Certificate Transparency for Enterprises
## Locally-trusted CAs
Certificate Transparency only applies to CAs that are publicly-trusted - that
is, CAs that are supported by your browser or device out of the box, without
any additional configuration steps.
For CAs that have been manually installed, provided those certificates are not
or have not been publicly-trusted, it's not necessary to enable support for
Certificate Transparency. Further, Certificate Transparency Logs will not
accept certificates from those CAs, thus it's not possible to support CT.
In some cases, an Enterprise may have a locally-trusted CA that has been
manually installed, but it was previously publicly-trusted. For example, this
CA may have been removed by a browser or an OS for not complying with the
root store policies, but the Enterprise may still have a dependency on
trusting this CA. In these cases, the Enterprise can use
[Enterprise Policies](#Enterprise-Policies) to configure how Certificate
Transparency will be enforced for those CAs.
## Private Domain Names
For Enterprises that have domain names that are internal to their organization,
and do not need to be publicly-trusted by default, several options exist to
enable these domains to be kept private, while allowing the certificates to
still be used, without error, for users in their organization.
The recommended option is to no longer rely on publicly-trusted certificates
to serve these domains, as they are organization specific. For example, such
organizations can use a private CA, which [several](https://aws.amazon.com/certificate-manager/private-certificate-authority/)
[CAs](https://www.digicert.com/private-pki/) [offer](https://www.comodo.com/business-security/pki-management/certificate-manager.php).
Using a hosted, managed PKI may help organizations more rapidly respond to
change in the TLS ecosystem, such as changes to certificate algorithms or
support for new protocols.
Another option is to request that the publicly-trusted CA not log the
certificate. This will prevent this certificate from being trusted by default,
but organizations that manage their devices or users can override this through
[Enterprise Policies](#Enterprise-Policies) to enable these certificates to be
trusted for users in their Enterprise.
Finally, organizations may manage their own PKI in-house, using CA
software such as [CFSSL](https://github.com/cloudflare/cfssl), [Boulder](https://github.com/letsencrypt/boulder),
[EJBCA](https://www.ejbca.org/) or
[Active Directory Certificate Services](https://msdn.microsoft.com/en-us/library/ff630887.aspx).
Managing certificates in-house may be more complex and security risky, but
offers an alternative solution to partnering with a certificate provider.
## Legacy CAs
Some Enterprises rely on Certificate Authorities that have not been audited to
the same standard as other CAs or been operated to the same security
requirements. These CAs would not be trusted in new products, nor other root
programs, but may be trusted on one or more platforms that Chrome runs on.
Because they are trusted by default, they are subject to the Chrome's policies
on requiring CT, but due to their legacy status, may not be prepared. While the
requirement to disclose new certificates via Certificate Transparency has been
communicated, some may not do so, causing their new certificates to not be
trusted. This is most common with CAs run by governments, as they rarely meet the
required security standards of a widely-trusted CA.
Organizations that need to use certificates from these CAs should be aware
that their certificates will not be trusted if they do not support CT, and so
should look for CAs that do support CT. Alternatively, supporting CT via TLS
may be the only way to ensure these certificates continue to work, but that
requires the Enterprise constantly keep track of changes regarding Certificate
Transparency.
Organizations that need to trust certificates from these CAs, such as when
talking to other organizations that need to use these CAs, can configure
[Enterprise Policies](#Enterprise-Policy) for users in their organization,
which will allow trust in these certificates. As these only apply to Enterprise
users, these policies are not suitable for making these certificates trusted
more widely.
## Enterprise Policies
Several Chrome-specific policies exist that allow Enterprises to configure
their machines or users to disable Certificate Transparency for certain cases.
These policies are documented in the
[master policy list](https://cloud.google.com/docs/chrome-enterprise/policies),
but detailed further below.
### CertificateTransparencyEnforcementDisabledForUrls
This [policy](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForUrls)
has been available since Chrome 53, and allows for disabling Certificate
Transparency enforcement for a certain set of domains or subdomains, without
disabling Certificate Transparency altogether.
If you wish to disable CT for a given hostname, and all of its subdomains, then
the domain is simply entered into the list. For example, `example.com` will
disable CT for `example.com` and all subdomains.
If you wish to disable CT only for a given hostname, but wish to ensure that
subdomains will still have CT enabled, then prefix the domain with a leading
dot. For example, `.example.com` will disable CT for `example.com` exactly,
while leaving it enabled for subdomains.
### CertificateTransparencyEnforcementDisabledForCas
This [policy](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForCas),
available since Chrome 57, allows for disabling Certificate Transparency
enforcement if certain conditions are met in the trusted certificate chain.
This allows disabling CT without having to list all of the domain names, but
only for certificates issued to a specific organization.
Certificates are specified in this policy by applying Base64 to a hash of their
subjectPublicKeyInformation, as well as specifying the hash algorithm used.
This format is very similar to that used by
[HTTP Public Key Pinning](https://tools.ietf.org/html/rfc7469) (HPKP), so that
sites can use the same [examples](https://tools.ietf.org/html/rfc7469#appendix-A)
or [tools](https://report-uri.com/home/pubkey_hash) used to generate HPKP
hashes to determine how to configure the policy. Note that while both use
Base64, an HPKP hash will be in the form `pin-sha256="hash"`, while the policy
will be in the form `sha256/hash`.
To disable Certificate Transparency for these certificates, the certificate
must match one of the following conditions:
1. The hash specified is of the server certificate's subjectPublicKeyInfo.
2. The hash specified is of an intermediate CA, and that intermediate CA has
a nameConstraints extension with one or more directoryNames in the
permittedSubtrees of that extension.
3. The hash specified is of an intermediate CA, that intermediate CA contains
one or more organizationName (O) attribute in the subject, and the server
certificate's has the same number of organizationName attributes, with
byte-for-byte identical values, in the same exact order.
### CertificateTransparencyEnforcementDisabledForLegacyCas
This [policy](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=CertificateTransparencyEnforcementDisabledForLegacyCas),
available since Chrome 67, allows for disabling Certificate Transparency
enforcement for certain legacy CAs that have not adopted modern security and
audit requirements required of publicly-trusted CAs. This is particularly
tailored towards CAs that are trusted on some platforms that Chrome runs on,
but are not trusted on ChromeOS or Android, due to not meeting the necessary
security requirements.
CAs are specified in this policy by applying Base64 to a hash of their
subjectPublicKeyInformation, the same as in
[CertificateTransparencyEnforcementDisabledForCAs](#CertificateTransparencyEnforcementDisabledForCas).
However, these CAs must also be recognized as Legacy CAs in the
[`/net/data/ssl/root_stores/root_stores.json`](/net/data/ssl/root_stores/root_stores.json)
file, which means that they are not trusted on ChromeOS or Android, but are
trusted on another platform that Chrome runs on.
This policy is the riskiest of the three Enterprise policies, in that such
legacy CAs can represent the greatest security threat to an organization, as
they lack either the audits or compliance with industry best practice and root
store requirements. Enterprises should only enable this policy if no other
option meets their needs.

24
glossary.md Normal file
Просмотреть файл

@ -0,0 +1,24 @@
# Glossary of CT Terms
The folloiwing is a list of commonly-used terms used in the Chrome CT Policy, Chrome Log Policy, and RFC 6962:
**Signed Certificate Timestamp (SCT):**
**Maximum Merge Delay (MMD):**
**CT Log:**
**Log Operator:**
**CT-enforcing User Agent:**
**Certification Authority (CA):**
**CT Log Operator Bug:** All CT Log Operators are required to file a CT Log Operator bug on the Chromium issue tracker in order to apply for inclusion of their CT Log(s) to Chrome. This bug tracks all state changes for all CT Logs operated by this organization.
**CT Log States:**
**CT Compliance:**
**Temporal Sharding:** CT Logs that specify a certificate expiry range and reject logging submissions for certificates that expire outside of this range are said to be temporally sharded. To provide for ecosystem agility and limit CT Log size, all new CT Logs are required to be temporally sharded to be added to Chrome.
**Logging Submission:**

70
log_list.md Normal file
Просмотреть файл

@ -0,0 +1,70 @@
# Recognized Logs
The following table includes information about the Certificate Transparency Logs
that are recognized by Chromium. It includes information about who operates the
log, the name the log has been given, and the URL that can be used for logging
certificates or inspecting the certificates that have been logged.
**_Note: The authoritative list is maintained in the [Chromium code base](https://cs.chromium.org/chromium/src/components/certificate_transparency/data/log_list.json). This is merely informational._**
## Qualified Logs
| Log Operator | Log Name | Log URL | MMD | Qualified In | Current State |
| ----------------------------------------- | --------------------------------------- | ------------------------------------------ | -------- | ------------------------------------- | ------------- |
| [Google](https://www.google.com/) | Google 'Aviator' Log | https://ct.googleapis.com/aviator | 24 hours | [Chrome 35](https://crrev.com/237785) | Read Only |
| [Google](https://www.google.com/) | Google 'Pilot' Log | https://ct.googleapis.com/pilot/ | 24 hours | [Chrome 35](https://crrev.com/237785) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert's Certificate Transparency log | https://ct1.digicert-ct.com/log/ | 24 hours | [Chrome 41](https://crrev.com/309831) | Usable |
| [Google](https://www.google.com/) | Google 'Rocketeer' Log | https://ct.googleapis.com/rocketeer | 24 hours | [Chrome 43](https://crrev.com/325382) | Usable |
| [Google](https://www.google.com/) | Google 'Icarus' Log | https://ct.googleapis.com/icarus/ | 24 hours | [Chrome 55](https://crrev.com/429670) | Usable |
| [Google](https://www.google.com/) | Google 'Skydiver' Log | https://ct.googleapis.com/skydiver/ | 24 hours | [Chrome 55](https://crrev.com/429670) | Usable |
| [Sectigo](https://sectigo.com/) | Sectigo 'Mammoth' Log | https://mammoth.ct.comodo.com/ | 24 hours | [Chrome 60](https://crrev.com/482145) | Usable |
| [Sectigo](https://sectigo.com/) | Sectigo 'Sabre' Log | https://sabre.ct.comodo.com/ | 24 hours | [Chrome 60](https://crrev.com/482145) | Usable |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2020' Log | https://ct.cloudflare.com/logs/nimbus2020/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2021' Log | https://ct.cloudflare.com/logs/nimbus2021/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
| [Google](https://www.google.com/) | Google 'Argon2020' Log | https://ct.googleapis.com/logs/argon2020/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
| [Google](https://www.google.com/) | Google 'Argon2021' Log | https://ct.googleapis.com/logs/argon2021/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2020' Log | https://yeti2020.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2021' Log | https://yeti2021.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2022' Log | https://yeti2022.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2020' Log | https://nessie2020.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2021' Log | https://nessie2021.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2022' Log | https://nessie2022.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Usable |
| [Google](https://www.google.com/) | Google 'Xenon2020' Log | https://ct.googleapis.com/logs/xenon2020/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
| [Google](https://www.google.com/) | Google 'Xenon2021' Log | https://ct.googleapis.com/logs/xenon2021/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
| [Google](https://www.google.com/) | Google 'Xenon2022' Log | https://ct.googleapis.com/logs/xenon2022/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Usable |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2022' Log | https://ct.cloudflare.com/logs/nimbus2022/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2023' Log | https://ct.cloudflare.com/logs/nimbus2023/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2023' Log | https://nessie2023.ct.digicert.com/log/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2023' Log | https://yeti2023.ct.digicert.com/log/ | 24 hours | [Chrome 76](https://crrev.com/666475) | Usable |
| [Google](https://www.google.com/) | Google 'Xenon2023' Log | https://ct.googleapis.com/logs/xenon2023/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
| [Google](https://www.google.com/) | Google 'Argon2022' Log | https://ct.googleapis.com/logs/argon2022/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
| [Google](https://www.google.com/) | Google 'Argon2023' Log | https://ct.googleapis.com/logs/argon2023/ | 24 hours | [Chrome 77](https://crrev.com/689620) | Usable |
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2020' Log | https://oak.ct.letsencrypt.org/2020/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2021' Log | https://oak.ct.letsencrypt.org/2021/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2022' Log | https://oak.ct.letsencrypt.org/2022/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Usable |
### Once, but no longer, Qualified Logs
| Log Operator | Name | Log URL | MMD | Qualified In | Last Accepted SCT |
| ----------------------------------------- | --------------------------- | ------------------------------------------ | -------- | ------------------------------------- | ---------------------------- |
| [Certly](https://certly.io/) | Certly.IO Log | https://log.certly.io | 24 hours | [Chrome 43](https://crrev.com/325382) | 15 April 2016 00:00:00 UTC. |
| [Izenpe](https://www.izenpe.com/) | Izenpe Log | https://ct.izenpe.com | 24 hours | [Chrome 44](https://crrev.com/326301) | 30 May 2016 00:00:00 UTC. |
| [Venafi](https://www.venafi.com/) | Venafi CT Log Server | https://ctlog.api.venafi.com/ct/v1 | 24 hours | [Chrome 47](https://crrev.com/349170) | 28 Feb 2017 18:42:26 UTC. |
| [WoSign](https://www.wosign.com/) | WoSign Log | https://ctlog.wosign.com/ | 24 hours | [Chrome 54](https://crrev.com/414378) | 12 Feb 2018 23:59:59 UTC. |
| [StartCom](https://www.startssl.com/) | StartCom CT Log | https://ct.startssl.com/ | 24 hours | [Chrome 54](https://crrev.com/414440) | 12 Feb 2018 23:59:59 UTC. |
| [CNNIC](https://cnnic.cn/) | CNNIC CT Log | https://ctserver.cnnic.cn/ | 24 hours | [Chrome 53](https://crrev.com/396817) | 18 Sep 2018 00:00:00 UTC. |
| [DigiCert](https://www.digicert.com/) | Symantec Log | https://ct.ws.symantec.com | 24 hours | [Chrome 45](https://crrev.com/483625) | 16 Feb 2019 00:00:00 UTC. |
| [DigiCert](https://www.digicert.com/) | Symantec 'Vega' Log | https://vega.ws.symantec.com/ | 24 hours | [Chrome 50](https://crrev.com/376143) | 16 Feb 2019 00:00:00 UTC. |
| [DigiCert](https://www.digicert.com/) | Symantec 'Sirius' Log | https://sirius.ws.symantec.com/ | 24 hours | [Chrome 60](https://crrev.com/481160) | 16 Feb 2019 00:00:00 UTC. |
| [Google](https://www.google.com/) | Google 'Argon2018' Log | https://ct.googleapis.com/logs/argon2018/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2018' Log | https://ct.cloudflare.com/logs/nimbus2018/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2018' Log | https://yeti2018.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Rejected - Shard Expired |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2018' Log | https://nessie2018.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Rejected - Shard Expired |
| [Cloudflare](https://www.cloudflare.com/) | Cloudflare 'Nimbus2019' Log | https://ct.cloudflare.com/logs/nimbus2019/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Yeti2019' Log | https://yeti2019.ct.digicert.com/log/ | 24 hours | [Chrome 67](https://crrev.com/559734) | Rejected - Shard Expired |
| [DigiCert](https://www.digicert.com/) | DigiCert 'Nessie2019' Log | https://nessie2019.ct.digicert.com/log/ | 24 hours | [Chrome 72](https://crrev.com/620903) | Rejected - Shard Expired |
| [Google](https://www.google.com/) | Google 'Argon2019' Log | https://ct.googleapis.com/logs/argon2019/ | 24 hours | [Chrome 65](https://crrev.com/540254) | Rejected - Shard Expired |
| [Google](https://www.google.com/) | Google 'Xenon2019' Log | https://ct.googleapis.com/logs/xenon2019/ | 24 hours | [Chrome 73](https://crrev.com/634940) | Rejected - Shard Expired |
| [Let's Encrypt](https://letsencrypt.org/) | Let's Encrypt 'Oak2019' Log | https://oak.ct.letsencrypt.org/2019/ | 24 hours | [Chrome 78](https://crrev.com/703880) | Rejected - Shard Expired |
| [Venafi](https://www.venafi.com/) | Venafi Gen2 CT log | https://ctlog-gen2.api.venafi.com/ | 24 hours | [Chrome 59](https://crrev.com/471318) | Rejected - All Certs Expired |
| [DigiCert](https://www.digicert.com/) | DigiCert Log Server 2 | https://ct2.digicert-ct.com/log/ | 24 hours | [Chrome 60](https://crrev.com/481160) | 04 May 2020 00:00:40 UTC |

Просмотреть файл

@ -1,110 +1,83 @@
# Certificate Transparency Log Policy
As specified by [RFC 6962](https://tools.ietf.org/html/rfc6962), Certificate Transparency includes a multi-party protocol for providing cryptographically-verifiable proofs to audit the issuance and security practices of Certificate Authorities.
To improve trust and security when communicating with secure services,
Chromium-derived products, such as Google Chrome, will require certificates
presented by servers to be publicly audited using Certificate Transparency.
As specified by [RFC 6962](https://tools.ietf.org/html/rfc6962), Certificate
Transparency includes a multi-party protocol for providing
cryptographically-verifiable proofs to audit the issuance and security
practices of Certificate Authorities.
To support such auditing, Chrome includes a list of Logs that have passed an application process and are recognized to be operating in the public interest. This Certificate Transparency Log Policy ("Policy") sets forth how a Certificate Transparency Log Operator may have its Log recognized within Chrome as well as the ongoing expectations of these Log Operators. This policy may be updated by Google from time to time.
To support such auditing, Chromium-derived products include a list of Logs
that are recognized to be operating in the public interest. This Certificate
Transparency Log Policy ("Policy") sets forth how a Certificate Transparency
Log Operator may have its Log recognized within Chromium, ongoing expectations
of Log Operators, and how Chromium developers may preserve the integrity of
recognized Logs. This policy may be updated by Google from time to time.
---
When a Log is recognized, Signed Certificate Timestamps (SCT) issued by that
Log will be granted special treatment within the Chromium user interfaces,
such as by indicating that the associated certificate certified by the SCT has
been publicly noted by the Log Operator.
## Application Process
Before applying for their first CT Logs to be added to Chrome, new CT Log Operators should first read and fully comprehend the ongoing requirements for CT Logs specified in this Policy. Once a Log Operator is confident they can meet these requirements and has deployed a set of temporally-sharded CT Logs ready for application, they should follow the below process for adding these Logs to Chrome.
## Application
### New CT Log Operators
New CT Log Operators should begin their application process by first [filing a new CT Log Operator bug](https://bugs.chromium.org/p/chromium/issues/entry) on the Chromium Issue Tracker, and provide:
* Contact Information for the Log Operator, including:
* An email or e-mail alias that is continuously monitored by the Log Operator
* A list of person(s) authorized to represent the Log Operator when communicating with the Chrome team
To apply for a Log to be included within Chromium, the Log Operator must
[file a new bug](https://bugs.chromium.org/p/chromium/issues/entry) on the
Chromium Issue Tracker, and provide:
* Contact Information for the Log Operator, including:
* An email or e-mail alias that is continuously monitored by the Log
Operator
* A phone number
* A list of person(s) authorized to represent the Log Operator
* A public HTTP endpoint that responds to all Log Client Messages indicated
in RFC 6962, Section 4
* The Log's public key, attached as a binary file containing the DER
encoding of the SubjectPublicKeyInfo ASN.1 structure
* A description of the Log, including applicable policies or requirements
for logging certificates
* The Maximum Merge Delay (MMD) of the Log
* All of the Accepted Root Certificates of the Log
* Whether the Log will reject certificate logging requests based on any of the Permissible Logging Rejection Criteria and if so, which criteria will be used as a basis for rejection by this Log.
This bug will be used to track all CT Logs operated by this Log Operator for as long as any Logs operated by this organization are `Pending`, `Qualified`, `Usable`, `ReadOnly`, or `Retired`. By creating a new CT Log Operator bug, applicants are asserting they are organizationally independent from all existing CT Log Operators, which can be observed in the [log_list.json](https://www.gstatic.com/ct/log_list/v2/log_list.json) file hosted by Google. If an organizational change occurs that alters this independence, CT Log Operators are required to notify Chrome at chrome-certificate-transparency@google.com as soon as possible.
After acceptance, Google will monitor the Log, including random compliance
testing, prior to its inclusion within Chromium. Such compliance testing will
include, but is not limited to, verifying the Logs conformance to RFC 6962,
and confirming the Log's uptime meets the requirements of this Policy and
confirming the Log is append-only and consistent from every point of view.
### Existing CT Log Operators
Once the Chrome team has confirmed the Log Operators contact information, or if an existing Log Operator is applying for additional CT Logs to be added to Chrome, the CT Log Operator must next provide the following information about the new CT Logs in their existing CT Log Operator bug:
* Public HTTP endpoints that respond to all Log Client Messages indicated in RFC 6962, Section 4
* The Logs public keys, attached as a binary file containing the DER encoding of the SubjectPublicKeyInfo ASN.1 structure
* A description of the Logs, including applicable policies or requirements for logging certificates
* The Maximum Merge Delay (MMD) of the Logs
* The set of Accepted Root Certificates of the Logs
* The expiry ranges of each Log in the form [rangeBegin, rangeEnd).
* Certificate expiry ranges for a set of Logs must be contiguous, with no gaps, and each expiry range should be between 6 and 12 months.
* Whether the Logs will reject logging submissions for expired or revoked certificates.
To enable monitoring, log operators are asked to include Google's
["Merge Delay Monitor Root"](mmd_monitor_root.crt) in the set of Accepted Root
Certificates of their logs.
After acceptance, Google will monitor the Logs, including random compliance testing, prior to its inclusion within Chrome. Such compliance testing will include, but is not limited to, verifying the Logs conformance to RFC 6962, confirming the Logs availability meets the requirements of this Policy, and confirming the Logs are append-only and consistent from every point of view.
To enable compliance monitoring, Log Operators will be asked to include Google's Merge Delay Monitor Root certificate in the set of accepted root certificates of their Logs.
---
## Ongoing Requirements of Included Logs
In order for their Logs to remain included within Chrome after first becoming `Qualified`, Log Operators must continue to operate these Logs in accordance with this Policy. Log Operators must:
* Monitor the [ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy) group for relevant updates to policy or requirements for CT Log Operators
* Have no outage that exceeds an MMD of more than 24 hours. Outages include, but are not limited to: network level outages, expiration of the Logs SSL certificate, a failure to accept new Certificates to be logged (with the exception of the conditions defined in the Logging Submission Acceptance section below), HTTP response status codes other than 200, or responses that include data that does not conform to RFC 6962.
* Conform to RFC 6962, including the implementation of all API endpoints defined within Section 4 of RFC 6962
* Not impose conditions on retrieving or sharing data from the Logs
* Maintain Log availability of 99% or above, with no outage lasting longer than the MMD (as measured by Google)
* Not present two or more conflicting views of the Merkle Tree at different times and/or to different parties.
* Incorporate a certificate for which an SCT has been issued by the Log within the MMD.
* When Logs receive a logging submission for an already-incorporated certificate, Logs must either return an existing SCT or, if creating a new one, add another certificate entry within the MMD such that the new SCT can be verified using the APIs specified in RFC 6962.
* Accept certificates issued by Googles Merge Delay Monitor Root to enable Google to monitor the Logs compliance to these policies.
* Operate their Logs in good faith, including, but not limited to each Log Operator:
* Verifiably incorporating all certificates into the Log for which SCTs have been issued, within the Logs MMD
* Maintaining the append-only property of the Log by providing consistent views of the Merkle Tree at all times and to all parties.
* Notify the Chrome team of any and all changes to information gathered during the Log Inclusion by detailing such changes in an update to the CT Log Operator bug on the [Chromium Issue Tracker](https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork%3ECertTrans) in which they requested Log Inclusion.
To remain included within Chromium-derived projects, Log Operators must
operate the Log in accordance with this Policy. Log Operators must:
Google will notify Log Operators of changes to these requirements as well as effective dates for those changes via announcements to the [ct-policy@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy). Log Operators that fail to meet these requirements will be in violation of this Policy, which may result in removal of the Log(s) from Chrome.
* Have no outage that exceeds an MMD of more than 24 hours.
Outages include, but are not limited to: network level outages, expiration
of the Logs SSL certificate, a failure to accept new Certificates to be
logged (with the exception of the Permissible Logging Rejection Criteria defined below), HTTP response status codes other than 200, or responses that
include data that does not conform to RFC 6962.
* Conform to RFC 6962, including the implementation of all API endpoints
defined within Section 4 of RFC 6962
* Not impose conditions on retrieving or sharing data from the Log
* Have 99% uptime, with no outage lasting longer than the MMD (as measured
by Google)
* Not present two or more conflicting views of the Merkle Tree at different
times and/or to different parties.
* Incorporate a certificate for which an SCT has been issued by the Log
within the MMD.
* If requested, accept certificates issued by a test CA run by Google to
enable Google to monitor the logs compliance to these policies.
* Be operated in good faith, including, but not limited to each Log
Operator:
* Verifiably logging all certificates within the Log for which SCTs have
been issued within the MMD
* Maintaining the append-only property of the of the Log by providing
consistent views of the Merkle Tree at all times and to all parties.
* Notify the Chromium developers of any and all changes to information
gathered during the Log Inclusion by detailing such changes in an update
to the bug on the [Chromium Issue Tracker](https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork%3ECertTrans)
in which they requested Log Inclusion.
---
Google will notify Log Operators, via announcements to the
[Chromium CT Policy Group](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy),
of changes to these requirements. Log Operators that fail to meet these
requirements will be in violation of the Log Inclusion Policy, which may
result in removal of the Log from the Chromium projects.
## Logging Submission Policy
### Accepted Root Certificates
In order to maintain broad utility to Chrome and its users, CT Logs are expected to accept logging submissions from CAs that are trusted by default in Chrome across all its supported platforms, including ChromeOS, Android, Linux, Windows, macOS, iOS. If a Log Operator plans to restrict the set of Accepted Root Certificates, this should be clearly stated in the CT Log Operator Application as well as the rationale for this restriction. **Note:** This restriction may prevent a CT Log from being accepted by Chrome for inclusion.
## Permissible Logging Rejection Criteria
### Rejecting Logging Submissions
CT Logs are permitted to reject logging submissions for certificates that meet certain conditions, such as being expired or revoked at the time the submission was made. A logging rejection means that the CT Log will not incorporate a given certificate entry into the Merkle Tree even if the certificate chains to an Accepted Root Certificate. Rejected logging submissions **must not** be issued an SCT by the CT Log.
Under certain circumstances, it is permissible for a Log to reject logging requests for certain classes of certificates. A logging rejection means that the Log will not incorporate a given certificate entry into the Merkle Tree even if the certificate chains to an Accepted Root Certificate. In accordance with this policy, rejected logging requests must not be issued an SCT by the Log.
If specified within the Log's Chromium Application, a Log may reject requests to log certificates that chain up to an Accepted Root Certificate based on one or more of the following bases:
* **Revocation Status**: If the Log determines that a certificate has been revoked by the issuing CA, it may reject the logging request. If the Log is unable to determine revocation status, it must accept the logging request and incorporate the entry into the Merkle Tree within the Log's MMD.
* **Certificate Expired**: If a logging request includes a certificate whose notAfter timestamp represents a point in time before the logging request is made, the Log may refuse to log the certificate entry.
* **Certificate Lifetime**: In order to control the growth of a Logs size, a Log Operator may specify a certificate expiry range for that Log, which must be included in the Logs Chromium Application in the form of two dates: [rangeBegin, rangeEnd). The certificate expiry range allows a Log to reject logging requests for certificates whose notAfter timestamp falls outside of this range, thus partitioning the set of publicly-trusted certificates that the Log will accept. In the spirit of operating Logs in the public interest, Log Operators who take advantage of this limitation are strongly encouraged to operate multiple Logs with staggered certificate expiry ranges to allow for logging of all currently valid publicly-trusted certificates.
If specified within the Application, a Log may reject submission to log certificates that chain up to an Accepted Root Certificate based on one or more of the following conditions:
* **Certificate Revoked:** If the Log determines that a certificate has been revoked by the issuing CA, it may reject the logging submission. If the Log is unable to determine revocation status, it must accept the logging submission and incorporate the entry into the Merkle Tree within the Log's MMD.
* **Certificate Expired:** If a logging submission includes a certificate whose notAfter timestamp represents a point in time before the logging submission was made, the Log may refuse to log the certificate entry. This criteria may be used even by legacy non-sharded CT Logs that do not set certificate expiry ranges.
The primary purpose of the permissible rejection criteria is to provide Log Operators with greater control over the growth and operation of a given Log instance while still performing the core functions of a trusted CT Log. Additionally, these criteria allow logs to be shielded from certain types of Denial of Service such as being spammed with the corpus of all expired certificates and being unable to respond to legitimate logging requests.
The primary purpose of allowing rejection of certain logging submissions is to provide Log Operators with greater control over the growth and operation of their Logs while still performing their core function. Additionally, these criteria allow Logs to be shielded from certain types of Denial of Service such as being spammed with the corpus of all expired certificates and being unable to respond to legitimate logging submissions.
### Temporal Sharding
In order to provide ecosystem agility and to control the growth of CT Log sizes, new CT Logs must be *temporally sharded*, defining a *certificate expiry range* denoted in the form of two dates: [rangeBegin, rangeEnd). The certificate expiry range allows a Log to reject otherwise valid logging submissions for certificates that expire before or after this defined range, thus partitioning the set of publicly-trusted certificates that each Log will accept.
In order to have their Logs accepted for inclusion, Log Operators should deploy and operate their Logs according to the following:
* The certificate expiry ranges for CT Logs must be no longer than one calendar year and should be no shorter than six months
* CT Logs must reject logging submissions for certificates whose notAfter timestamp falls outside the certificate expiry range
* Log Operators should deploy enough sharded CT Logs so that their certificate expiry ranges cover a contiguous period of time, spanning from the current time to 3-4 years in the future
* Many Log Operators find it convenient to define these ranges on the calendar year, so an application in 2020 would include e.g. Log2020, Log2021, Log2022, Log2023.
* CT Logs will be removed from Chrome once their certificate expiry range has passed. When Log Operators in good standing have one of their Logs removed in this manner, they should stand up a new CT Log whose expiry range extends the set of contiguous expiry ranges
* Following the example from above, when Log2020 is removed in early 2021, the Log Operator should stand up Log2024 and apply for its inclusion, following the Application Process defined above.
---
## Policy Violations
The Chromium developers include Logs at their sole discretion, to further
public auditability of Certificate Authorities. Upon learning of a Logs
potential violation of this Policy, the Chromium Authors will review the
information and may take corrective actions to preserve the integrity of its
Log program. The Chromium Authors may remove Logs at any time, and for any
reason.
The Chrome team includes CT Logs at their sole discretion, to further public auditability of Certificate Authorities. Upon learning of a Logs potential violation of this Policy, they will review the information and may take corrective actions to preserve the integrity of its CT Log program. CT Logs may be removed from Chrome at any time, and for any reason.

147
log_states.md Normal file
Просмотреть файл

@ -0,0 +1,147 @@
# Certificate Transparency Log Lifecycle
## Introduction
Certificate Transparency (CT) is a technology and an ecosystem designed to ensure that TLS certificates issued by publicly-trusted Certification Authorities (CAs) are detectable by website operators shortly after they are first able to validate in CT-enforcing user agents, such as Chrome. In order to achieve this goal, user agents rely on organizations called Log Operators to stand up and operate infrastructure called CT Logs and apply for inclusion to be recognized by these user agents.
The purpose of this document is to describe the lifecycle of a CT Log, represented by a set of states and state transitions, and explain what these states mean for Log Operators, CAs, CT Monitors, Site Operators, and Chrome.
---
## CT Log State Machine
When the JSON schema for CT Log Lists was updated to [v2](https://www.gstatic.com/ct/log_list/v2/log_list_schema.json) in 2019, several CT Log states were formalized that did not exist when the CT enforcement logic in Chrome was implemented. Some of these states are related to CT enforcement, others represent a stage of the CT Log application process, while others still are external signals to CAs and CT Monitors.
```
+------------------------+
| |
| V
PENDING ---> QUALIFIED ---> USABLE ---> READONLY----+
| | | | | | |
| | | | | V |
| | +--------|---+----> RETIRED |
| | | | V
+-----------+------------+-------------+----> REJECTED
```
In the above state machine, the nodes represent all possible CT Log states and the directional edges represent possible state transitions. The remainder of this document describes how CT Logs transition into and out of these states, what is expected of CT Logs in these states, and finally, how the CT Log states map to Chrome behavior.
---
## `Pending`
When a Log Operator requests for a CT Log to be added to Chrome, the CT Log is first placed into the `Pending` state. While the Log undergoes its initial compliance monitoring period, it remains in the `Pending` state until it is either added to Chrome or a determination is made to reject the application.
**How `Pending` CT Logs transition to other states:**
* `Pending` CT Logs transition to `Qualified` when they are first added to Chrome after a successful compliance monitoring period.
* `Pending` CT Logs transition to `Rejected` if serious or sustained violations of RFC 6962 or the [CT Log Policy](log_policy.md) are detected during the application process, or if the Log Operator indicates they are withdrawing the application for inclusion in Chrome.
**Expected Log Behavior:**
While in the `Pending` state, CT Logs are expected to abide by all ongoing requirements defined in the [Certificate Transparency Log Policy](log_policy.md), including availability requirements, RFC compliance, and timely notification of changes to Log Operation.
**Chrome Behavior:**
`Pending` Logs are not included in the CT Log List in Chrome. When evaluated in CT-enforcing versions of Chrome, SCTs from CT Logs in the `Pending` state at time of check do not contribute towards CT Compliance for either the Embedded SCT or the OCSP/TLS SCT criteria.
---
## `Qualified`
CT Logs that successfully pass the initial compliance monitoring period are placed in the `Qualified` state if there are no major issues observed during this period. `Qualified` CT Logs are added to the list checked into Chromium and get included in a future version of Chrome. `Qualified` CT Logs must meet an ongoing set of compliance and availability requirements in order to remain included in Chrome.
**How `Qualified` CT Logs transition to other states:**
* `Qualified` CT Logs transition to `Usable` within a fixed period of time after becoming `Qualified`, so long as they continue to comply with the [CT Log Policy](log_policy.md).
* `Qualified` CT Logs transition to `Retired` if they demonstrate a serious or sustained pattern of CT Policy or RFC compliance issues, or if the Log Operator ceases operation of their CT Log(s). Due to the inability for Chrome to distinguish between intentional and accidental non-compliance, such issues are treated as highest possible severity, which results in the CT Log being `Retired`.
* `Qualified` CT Logs transition to `Rejected` if all certificates contained therein are expired or if it is past the end of their certificate expiry range specified in their Chromium CT Log application. Notably, the `Qualified` to `Rejected` transition is not used as a more severe response to a CT Logs compliance issues.
**Expected Log Behavior:**
While in the `Qualified` state, CT Logs are expected to abide by all ongoing requirements defined in the [Certificate Transparency Log Policy](log_policy.md), including availability requirements, RFC compliance, and timely notification of changes to Log Operation.
**Chrome Behavior:**
`Qualified` CT Logs are periodically imported to the list of CT Logs recognized by Chrome. When evaluated in CT-enforcing versions of Chrome, SCTs from CT Logs in the `Qualified` state at time of check contribute towards CT Compliance for both the Embedded SCT and the OCSP/TLS SCT criteria.
---
## `Usable`
Once a CT Log becomes `Qualified`, there will be a period of time in which older versions of Chrome are still enforcing CT but are not yet aware of this newly `Qualified` CT Log. Certificates accompanied by SCTs from such a newly-`Qualified` CT Log would fail validation in these non-updated clients, so the `Qualified` Log state is insufficient on its own to indicate safeness for production CT Logging. The `Usable` Log state captures this notion of safety by indicating to CAs and site operators that all CT-enforcing versions of Chrome now recognize a given newly-`Qualified` CT Log.
Newly-`Qualified` CT Logs become `Usable` when they have been added to the CT Log List for all CT-enforcing versions of Chrome. This is achieved either by Chrome clients updating to a version in which this CT Log has been added or by older clients becoming 10 or more weeks out-of-date and thus disabling CT enforcement. Rather than being a distinct state recognized by any given Chrome client, the `Usable` state can be thought of as a signal to the CT ecosystem, representing the distributed state of all CT-enforcing user agents now recognizing these CT Logs.
**How `Usable` CT Logs transition to other states:**
* `Usable` CT Logs transition to `Retired` if they demonstrate a serious or sustained pattern of CT Policy or RFC compliance issues, or if the Log Operator ceases operation of their CT Log(s). Due to the inability for Chrome to distinguish between intentional and accidental non-compliance, such issues are treated as highest possible severity, which results in the CT Log being `Retired`.
* `Usable` CT Logs transition to `Rejected` if all certificates contained therein are expired or if it is past the end of their certificate expiry range specified in their CT Log application. Notably, the `Usable` to `Rejected` transition is not used as a more severe response to a CT Logs compliance issues.
**Expected Log Behavior:**
While in the `Usable` state, CT Logs are expected to abide by all ongoing requirements defined in the [Certificate Transparency Log Policy](log_policy.md), including availability requirements, RFC compliance, and timely notification of changes to Log Operation.
**Chrome Behavior:**
The `Usable` state is not a state that is specifically recognized by Chrome clients and is functionally equivalent to `Qualified` and `ReadOnly` in terms of SCTs from such Logs contributing towards CT compliance.
`Usable` CT Logs are imported to the list of CT Logs recognized by Chrome, usually from when they first became `Qualified`. When evaluated in CT-enforcing versions of Chrome, SCTs from CT Logs in the `Usable` state at time of check contribute towards CT Compliance for both the Embedded SCT and the OCSP/TLS SCT criteria.
---
## `ReadOnly`
If a Log Operator wishes to cease accepting certificate logging requests, they may request that their `Qualified` or `Usable` CT Log(s) be placed in the `ReadOnly` state. CT Logs that become `ReadOnly` mode are making an assertion that they will stop issuing new SCTs, but will continue to operate the CT Log in accordance with the [Certificate Transparency Log Policy](log_policy.md).
When a Log becomes `ReadOnly`, the final tree size is published to the Google-hosted [CT Log List](https://www.gstatic.com/ct/log_list/v2/log_list.json) to signal that this Log should not grow past this point. To help ensure this behavior, CT Monitors should continue monitoring `ReadOnly` Logs until they become `Retired` or `Rejected`.
**How `ReadOnly` CT Logs transition to other states:**
* `ReadOnly` CT Logs transition to `Retired` if they demonstrate a serious or sustained pattern of CT Policy or RFC compliance issues, or if the Log Operator ceases operation of their CT Log(s). Due to the inability for Chrome to distinguish between intentional and accidental non-compliance, such issues are treated as highest possible severity, which results in the CT Log being `Retired`.
* `ReadOnly` CT Logs transition to `Rejected` if all certificates contained therein are expired or if it is past the end of their certificate expiry range specified in their CT Log application. Notably, the `ReadOnly` to `Rejected` transition is not used as a more severe response to a CT Logs compliance issues.
**Expected Log Behavior:**
While in the `ReadOnly` state, CT Logs are expected to abide by all ongoing requirements defined in the [Certificate Transparency Log Policy](log_policy.md), including availability requirements, RFC compliance, and timely notification of changes to Log Operation.
**Chrome Behavior:**
The `ReadOnly` state is not a state that is directly recognized by Chrome clients, but rather is treated as functionally equivalent to `Qualified` and `Usable` in terms of CT enforcement.
`ReadOnly` CT Logs are imported to the list of CT Logs recognized by Chrome, usually from when they first became `Qualified`. When evaluated in CT-enforcing versions of Chrome, SCTs from CT Logs in the `ReadOnly` state at time of check contribute towards CT Compliance for both the Embedded SCT and the OCSP/TLS SCT criteria.
---
## `Retired`
A `Retired` Log is one that was at one point `Qualified`, but has stopped being relied upon for the creation of new SCTs. CT Logs usually enter the `Retired` state due to a failure to adhere to the ongoing requirements outlined in the [Certificate Transparency Log Policy](log_policy.md).
To increase the CT ecosystems resilience against CT Log failure, existing certificates relying on embedded SCTs that were issued before a Logs Retirement timestamp can still contribute to CT Compliance for certificates using Embedded SCTs. However, since they can be modified without certificate re-issuance, SCTs delivered via OCSP or TLS must come from CT Logs that are `Qualified`, `Usable`, or `ReadOnly` at time of check.
**How `Retired` CT Logs transition to other states:**
* `ReadOnly` CT Logs transition to `Rejected` if all certificates contained therein are expired or if it is past the end of their certificate expiry range specified in their CT Log application. Notably, the `ReadOnly` to `Rejected` transition is not used as a more severe response to a CT Logs compliance issues.
**Expected Log Behavior:**
Once a CT Log becomes `Retired`, there are no longer any expectations that it continues operation. Log Operators are encouraged to turn down `Retired` CT Logs and securely delete the Log key.
**Chrome Behavior:**
`Retired` Logs are included in the [CT Log List](https://cs.chromium.org/chromium/src/components/certificate_transparency/data/log_list.json) that is shipped in Chrome, but include both an indicator that the Log is now `Retired` as well as the corresponding Retirement timestamp.
Embedded SCTs from `Retired` Logs count towards certain requirements for CT compliance; however, as outlined in [Chrome CT Policy](ct_policy.md), in order for a certificate to be CT Compliant, SCTs from `Retired` Logs must be accompanied by at least one SCT from a Log that was `Qualified`, `Usable`, or `ReadOnly` at time of check.
SCTs from `Retired` Logs that are delivered via OCSP or TLS do not contribute towards CT Compliance, and failure to include sufficient SCTs from `Qualified`, `Usable`, or `ReadOnly` CT Logs at time of check will result in certificate validation failure in CT-enforcing versions of Chrome.
---
## `Rejected`
When all certificates contained in a CT Log have expired and the CT Log is no longer issuing new SCTs in response to logging requests, it will transition into the `Rejected` state. Additionally, if a CT Log fails its initial compliance monitoring period, it will skip straight to the `Rejected` state, since there should be no still-valid certificates relying on SCTs from this Log.
SCTs from `Rejected` CT Logs do not contribute in any way towards CT Compliance and should not be embedded in new certificates or delivered via OCSP or TLS.
Despite the fact that `Rejected` CT Logs are not included in either the CT Log List shipped in Chrome or the Log List hosted by Google, they are tracked internally to ensure that keys are not reused in future CT Logs applying for inclusion.
**How `Rejected` CT Logs transition to other states:**
* The `Rejected` state is the terminal state of the CT Log Lifecycle state machine. Once a CT Log enters the `Rejected` state, it can no longer transition to any of the other defined states.
**Expected Log Behavior:**
Once a CT Log becomes `Rejected`, there are no longer any expectations that it continues operation. Log Operators are encouraged to turn down `Rejected` CT Logs and securely delete the Log key.
**Chrome Behavior:**
`Rejected` Logs are not included in the CT Log List in Chrome. When evaluated in CT-enforcing versions of Chrome, SCTs from CT Logs in the `Rejected` state at time of check do not contribute towards CT Compliance for either the Embedded SCT or the OCSP/TLS SCT criteria.
---
## Considerations for Chromium Embedders and other CT User Agents
With these high-level Log state descriptions in mind, each CT-enforcing user agent may wish to further specify additional context for any of these states; however, it is important that user agent CT Policies remain compatible with one another to ensure CAs and site operators can continue to issue and serve certificates that will successfully validate across multiple user agents. We welcome discussion and feedback about CT Log state definitions in the ct-policy@chromium.org discussion forum.

110
logs.md Normal file
Просмотреть файл

@ -0,0 +1,110 @@
# Certificate Transparency Log Policy
To improve trust and security when communicating with secure services,
Chromium-derived products, such as Google Chrome, will require certificates
presented by servers to be publicly audited using Certificate Transparency.
As specified by [RFC 6962](https://tools.ietf.org/html/rfc6962), Certificate
Transparency includes a multi-party protocol for providing
cryptographically-verifiable proofs to audit the issuance and security
practices of Certificate Authorities.
To support such auditing, Chromium-derived products include a list of Logs
that are recognized to be operating in the public interest. This Certificate
Transparency Log Policy ("Policy") sets forth how a Certificate Transparency
Log Operator may have its Log recognized within Chromium, ongoing expectations
of Log Operators, and how Chromium developers may preserve the integrity of
recognized Logs. This policy may be updated by Google from time to time.
When a Log is recognized, Signed Certificate Timestamps (SCT) issued by that
Log will be granted special treatment within the Chromium user interfaces,
such as by indicating that the associated certificate certified by the SCT has
been publicly noted by the Log Operator.
## Application
To apply for a Log to be included within Chromium, the Log Operator must
[file a new bug](https://bugs.chromium.org/p/chromium/issues/entry) on the
Chromium Issue Tracker, and provide:
* Contact Information for the Log Operator, including:
* An email or e-mail alias that is continuously monitored by the Log
Operator
* A phone number
* A list of person(s) authorized to represent the Log Operator
* A public HTTP endpoint that responds to all Log Client Messages indicated
in RFC 6962, Section 4
* The Log's public key, attached as a binary file containing the DER
encoding of the SubjectPublicKeyInfo ASN.1 structure
* A description of the Log, including applicable policies or requirements
for logging certificates
* The Maximum Merge Delay (MMD) of the Log
* All of the Accepted Root Certificates of the Log
* Whether the Log will reject certificate logging requests based on any of the Permissible Logging Rejection Criteria and if so, which criteria will be used as a basis for rejection by this Log.
After acceptance, Google will monitor the Log, including random compliance
testing, prior to its inclusion within Chromium. Such compliance testing will
include, but is not limited to, verifying the Logs conformance to RFC 6962,
and confirming the Log's uptime meets the requirements of this Policy and
confirming the Log is append-only and consistent from every point of view.
To enable monitoring, log operators are asked to include Google's
["Merge Delay Monitor Root"](mmd_monitor_root.crt) in the set of Accepted Root
Certificates of their logs.
## Ongoing Requirements of Included Logs
To remain included within Chromium-derived projects, Log Operators must
operate the Log in accordance with this Policy. Log Operators must:
* Have no outage that exceeds an MMD of more than 24 hours.
Outages include, but are not limited to: network level outages, expiration
of the Logs SSL certificate, a failure to accept new Certificates to be
logged (with the exception of the Permissible Logging Rejection Criteria defined below), HTTP response status codes other than 200, or responses that
include data that does not conform to RFC 6962.
* Conform to RFC 6962, including the implementation of all API endpoints
defined within Section 4 of RFC 6962
* Not impose conditions on retrieving or sharing data from the Log
* Have 99% uptime, with no outage lasting longer than the MMD (as measured
by Google)
* Not present two or more conflicting views of the Merkle Tree at different
times and/or to different parties.
* Incorporate a certificate for which an SCT has been issued by the Log
within the MMD.
* If requested, accept certificates issued by a test CA run by Google to
enable Google to monitor the logs compliance to these policies.
* Be operated in good faith, including, but not limited to each Log
Operator:
* Verifiably logging all certificates within the Log for which SCTs have
been issued within the MMD
* Maintaining the append-only property of the of the Log by providing
consistent views of the Merkle Tree at all times and to all parties.
* Notify the Chromium developers of any and all changes to information
gathered during the Log Inclusion by detailing such changes in an update
to the bug on the [Chromium Issue Tracker](https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork%3ECertTrans)
in which they requested Log Inclusion.
Google will notify Log Operators, via announcements to the
[Chromium CT Policy Group](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy),
of changes to these requirements. Log Operators that fail to meet these
requirements will be in violation of the Log Inclusion Policy, which may
result in removal of the Log from the Chromium projects.
## Permissible Logging Rejection Criteria
Under certain circumstances, it is permissible for a Log to reject logging requests for certain classes of certificates. A logging rejection means that the Log will not incorporate a given certificate entry into the Merkle Tree even if the certificate chains to an Accepted Root Certificate. In accordance with this policy, rejected logging requests must not be issued an SCT by the Log.
If specified within the Log's Chromium Application, a Log may reject requests to log certificates that chain up to an Accepted Root Certificate based on one or more of the following bases:
* **Revocation Status**: If the Log determines that a certificate has been revoked by the issuing CA, it may reject the logging request. If the Log is unable to determine revocation status, it must accept the logging request and incorporate the entry into the Merkle Tree within the Log's MMD.
* **Certificate Expired**: If a logging request includes a certificate whose notAfter timestamp represents a point in time before the logging request is made, the Log may refuse to log the certificate entry.
* **Certificate Lifetime**: In order to control the growth of a Logs size, a Log Operator may specify a certificate expiry range for that Log, which must be included in the Logs Chromium Application in the form of two dates: [rangeBegin, rangeEnd). The certificate expiry range allows a Log to reject logging requests for certificates whose notAfter timestamp falls outside of this range, thus partitioning the set of publicly-trusted certificates that the Log will accept. In the spirit of operating Logs in the public interest, Log Operators who take advantage of this limitation are strongly encouraged to operate multiple Logs with staggered certificate expiry ranges to allow for logging of all currently valid publicly-trusted certificates.
The primary purpose of the permissible rejection criteria is to provide Log Operators with greater control over the growth and operation of a given Log instance while still performing the core functions of a trusted CT Log. Additionally, these criteria allow logs to be shielded from certain types of Denial of Service such as being spammed with the corpus of all expired certificates and being unable to respond to legitimate logging requests.
## Policy Violations
The Chromium developers include Logs at their sole discretion, to further
public auditability of Certificate Authorities. Upon learning of a Logs
potential violation of this Policy, the Chromium Authors will review the
information and may take corrective actions to preserve the integrity of its
Log program. The Chromium Authors may remove Logs at any time, and for any
reason.

125
site_operators.md Normal file
Просмотреть файл

@ -0,0 +1,125 @@
# Certificate Transparency for Site Operators
## Basics
We say that a certificate supports Certificate Transparency if it comes with
CT information that demonstrates it has been logged in several CT logs. This
CT information must comply with the
[Certificate Transparency in Chrome](https://github.com/chromium/ct-policy/blob/master/ct_policy.md)
policy. We sometimes refer to a site that "supports" CT as using a certificate
that is "CT qualified" or "disclosed via CT."
In general, a site operator does not need to take special action to
support Certificate Transparency. This is because RFC 6962 defines three ways
of providing the necessary information for CT: within the certificate, within
a stapled OCSP response, or directly by the TLS server. Nearly every CA
supports CT through the first method, meaning that when you get a certificate,
it will already support CT and require no further configuration. If you are
using a cloud provider to terminate your TLS connections, the cloud provider
may also support CT via TLS, requiring no further action on your part.
Supporting CT within the certificate itself is the preferred and recommended
way to enable CT support. If you obtain a certificate from your CA and it does
not support CT, then that generally indicates that your CA is not following
industry best practice, and you should probably look for another CA to provide
certificates for your sites.
Configuring support for CT via the TLS extension is not recommended for most
site operators. This is because supporting CT via this method requires
constant monitoring of the CT ecosystem, such as for changes in the list of
trusted logs or testing compatibility with various CT-supporting clients. This
method works well for organizations with the ability to dedicate resources to
that, such as hosting and cloud providers. If you are hosting your own website,
you should try to ensure that your certificates support CT, and avoid supporting
CT via the TLS extension. Supporting CT via the TLS extension may require rapid
changes to your configuration, and thus may be riskier for organizations
without staff dedicated to this.
If you are getting longer-lived certificates (for example, 1 year), it's
possible that changes in the CT ecosystem may mean that the CT information may
expire before the certificate expires. If your CA also supports delivering CT
via OCSP responses, then supporting OCSP stapling on your server may allow
fresh CT information to be provided without having to replace the certificate.
Alternatively, if your server does not support OCSP stapling, or your CA does
not support CT in their OCSP responses, you may need to replace your certificate.
These policies only apply to publicly-trusted CAs - that is, CAs that your
browser or device trust without any additional configuration. For organizations
using their own CAs, or for locally installed CAs, see
[Certificate Transparency for Enterprises](#Certificate-Transparency-For-Enterprises).
## Domain Privacy
Supporting CT by disclosing the certificate to a CT Log means that the full
contents of the certificate will be publicly accessible and viewable. In
particular, this means that the domains a certificate are for will be included
in the Certificate Transparency log, as well as the organization they are
affiliated with, if they are validated to a level higher than Domain
Validation or issued from an organization-specific CA.
For most certificates, this is no different than what is already available.
Publicly-trusted certificates have been subject to aggregation for public
analysis for some time, such as through products and tools such as
[Censys](https://censys.io/) or [scans.io](https://scans.io/). While
Certificate Transparency provides an interoperable protocol for exchanging
these datasets, in many cases, the certificate details and domains were already
publicly detectable.
Requiring that the full certificate be disclosed if it was issued by a
publicly-trusted CA is an important part of the security goals of Certificate
Transparency. Permitting some of the information to be hidden from
certificates allows for both attackers and untrustworthy CAs to hide
certificates that could be used to compromise users. Certificate Transparency
has detected issues at a large
[number of CAs](https://wiki.mozilla.org/CA/Incident_Dashboard), many that the
CAs themselves were not even aware of, and so public disclosure is critical
to keeping all users safe.
While proposals for hiding domain names were presented during the development
of Certificate Transparency, none of them were able to balance the needs of
site operators that did not need to hide their domains, those that did, and the
security risks that users would face.
Because of this, Chrome does not support any method for hiding domain names or
other information within publicly-trusted certificates, nor are there any plans
to support such mechanisms. Domain operators that wish to hide their
certificates, enabling security risks and attacks, have two options:
1. **Wildcard Certificates** - Wildcard certificates allow a single certificate
to be used for multiple hostnames, by putting a `*` as the most specific
DNS label (for example, `*.internal.example.com` is valid for
`mail.internal.example.com` and `wiki.internal.example.com`, but not for
`www.example.com` or `two.levels.internal.example.com`). Wildcard
certificates require greater care by the site operator to protect their
private key, but also can have their issuance controlled via technologies
such as [CAA (RFC 6844)](https://tools.ietf.org/html/rfc6844). This still
requires the certificate be disclosed, but can limit how much of the domain
is disclosed.
2. **Enterprise-specific configuration** - If the domains being accessed are
not intended to be used on the public internet, or not on machines or by
users that are not part of a single enterprise, then that enterprise can
use the options in the
[Certificate Transparency for Enterprises](#Certificate-Transparency-For-Enterprises).
This allows the enterprise to not reveal any information about the
certificate, but these certificates will **only** be trusted by their
members.
## What to do if your certificate does not work
As noted in [Chrome Policies](#Chrome-Policies), all certificates issued after
30 April 2018 are expected to be disclosed via Certificate Transparency in a
way that is compliant with the Certificate Transparency in Chrome policy.
Virtually all publicly-trusted CAs have committed to supporting CT for their
customers by default by this date, meaning that site operators should not have
to do anything special and can continue getting certificates that just work on
1 May 2018.
However, there's still a chance that a CA may not have adopted Certificate
Transparency, may have an infrastructure issue, or may not have communicated
to their partners, such as resellers or subordinate CAs, to ensure that the
transition would be as smooth as possible for their customers.
If you're receiving a `net::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED` error
message, the best thing to do is to contact your CA's support or sales team
to diagnose the error with them. They will most likely need to replace your
certificate with a new one that properly supports CT.