Let me know if there's anything else I need to include. Thanks!

Hi Jeremy - The log public keys (in DER) do not appear to be attached to this bug.

Application looks good; we're going to track all 5 temporally sharded logs in this bug. Over to CT team for monitoring progress.

Thank you for your request, we have started monitoring your log server.
Should no issues be detected, the initial compliance monitoring phase
will be complete on Apr 29 2018 and we will update this bug shortly 
after that date to confirm.

I would like to amend the previous comment.  As we have been compliance monitoring the Yeti Logs since the beginning of the year, and the delay between the go ahead on Jan 5th and the official monitoring period beginning was simply me not noticing that update until today, we have discussed it and decided that the start date of the official monitoring period for the Yeti Logs should be Jan 6th 2018.

This means that the initial compliance monitoring phase will actually be complete on Apr 6 2018 and we will update this bug shortly after that date to confirm.

We are adding the 'DigiCert Trusted Root G4' root to our CT server.

-----BEGIN CERTIFICATE-----
MIIFkDCCA3igAwIBAgIQBZsbV56OITLiOQe9p3d1XDANBgkqhkiG9w0BAQwFADBi
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBUcnVzdGVkIFJvb3Qg
RzQwHhcNMTMwODAxMTIwMDAwWhcNMzgwMTE1MTIwMDAwWjBiMQswCQYDVQQGEwJV
UzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu
Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBUcnVzdGVkIFJvb3QgRzQwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQC/5pBzaN675F1KPDAiMGkz7MKnJS7JIT3y
ithZwuEppz1Yq3aaza57G4QNxDAf8xukOBbrVsaXbR2rsnnyyhHS5F/WBTxSD1If
xp4VpX6+n6lXFllVcq9ok3DCsrp1mWpzMpTREEQQLt+C8weE5nQ7bXHiLQwb7iDV
ySAdYyktzuxeTsiT+CFhmzTrBcZe7FsavOvJz82sNEBfsXpm7nfISKhmV1efVFiO
DCu3T6cw2Vbuyntd463JT17lNecxy9qTXtyOj4DatpGYQJB5w3jHtrHEtWoYOAMQ
jdjUN6QuBX2I9YI+EJFwq1WCQTLX2wRzKm6RAXwhTNS8rhsDdV14Ztk6MUSaM0C/
CNdaSaTC5qmgZ92kJ7yhTzm1EVgX9yRcRo9k98FpiHaYdj1ZXUJ2h4mXaXpI8OCi
EhtmmnTK3kse5w5jrubU75KSOp493ADkRSWJtppEGSt+wJS00mFt6zPZxd9LBADM
fRyVw4/3IbKyEbe7f/LVjHAsQWCqsWMYRJUadmJ+9oCw++hkpjPRiQfhvbfmQ6QY
uKZ3AeEPlAwhHbJUKSWJbOUOUlFHdL4mrLZBdd56rF+NP8m800ERElvlEFDrMcXK
chYiCd98THU/Y+whX8QgUWtvsauGi0/C1kVfnSD8oR7FwI+isX4KJpn15GkvmB0t
9dmpsh3lGwIDAQABo0IwQDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIB
hjAdBgNVHQ4EFgQU7NfjgtJxXWRM3y5nP+e6mK4cD08wDQYJKoZIhvcNAQEMBQAD
ggIBALth2X2pbL4XxJEbw6GiAI3jZGgPVs93rnD5/ZpKmbnJeFwMDF/k5hQpVgs2
SV1EY+CtnJYYZhsjDT156W1r1lT40jzBQ0CuHVD1UvyQO7uYmWlrx8GnqGikJ9yd
+SeuMIW59mdNOj6PWTkiU0TryF0Dyu1Qen1iIQqAyHNm0aAFYF/opbSnr6j3bTWc
fFqK1qI4mfN4i/RN0iAL3gTujJtHgXINwBQy7zBZLq7gcfJW5GqXb5JQbZaNaHqa
sjYUegbyJLkJEVDXCLG4iXqEI2FCKeWjzaIgQdfRnGTZ6iahixTXTBmyUEFxPT9N
cCOGDErcgdLMMpSEDQgJlxxPwO5rIHQw0uA5NBCFIRUBCOhVMt5xSdkoF1BN5r5N
0XWs0Mr7QbhDparTwwVETyw2m+L64kW4I1NsBm9nVX9GtUw/bihaeSbSpKhil9Ie
4u1Ki7wb/UdKDd9nZn6yW0HQO+T0O/QEY+nvwlQAUaCKKsnOeMzV6ocEGLPOr0mI
r/OSmbaz5mEP0oUA51Aa5BuVnRmhuZyxm7EAHu/QD09CbMkKvO5D+jpxpchNJqU1
/YldvIViHTLSoCtU7ZpXwdv6EM8Zt4tKG48BtieVU+i2iW1bvGjUI+iLUaJW+fCm
gKDWHrO8Dw9TdSmq6hN35N6MgSGtBxBHEa2HPQfRdbzP82Z+
-----END CERTIFICATE-----

These Logs have passed the initial 90 day compliance period and we will start
the process to add them to Chrome.

For the last ~18 hours, my monitor has received a 500 Internal Server error on all requests to the 2018 shard's get-entries endpoint. The most recent STH it has been able to verify is dated 2018-04-30 14:00:57.573 UTC, which is more than 24 hours ago. The other shards' get-entries endpoints also appear to be down, but I haven't looked to see if they have blown their MMDs as well.

Cert Spotter has also been unable to retrieve recent entries from Yeti 2018.  The most recent STH it has been able to verify is timestamped Mon Apr 30 05:00:32 UTC 2018.

The most recent STH Graham Edgecombe has been able to verify is 2018-04-30 08:00:42 UTC (https://ct.grahamedgecombe.com/logs/56) and his monitor has marked Yeti 2018 as "Bad" (https://ct.grahamedgecombe.com/)

After taking a preliminary glance at what Google's compliance monitor has seen (which I will follow up on in more detail), our monitor has not had any problems getting or verifying recent STHs from Yeti2018.  For the non-2018 Logs, we have seen sporadic get-entries errors, but we have eventually been able to get the necessary entries for merge delay checking.  However, we have been unable to add any certificates to Yeti2018 at all today (UTC), making us unable to do merge delay checks, so it would seem that something may be up with that shard.

I will investigate further tomorrow, and report back with more in-depth and properly verified findings on our end.  We do also have tooling that ingests entries from Logs, so we will check that to see if we are seeing the same issues with get-entries from the point of view of that tool.

Out of interest, you mention the most recent STH you have been able to *verify*... have you received more recent STHs that you have been unable to verify, or are all the STHs you've received verifiable?  Also, what do you mean by verify?  Are we talking just checking the signature verifies, or building the Log (thus relying on get-entries) and checking the hash matches too?

We're looking into it as well. All I know for now is that it was deployed
to AWS. AWS had some i/o issues that caused the cert to be down. The report
I received internally was that we were down for 4 hours so I'm not sure why
it was reported as down for more than 24. I'll get back to you when I know
more info.

For Cert Spotter, verifying an STH means that it has been able to use get-entries to build a tree with a root hash that matches the STH.  I have received more recent STHs with authentic signatures whose root hashes I have not been able to verify.

Does Google's compliance monitor use get-entries to verify an STH's root hash, or does it use consistency proofs?

The current compliance monitor doesn't use get-entries, but the other tooling I mentioned we have that ingests the entries from Logs does verify STHs in the way you mention - by building the tree.  We'll take a look tomorrow at what has been seen by that tool, to see if we have seen the same things as you :)

To be clear - the current compliance monitor doesn't use get-entries *to verify STHS* - it does use get-entries to check merge delays.

Our I/O on two of our three database nodes went down, which basically
destroyed the queries into the system as we couldn't get quorum. Because
quorum couldn't be verified, some people (most?) saw query timeouts.  One
of our alerts did not trigger properly so we missed the first alarm.
However, i think the downtime was closer to 4 hours. We are digging into
the logs and will give you more info once we find out when the I/O issue
started happening. There shouldn't have been any inconsistent tree heads
signed though.

We fixed it by updating the server types on AWS. Not sure why this fixed
it, but it apparently did.

Yeti2018's get-entries endpoint is now working. My monitor was able to verify all the STHs it retrieved during the outage.

By "verify" I mean not only retrieving and verifying the signature on the STH but also retrieving the entries and checking that the hashes match. My monitor was never unable to fetch a STH.

I believe this constitutes a blown MMD because DigiCert's logs impose a 12-hour delay between submission and inclusion, so a certificate that was submitted to Yeti2018 12 hours before the most recent verified STH during the outage (i.e., 2018-04-30 02:00:57 UTC) would not have been available at the get-entries endpoint until the outage ended a couple hours ago - the last failure my monitor saw was at 2018-05-01 19:13:42 UTC. That's a span of more than 24 hours.

I don't think this is accurate. The MMD is a promise to incorporate the
cert in a log by a certain time, not that the signed head will be available
to any particular monitoring service. However, I can't say for sure that we
produced a new STH within the 24 hours. We're looking into it to see
whether the STH simply wasn't available or never got signed.  If the STH
did get signed and simply didn't respond to the query, then the MMD wasn't
really missed, there was "just" significant down-time. Whether the STH did
exist should be fairly easy to prove once we can pull the logs.

My monitor did not see downtime on the get-sth endpoint, and never received a STH that was more than 24 hours old. 

RFC6962, section 7.1 states in part: "Misissued certificates that do have an SCT from a log will appear in that public log within the Maximum Merge Delay, assuming the log is operating correctly.  Thus, the maximum period of time during which a misissued certificate can be used without being available for audit is the MMD."

All I'm saying was that I believe there were certificates submitted to Yeti2018 that weren't available for audit within 24 hours of their submission. In my opinion this violates the spirit of a maximum merge delay.

I don't think it violates the spirit of the MMD.

Section 3 of 6962: "The SCT is the log's promise to incorporate the
certificate in the Merkle Tree within a fixed amount of time known as the
Maximum Merge Delay (MMD)."

Section 7.3 specifies exacatly when a log is bad: "by failing to
incorporate a  certificate with an SCT in the Merkle Tree within the MMD".
If the SCT existed, even if some audit systems couldn't reach it, then the
MMD was met and the log wasn't mis-behaving.

A failure to meet availability expectations is a separate issue - one that
touches browser policy concerns rather than log misbehavior.

Unfortunately our tool that gets entries from Logs had not been configured to ingest from the Yeti Logs, so we are unable to confirm/deny the get-entries downtime for Yeti2018.

What I can confirm is the following:
- We successfully retrieved STHs from Yeti2018 all of 2018/05/01 (YYYY/MM/DD).  Usually the STHs we receive from Digicert Logs contain a timestamp of ~12hrs before the time we receive them.  Interestingly, at around 10am (UTC) on 2018/05/01 the STHs suddenly became exceedingly fresh - the first fresh one we recieved at 2018/05/01 10:03 has a timestamp for 2018/05/01 10:01.  The freshness of STHs then gradually decreased over the next 9 hours, until they were back to being ~12hrs old.  In the interest of transparency, I'd be interested to know if there was anything that happened on the Digicert end at 10am (UTC) that would explain this?  There's nothing wrong with it of course, it was just an interesting find.
- Between 2018/05/01 10:17 (UTC) and 2018/05/01 20:18 (UTC) we were unable to submit certificates to Yeti2018.

Hi Kat, I'm currently working on the post-mortem right now and will send it to the CT policy group soon. The faster refresh of STHs is due to the architecture of the logs and them trying to always keep 12 STHs signed and ready to be delivered. When one takes longer than an hour to sign due to an issue, the others will be signed faster to get back to 12.  I'll include more of those details in the post-mortem, along with details on the success and failure rates of the API calls during the outage. We did have a new submission requests succeed all throughout the outage on all the Yeti logs, albeit at a much lower rate due to the database issue.

The post-mortem has been posted to the CT policy group here https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/EKB9ycLsMk0

A small correction to my last message - all the times stated there were UTC+01:00.  Apologies for this, this was a by-product of living in a city where it is UTC for half of the year, and forgetting that we've now changed to BST :)

This means that what we observed on the STH front matches what was reported in Rick's post-mortem.

The NextAction date has arrived: 2018-05-04

As we've posted to the thread mentioned in Comment 26, we do not consider the incident noted in the post-mortem to be a disqualifying event.

With that, Yeti is ready to be added to Chrome's trusted log list, but there are currently too many CT Logs operated by DigiCert. Per discussion on ct-policy, Log Operators are being limited to 3 separate Logs or Shard Groups.

Can you provide feedback on which Logs should be removed to add Yeti and Nessie? Additionally, we will need to specify a disqualified_at date in the near future and will disqualify them after they've stopped issuing new SCTs.

Currently qualified:
DigiCert Log Server (ct1.digicert-ct.com/log/)
DigiCert Log Server 2 (ct2.digicert-ct.com/log/)
Symantec Log (ct.ws.symantec.com/)
Symantec Vega Log (vega.ws.symantec.com/)
Symantec Sirius Log (sirius.ws.symantec.com/)

Pending qualification:
DigiCert Yeti 20XX group
DigiCert Nessie 20XX group

You can disqualify the following:

Symantec Log (ct.ws.symantec.com/)
Symantec Vega Log (vega.ws.symantec.com/)
Symantec Sirius Log (sirius.ws.symantec.com/)

We announced that the logs would be discontinued both here and on the Mozilla forum. We also checked and all certs visible in these logs appear in a mirror Google log.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4508ef53b34e90e445e60dda8fd45f50e89d84dc

commit 4508ef53b34e90e445e60dda8fd45f50e89d84dc
Author: Devon O'Brien <asymmetric@chromium.org>
Date: Thu May 17 23:41:09 2018

Add DigiCert Yeti to Trusted CT Logs

The following CT Logs have passed their monitoring period an are being
added as trusted Logs in Chrome:

DigiCert Yeti2018, Yeti2019, Yeti2020, Yeti2021, Yeti2022

R=rsleevi@chromium.org

Bug:  796333 
Change-Id: I83f7238ed90f2e370c7cf1fe196b6f48862f7d10
Reviewed-on: https://chromium-review.googlesource.com/1058686
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559734}
[modify] https://crrev.com/4508ef53b34e90e445e60dda8fd45f50e89d84dc/components/certificate_transparency/data/log_list.json

The NextAction date has arrived: 2018-05-21

Requesting merge to M67. Data only change (which I just double checked in source) and I've also verified correct CT functioning in 68.0.3436.0, and UMA metrics look as expected.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M67 branch 3396 based on comment #35. Please merge ASAP so we can take it in for this week last M67 Beta release on Wednesday. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cdf0c4e95b6db65b4bcbfbee79cc3d2faf3b448a

commit cdf0c4e95b6db65b4bcbfbee79cc3d2faf3b448a
Author: Andrew R. Whalley <awhalley@chromium.org>
Date: Mon May 21 17:52:38 2018

Add DigiCert Yeti to Trusted CT Logs

[67 merge] The following CT Logs have passed their monitoring period an are being
added as trusted Logs in Chrome:

DigiCert Yeti2018, Yeti2019, Yeti2020, Yeti2021, Yeti2022

R=rsleevi@chromium.org
TBR=asymmetric@chromium.org

(cherry picked from commit 4508ef53b34e90e445e60dda8fd45f50e89d84dc)

Bug:  796333 
Change-Id: I83f7238ed90f2e370c7cf1fe196b6f48862f7d10
Reviewed-on: https://chromium-review.googlesource.com/1058686
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#559734}
Reviewed-on: https://chromium-review.googlesource.com/1067509
Reviewed-by: Andrew Whalley <awhalley@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#663}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/cdf0c4e95b6db65b4bcbfbee79cc3d2faf3b448a/net/data/ssl/certificate_transparency/log_list.json

Thank you for getting this merged into Chrome so quickly as this allows these logs to be used for non-EV certs right away.

We are adding the 'SSL.com EV Root Certification Authority RSA R2' root to all Yeti logs.

-----BEGIN CERTIFICATE-----
MIIF6zCCA9OgAwIBAgIIVrYpzTS8ePYwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNV
BAYTAlVTMQ4wDAYDVQQIDAVUZXhhczEQMA4GA1UEBwwHSG91c3RvbjEYMBYGA1UE
CgwPU1NMIENvcnBvcmF0aW9uMTcwNQYDVQQDDC5TU0wuY29tIEVWIFJvb3QgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkgUlNBIFIyMB4XDTE3MDUzMTE4MTQzN1oXDTQy
MDUzMDE4MTQzN1owgYIxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIDAVUZXhhczEQMA4G
A1UEBwwHSG91c3RvbjEYMBYGA1UECgwPU1NMIENvcnBvcmF0aW9uMTcwNQYDVQQD
DC5TU0wuY29tIEVWIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUlNBIFIy
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAjzZlQOHWTcDXtOlG2mvq
M0fNTPl9fb69LT3w23jhhqXZuglXaO1XPqDQCEGD5yhBJB/jchXQARr7XnAjssuf
OePPxU7Gkm0mxnu7s9onnQqG6YE3Bf7wcXHswxzpY6IXFJ3vG2fThVUCAtZJycxa
4bH3bzKfydQ7iEGonL3Lq9ttewkfokxykNorCPzPPFTOZw+oz12WGQvE43LrrdF9
HSfvkusQv1vrO6/PgN3B0pYEW3p+pKk8OHakYo6gOV7qd89dAFmPZiw+B6KjBSYR
aZfqhbcPlgtLyEDhULouisv3D5oi53+aNxPN8k0TayHRwMwi8qFG9kRpnMphNQcA
b9ZhCBHqurj26bNg5U257J8UZslXWNvNh2n4ioYSA0e/ZhN2rHd9NCSFg83XqpyQ
Gp8hLH94t2S42Oim9HizVcuE0jLEeK6jj2HdzghTreyI/BXkmg3mnxp3zkyPuBQV
PWKchjgGAGYS5Fl2WlPAApiiECtoRHuOec4zSnaqW4EWG7WK2NAAe15itAnWhmMO
pgWVSbooi4iTsjQc2KRVbrcc0N6ZVTsj9CLg+SlmJuwgUHfbSguPvuUCYHBBXtSu
UDkiFCbLsjtzdFVHB3mBOagwE0TlBIqulhMlQg+5U8Sb/M3kHN48+qvWBkofZ6aY
MBzdLNvcGJVXZsb/XItW9XcCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAfBgNV
HSMEGDAWgBT5YLvU49U09rj1BoAlp3PbRmmonjAdBgNVHQ4EFgQU+WC71OPVNPa4
9QaAJadz20ZpqJ4wDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4ICAQBW
s47LCp1Jjr+kxJG7ZhcFUZh1++VQLHqe8RT6q9OKPv+RKY9ji9i0qVQBDb6Thi/5
Sm3HXvVX+cpVHBK+Rw82xd9qt9t1wkclf7nxY/hoLVUE0fKNsKTPvDxeH3jnpaAg
cLAExbf3cqfeIg29MyVGjGSSJuM+LmOW2puMPfgYCdcDzH2GguDKBAdRUNf/ktUM
79qGn5nX67evaOI5JpS6aLe/g9Pqemc9YmeuJeVy6OLk7K4S9ksrPJ/psEDzOFSz
/bdoyNrGj1E8svuR3Bznm53htw1yj+KkxKl4+esUrMZDBcJlOSgYAsOCsp0FvmXt
ll9ldDz7CTUue5wT/RsPXcdtgTpWD8w74a8CLyKsRspGPKAcTNZEtF4uXBVmCeEm
Kf7GUmG6sXP/wwyc5WxqlD8UykAWlYTzWamsX0xhk23RO8yilQwipmdnRC652dKK
QbNmC1r7fSOl8hqw/96bg5Qu0T/fkreRrwU7ZcegbLHNYhLDkBvjJc40vG93drEQ
w/cFGsDWr3RiSBd3kmmQYRzelYB0VI8YHMPzA9C/pEN1hlMYegouCRw2n5H9gooi
S9EOUCXdywMMF8mDAAhONU2Ki+3wApRmLER/y5UnlhetCTCstnEXbosX9hwJ1C07
mKVx01QT2WDz9UtmT/rx7iASjbSsV7FFY6GsdqnC+w==
-----END CERTIFICATE-----

We are adding the 'Atos TrustedRoot 2011' root to all the Yeti logs.

-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIIXDPLYixfszIwDQYJKoZIhvcNAQELBQAwPDEeMBwGA1UE
AwwVQXRvcyBUcnVzdGVkUm9vdCAyMDExMQ0wCwYDVQQKDARBdG9zMQswCQYDVQQG
EwJERTAeFw0xMTA3MDcxNDU4MzBaFw0zMDEyMzEyMzU5NTlaMDwxHjAcBgNVBAMM
FUF0b3MgVHJ1c3RlZFJvb3QgMjAxMTENMAsGA1UECgwEQXRvczELMAkGA1UEBhMC
REUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVhTuXbyo7LjvPpvMp
Nb7PGKw+qtn4TaA+Gke5vJrf8v7MPkfoepbCJI419KkM/IL9bcFyYie96mvr54rM
VD6QUM+A1JX76LWC1BTFtqlVJVfbsVD2sGBkWXppzwO3bw2+yj5vdHLqqjAqc2K+
SZFhyBH+DgMq92og3AIVDV4VavzjgsG1xZ1kCWyjWZgHJ8cblithdHFsQ/H3NYkQ
4J7sVaE3IqKHBAUsR320HLliKWYoyrfhk/WklAOZuXCFteZI6o1Q/NnezG8HDt0L
cp2AMBYHlT8oDv3FdU9T1nSatCQujgKRz3bFmx5VdJx4IbHwLfELn8LVlhgf8FQi
eowHAgMBAAGjfTB7MB0GA1UdDgQWBBSnpQaxLKYJYO7Rl+lwrrw7GWzbITAPBgNV
HRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFKelBrEspglg7tGX6XCuvDsZbNshMBgG
A1UdIAQRMA8wDQYLKwYBBAGwLQMEAQEwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3
DQEBCwUAA4IBAQAmdzTblEiGKkGdLD4GkGDEjKwLVLgfuXvTBznk+j57sj1O7Z8j
vZfza1zv7v1Apt+hk6EKhqzvINB5Ab149xnYJDE0BAGmuhWawyfc2E8PzBhj/5kP
DpFrdRbhIfzYJsdHt6bPWHJxfrrhTZVHO8mvbaG0weyJ9rQPOLXiZNwlz6bb65pc
maHFCN795trV1lpFDMS3wrUU77QR/w4VtfX128a961qn8FYiqTxlVMYVqL2Gns2D
lmh6cYGJ4Qvh6hEbaAjMaZ7snkGeRDImeuKHCnE96+RapNLbxc3G3mB/ufNPRJLv
KrcYPqcZ2Qt9sTdBQrC6YB3y/gkRsPCHe6ed
-----END CERTIFICATE-----

Yeti2023 inclusion request:

We are adding the next partition to the Yeti logs to ensure they are usable by the time a certificate can expire within the range.

Contact info will be:
Email: ctops@digicert.com
Phone: 801-633-8482
Authorized persons: Jeremy Rowley, Rick Roos, Dan Timpson, Wade Choules (all of us are on the ctops email alias)

Log URL: https://yeti2023.ct.digicert.com/log
Certificate Expiry Range: Jan 01 2023 00:00:00Z inclusive to Jan 01 2024 00:00:00Z exclusive
MMD: 24 hours
Accepted roots: The same roots as for the existing Yeti Logs
Server public key: file attached (yeti_2023_public_key.der)

Deleted: yeti_2023_public_key.der 91 bytes

yeti_2023_public_key.der 91 bytes Download