Upcoming Log Removal: Venafi CT Log Server

[Ryan Sleevi]

As part of our ongoing maintenance and monitoring of the Certificate Transparency logs included in Chrome, we have determined that the Venafi CT Log Server, https://ctlog.api.venafi.com/ct/v1, has presented two conflicting views of the Merkle Tree at different times. While this was caused due to issues stemming from the outage of a cloud provider, presenting a consistent view of the tree is a critical security requirement for CT logs.

Because of this, the current Venafi CT Log Server will no longer be a qualified log, effective 28 March 2017, with the last 'qualified' SCT having a timestamp no later than 1488307345708, or 2017-02-28T18:42:26+00:00 in ISO 8601 format. No SCT from the current Venafi CT Log Server - past, present or future - will count towards the requirement that at least one SCT is qualified at time of check and, as such, will not be appropriate for inclusion within the TLS extension or embedded within a stapled OCSP response. SCTs whose timestamp is less than or equal to 1488307345708 and are embedded within certificates will continue to count as once or currently qualified, but certificates with timestamps issued on-or-after that point will need to ensure that there are a sufficient number of SCTs from logs which are qualified or pending qualification at time of issuance.

We greatly appreciate Venafi's assistance in understanding the factors related to this, which have provided an unparalleled degree of transparency and set a new standard with respect to disclosure and information sharing that we hope all logs will emulate. By doing so, they have helped provide a number of useful insights into improving Chrome's policies and implementation, as well as improvements to the general Certificate Transparency ecosystem. We look forward to the possible future acceptance of Venafi's Gen2 CT Log Server, for which compliance monitoring is expected to be finished by 2017-05-07. Discussions on how to improve the handling of this will continue on ct-p...@chromium.org, and we welcome all feedback.

What does this mean for site operators

If you are delivering SCTs embedded in the certificate, this may require updating your certificate. This only applies to the set of certificates logged within the Venafi CT Log Server after 2017-02-28T18:42:26+00:00 and which, as a result of this, may no longer comply with the Certificate Transparency policy. If you are affected by this issue, your CA should be reaching out to you, but this currently affects less than 2,000 certificates. If you wish to check if you will be affected, you can look up your domain(s) or certificate(s) using https://crt.sh . If your certificate contains a "CT Precertificate SCTs" section that indicates it is from the "Venafi CT Log Server" with a timestamp on or after 2017-02-28T18:42:26+00:00 UTC, or an entry ID 90156 or later, you may be affected. If you refresh or renew your certificate, your CA should be including sufficient and diverse SCTs from other logs that it should require no action on your part.

A subsequent update will attempt to provide a full list of potentially-affected certificates.

If you are delivering SCTs embedded in the OCSP response, via OCSP stapling, then your CA must take appropriate action to update their OCSP pipeline to include at least one SCT from a non-Google operated log that is qualified at time of check. Once done, you must refresh the OCSP response stapled to the connection. Alternatively, you may also enable the TLS extension mechanism to deliver additional SCTs from non-Google operated logs, in order to ensure that at least one SCT from a non-Google log, qualified at time of check, is presented.

If you are delivering SCTs via a TLS extension, SCTs issued by the Venafi CT Log Server will not be considered qualified at the time of check. As such, you must begin to serve SCTs from a different, non-Google log by 28 May 2017, in order to satisfy the CT requirements.

What does this mean for CAs

If you are embedding SCTs in your OCSP response, you must issue new OCSP responses by 28 March 2017, which replace the Venafi CT Log Server SCTs with SCTs issued from another non-Google log. Your customers must then begin to serve this new response. Alternatively, your customers must include SCTs delivered via the TLS extension until you are able to update the SCTs included in your responses.

If you are embedding SCTs in your certificates, SCTs from the Venafi CT Log Server for certificates issued after 2017-02-28T18:42:26+00:00 will not count towards the minimum requirements, beginning 28 March 2017, either in the number of SCTs from logs once or currently qualified or as a non-Google log. You must provide SCTs from a diverse set of logs which are qualified at the time of issuance. SCTs from the Venafi CT Log Server will be ignored.

If you issued one or more certificates which would, as a result of this upcoming change, no longer comply with the Chrome Certificate Transparency Policy, you should consider contacting affected customers and updating/replacing certificates as necessary, to minimize any impact or disruption. 

[Kurt Roeckx]

On Tue, Mar 14, 2017 at 03:26:50PM -0400, Ryan Sleevi wrote:
> As part of our ongoing maintenance and monitoring of the Certificate
> Transparency logs included in Chrome, we have determined that the Venafi CT
> Log Server, https://ctlog.api.venafi.com/ct/v1, has presented two
> conflicting views of the Merkle Tree at different times. While this was
> caused due to issues stemming from the outage of a cloud provider,
> presenting a consistent view of the tree is a critical security requirement
> for CT logs.
>
> Because of this, the current Venafi CT Log Server will no longer be a
> qualified log, effective 28 March 2017, with the last 'qualified' SCT
> having a timestamp no later than 1488307345708, or
> 2017-02-28T18:42:26+00:00 in ISO 8601 format.

Should that be February?


Kurt

[Kurt Roeckx]

I guess you mean that from 2017-03-28, only those up to 2017-02-28
are being accepted, and that everybody has until 2017-03-28 to
replace the certificates if needed.


Kurt

[Ryan Sleevi]

Could you clarify what you mean?

I suspect this might be confusion relating to two weeks from now is 28 March - which is when this change will land across Chrome versions - and which will apply to SCTs issued after 28 February. Does that help? 

[Ryan Sleevi]

On Tue, Mar 14, 2017 at 3:26 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

If you are delivering SCTs via a TLS extension, SCTs issued by the Venafi CT Log Server will not be considered qualified at the time of check. As such, you must begin to serve SCTs from a different, non-Google log by 28 May 2017, in order to satisfy the CT requirements.

Correction, and deeply sorry for the typo here - this is 28 March 2017, consistent with the rest of the message. I may have to march myself to another proofreader. 

[Ryan Sleevi]

On Tue, Mar 14, 2017 at 3:26 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

If your certificate contains a "CT Precertificate SCTs" section that indicates it is from the "Venafi CT Log Server" with a timestamp on or after 2017-02-28T18:42:26+00:00 UTC, or an entry ID 90156 or later, you may be affected. 

It was pointed out the tree size is 90155 entries, but because of CT's 0-based indexing, the last 'good' entry ID is 90154, and entries 90155 or later are affected.