Certificate Transparency policy

Site certificates are issued by dedicated certification authorities (CAs). Using the internet implies complete trust in their integrity. The Certificate Transparency standard (CT) provides an additional layer of security by identifying certificates that were issued by mistake or for fraudulent purposes.

What is Certificate Transparency for?

When checking site certificates, browsers are guided by the trust in the certification authorities that issued them. However, CAs may sometimes issue a certificate to a domain without the owner's permission: for example, for testing purposes. If an attacker gets access to such a certificate along with the associated private key, they can carry out a man-in-the-middle attack. This is because, from the browser's perspective, the certificate is perfectly valid.

The Certificate Transparency standard was developed as a solution to this problem. Information about all issued certificates is recorded in special Certificate Transparency logs. Monitoring these logs allows us to track all the certificates issued to a domain and ensures that we don't overlook those issued by mistake.

What are CT logs?

These are special logs that record information about issued certificates. CT logs must allow the appending of new entries and forbid the deletion and editing of the existing ones. This is enabled by hash structures known as Merkle trees.

CT logs are public, which allows:

Users and browsers to track the issuance and verify the authenticity of all domain certificates.
Site owners to detect unauthorized issuance of certificates.

When registering a certificate in the CT log, the certification authority receives a Signed Certificate Timestamp (SCT). The certification authority then sends the certificate along with the timestamp to the site owner. When a browser connects to the site, the server must provide the certificate and a timestamp from one or, preferably, several logs.

What certificates does Yandex Browser trust?

Yandex Browser currently trusts certificates with a timestamp from the Yandex CT log (described at the beginning of the list of trusted National Certification Authority CT logs). Soon, Yandex Browser will only trust certificates containing a timestamp from any CT log in the trusted list along with a timestamp from the Yandex CT log.

With respect to CT logs issued by other certification authorities, Yandex Browser adheres to the Google policy.

CT log requirements

A CT log owner must:

Meet all the requirements of the RFC 6962 standard, including the implementation of the API endpoints defined in Section 4.
Maintain a log availability of 99% or higher, without log downtime periods exceeding the maximum merge delay (MMD) specified during registration. The log availability is calculated based on Yandex data, not by the log owner.
Avoid failures that exceed the MMD by more than 24 hours. This requirement concerns network failures, expiration of the log's SSL certificate, denied certificate registration requests, HTTP response status codes other than 200, and responses that don't comply with the RFC 6962 requirements.
Not restrict the extraction or shared use of log data.
Keep the log append-only.
Transmit a consistent representation of the Merkle tree for all queries and at all times.
The representations of the Merkle tree that the owner transmits to different parties and at different times must be identical.
Update the log with certificates with an issued timestamp within a period not exceeding the MMD.
Upon receiving a request to register a certificate that is already included in the log, either return the previously issued SCT to the site owner or add a new certificate entry within the MMD, allowing the new SCT to be verified via the API described in RFC 6962.
Notify the Yandex team by email of any changes to the data specified in the request for the log's inclusion in the trusted list.

Violation of these requirements may lead to the removal of the CT log from the trusted list. Yandex Browser won't trust the timestamps issued for this log. The certificates included in the log will remain trusted only if they contain timestamps from other logs.

Add a CT log to the trusted list

Send a request to the Yandex team by email. The request must contain the following information:
- An email address that you regularly check.
- Full names of the representatives who will be interacting with the Yandex Browser team.
Note

By submitting an application, you confirm that your organization is independent from other CT log owners. If your log ceases to be independent, notify the Yandex Browser team by email as soon as possible.
After verifying the contact information, the Yandex Browser team will request the following information about the CT log:
- The public address of your CT log, which must respond to all client requests specified in RFC 6962, Section 4.
- Public keys for the log, provided in the form of a DER-encoded binary file representing the ASN.1 SubjectPublicKeyInfo structure.
- A description of the log, including the applied policies and the log's certificate requirements.
- Maximum merge delay (MMD).
- A set of trusted root certificates.
- The validity period of the log in the [start date, end date] format.
- The validity periods of sharded logs (listed consecutively without spaces). The validity period of each log must be between 6 and 12 months.
- Whether the log will reject expired and revoked certificates.

Policy for adding a certificate to the CT log

Accepted root certificates.
We expect your CT log to include the certificates from the CAs that Yandex Browser trusts by default across all supported platforms, including Windows, macOS, Linux, Android, and iOS.

In addition, your log must accept the certificates issued by the Yandex Merge Delay Monitor Root to verify the log's compliance with this policy.
Rejection of certificates.
Under certain conditions, you may choose not to include a certificate in the CT log. For example, if the certificate has expired or has already been revoked at the time of the request. Rejection of a certificate means that its entry won't be included in the Merkle tree, even if the certificate is linked to a trusted root certificate. A certificate that is rejected by the CT log isn't issued an SCT.
- Certificate has been revoked. If the CT log determines that the certificate has been revoked by the certification authority, it may reject it. If the log can't determine whether the certificate has been revoked, it must include an entry for the certificate in the Merkle tree within the MMD.
- Certificate has expired. If the certificate's notAfter property contains a date that is earlier than the date of the request, the CT log may reject the certificate. Even outdated CT logs that don't set certificate expiration ranges may apply this criterion.
Temporal sharding.
To ensure flexibility and manage the growth of CT logs, newer CT logs are split by certificate expiration ranges, which are expressed in the [start date, end date] format. This allows the CT log to reject certificates with expiration dates outside the specified range, sharding the set of public certificates accepted by each log.

To do this:
- The certificate expiration ranges for the CT log must be no less than six months and no more than one calendar year.
- The CT log must reject certificates with notAfter values outside the expiration range.
- The CT log shards must cover the period from the present to 3–4 years into the future. Many prefer to set yearly ranges, such as Log2020, Log2021, Log2022, and Log2023.
When the end of a CT log shard's range is reached, the shard is removed from the list. Upon deletion, the log owner must create a new CT log, extending the range. For example, if Log2020 is deleted at the beginning of 2021, you need to apply for the inclusion of Log2024 in the list.
Policy violations.
The Yandex team reviews CT logs for compliance at its discretion. Any CT logs that violate this Policy may be removed from the Yandex trusted list at any time.

<,span,class="button",>Contact support