Digicert and Sectigo logs unavailable for me with certspotter logtailing due to rate-limits/blocking (429)

[Tobias Fiebig]

Moin,

I am running certspotter [1] to monitor CT logs for domains I operate,
just using the certspotter binary to tail the logs (keeping progress
state locally to not have to re-crawl logs again after a restart).

I recently noticed that the software started to crash more often.
Consulting the logs, it seems like it is unable to successfully
retrieve several digicert.com and sectigo.com logs for me due to my
certificate tailing machine having been blocked (receiving a 429 Too
Many Requests).

For, e.g., tiger2025h2.ct.sectigo.com, i can trigger a persistent 429
with just three(!) subsequent manual requests from a fresh IP
previously not used to query the site. Persistent means that a single
request more than 10 minutes later immediately leads to a 429.

For the digicert logs, I was not able to trigger a rate limit manually;
I hence assume that there is some more elaborate rate limit that kicks
in just from tailing the log with certspotter.

As this, effectively, makes these logs unavailable for me, I wanted to
ask whether there is any advice on how to deal with this without having
to rely on a third party for certificate log tailing, missing parts of
the log, or being blocked by CT logs for just using a standard tool for
following CT logs.

Are there any publicly available documents on the set rate limits for
these two logs?

With best regards,
Tobias

[1] https://github.com/SSLMate/certspotter

--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl
Pronouns: he/him/his

[Andrew Ayer]

Hi Tobias,

On Fri, 13 Jun 2025 11:03:57 +0200
"'Tobias Fiebig' via Certificate Transparency Policy"

<ct-p...@chromium.org> wrote:

> I am running certspotter [1] to monitor CT logs for domains I operate,
> just using the certspotter binary to tail the logs (keeping progress
> state locally to not have to re-crawl logs again after a restart).
>
> I recently noticed that the software started to crash more often.
> Consulting the logs, it seems like it is unable to successfully
> retrieve several digicert.com and sectigo.com logs for me due to my
> certificate tailing machine having been blocked (receiving a 429 Too
> Many Requests).

Thanks for raising this. First off, I want to make sure you're using the latest version of certspotter (0.19.1) and not, e.g. the version in Debian Stable, since it introduces parallel downloading, which is needed to successfully monitor the DigiCert logs.

That said, multiple people have recently reported being unable to keep up with the Sectigo logs even with the latest version of certspotter <https://github.com/SSLMate/certspotter/issues/34#issuecomment-2957788163>, and all the information so far points to the rate limits being too strict.

Also, certspotter should not crash or terminate due to log errors, so if that's happening with the latest version, please file an issue about it at <https://github.com/SSLMate/certspotter/issues>.

Regards,
Andrew

[Tobias Fiebig]

Hello Andrew,

> Thanks for raising this.  First off, I want to make sure you're using
> the latest version of certspotter (0.19.1) and not, e.g. the version
> in Debian Stable, since it introduces parallel downloading, which is
> needed to successfully monitor the DigiCert logs.

I am following main for certspotter; Currently I am on:
# /opt/certspotter/repo/cmd/certspotter/certspotter -version
certspotter version v0.19.2-0.20250519174704-61b037a7081d

> That said, multiple people have recently reported being unable to
> keep up with the Sectigo logs even with the latest version of
> certspotter
> <https://github.com/SSLMate/certspotter/issues/34#issuecomment-
> 2957788163>, and all the information so far points to the rate limits
> being too strict.

Thanks, so this seems to not be me alone. As I said: Three manual
requests in succession are enough for blocking; Just now it triggered
on the second (but the block had been lifted for my workstation since
my first message). I guess, though, that that is then a discussion that
needs to be had with sectigo.

Would it make sense if i setup a quick measurement to get the exact
rate limits they have set?

> Also, certspotter should not crash or terminate due to log errors, so
> if that's happening with the latest version, please file an issue
> about it at <https://github.com/SSLMate/certspotter/issues>.

Let me first figure out enough information to make this a fileable bug;
It is running on OpenBSD 7.7; So far it crashed three times since 2025-
06-10T00:39:52+00:00, second and third time today, no logs; i updated
to the current version on 2026-06-01. So I am not yet entirely
convinced that this is a certspotter issue, and not something else in
the environment being funny.

I see that my monitoring noted new commits ~1h ago for 0.20.0; What is
your recommendation/would be more useful in your opinion? Roll out
0.20.0 and see what happens, or keep on the current version to have
less to bisect?

With best regards,
Tobias

[Andrew Ayer]

Hi Tobias,

On Fri, 13 Jun 2025 20:01:02 +0200

"'Tobias Fiebig' via Certificate Transparency Policy"
<ct-p...@chromium.org> wrote:

> Hello Andrew,
> > Thanks for raising this.__ First off, I want to make sure you're

> > using the latest version of certspotter (0.19.1) and not, e.g. the
> > version in Debian Stable, since it introduces parallel downloading,
> > which is needed to successfully monitor the DigiCert logs.
>
> I am following main for certspotter; Currently I am on:
> # /opt/certspotter/repo/cmd/certspotter/certspotter -version
> certspotter version v0.19.2-0.20250519174704-61b037a7081d

Good. Just to confirm - are you actually getting health check failures about backlogs with the DigiCert and Sectigo logs? Just because you see HTTP errors on stderr doesn't mean certspotter isn't keeping up with the log.

> > That said, multiple people have recently reported being unable to
> > keep up with the Sectigo logs even with the latest version of
> > certspotter
> > <https://github.com/SSLMate/certspotter/issues/34#issuecomment-
> > 2957788163>, and all the information so far points to the rate

> > 2957788163>limits

> > being too strict.
>
> Thanks, so this seems to not be me alone. As I said: Three manual
> requests in succession are enough for blocking; Just now it triggered
> on the second (but the block had been lifted for my workstation since
> my first message). I guess, though, that that is then a discussion
> that needs to be had with sectigo.
>
> Would it make sense if i setup a quick measurement to get the exact
> rate limits they have set?

Sectigo recently disclosed their rate limits here: https://groups.google.com/a/chromium.org/g/ct-policy/c/jW7eKhnctHQ/m/NV7bxiJCAAAJ

Notably, there is a global limit of 400 requests per second might be what you're hitting and will make it impossible to measure the per-IP limit.

> > Also, certspotter should not crash or terminate due to log errors,
> > so if that's happening with the latest version, please file an issue
> > about it at <https://github.com/SSLMate/certspotter/issues>.
>
> Let me first figure out enough information to make this a fileable
> bug; It is running on OpenBSD 7.7; So far it crashed three times
> since 2025- 06-10T00:39:52+00:00, second and third time today, no
> logs; i updated to the current version on 2026-06-01. So I am not yet
> entirely convinced that this is a certspotter issue, and not
> something else in the environment being funny.
>
> I see that my monitoring noted new commits ~1h ago for 0.20.0; What is
> your recommendation/would be more useful in your opinion? Roll out
> 0.20.0 and see what happens, or keep on the current version to have
> less to bisect?

I would update to the latest version.

Regards,
Andrew

[Tobias Fiebig]

Moin,

> Good.  Just to confirm - are you actually getting health check
> failures about backlogs with the DigiCert and Sectigo logs?  Just
> because you see HTTP errors on stderr doesn't mean certspotter isn't
> keeping up with the log.

I actually got those yesterday and Wednesday, only for Sectigo logs.
Today, though, things seem to have recovered. Looking at the PPS graphs
of the machine it also seems like it was initially hitting a high
number of retries. Scrolling got a lot less wild since when I wrote my
initial mail.

So I would suspect things to be good for now...

> I would update to the latest version.

kk, thx. Let's see what happens.