¿Cuál es el límite de tasa de crt.sh?

crt.sh no publica límite de tasa. Empíricamente es de unas 5 peticiones por minuto por IP origen para el endpoint de salida JSON. El límite puede bajar más cuando el Postgres backend está bajo carga — manifestándose como errores 502 o resultados vacíos en lugar de 429 explícitos.

¿crt.sh devuelve 429 al limitar?

Normalmente no. crt.sh tiende a devolver 502 Bad Gateway, un array vacío o una query larga que termina en timeout. No hay cabecera Retry-After. La solución de la comunidad es dormir 12-15 segundos entre peticiones como base.

¿Cómo se salta el límite de crt.sh?

No se salta — Sectigo opera crt.sh como bien público y rotar IPs es de mal gusto. Opciones reales: (1) cachea agresivamente cliente-side, (2) batch con comodines en lugar de por-subdominio, (3) usa servicio alternativo con cuotas propias (CT Radar, Censys, Cert Spotter), (4) auto-aloja un mirror.

Límite de tasa de crt.sh — lo que realmente sabemos

crt.sh no publica límite de tasa, pero cualquiera que haya tratado de scriptearlo se ha encontrado uno. Aquí el consenso de años de pruebas de la comunidad y formas de mantener el pipeline funcionando.

Los números, hasta donde sabemos

~5 peticiones por minuto por IP origen para el endpoint JSON, sostenido durante años en reportes comunitarios.
Sin 429. El servidor devuelve 502 Bad Gateway, arrays vacíos o queries colgadas en su lugar.
Sin Retry-After. El backoff es cosa tuya. ~12-15s entre peticiones es la regla habitual de la comunidad.
Penalización mayor para comodines. Las queries con comodín (%.example.com) consumen más presupuesto y golpean el límite antes.
Asimétrico: la interfaz HTML normalmente responde mientras el endpoint JSON rechaza, sugiriendo rutas separadas.

Por qué existe el límite

crt.sh consulta una sola instancia PostgreSQL contra miles de millones de filas. Queries pesadas concurrentes de un cliente pueden dejar sin servicio a todos. Sectigo provee crt.sh como bien público gratuito — el límite existe para mantener disponibilidad, no para monetizar.

Cómo mantener tu pipeline funcionando

1. Cachea agresivamente

Los datos CT solo crecen. Una vez que tienes el historial de certificados de un dominio, solo importan las entradas nuevas. Usa ETag/conditional requests contra tu propio caché, no contra crt.sh.

2. Prefiere comodines sobre bucles por subdominio

Una query a %.example.com cuesta menos que 200 queries individuales, aunque los comodines tienen mayor coste por query.

3. Usa un servicio con cuotas publicadas

CT Radar ofrece 100 búsquedas/día en el plan gratuito con cabeceras 429 + Retry-After explícitas al exceder. El plan Pro sube a 10K/día. Censys, Cert Spotter y otros tienen cuotas similares publicadas.

4. Auto-aloja un mirror de CT

Si tu volumen lo justifica, consume los CT logs directamente con certspotter (open source) e indéxalos. Es lo que crt.sh, Censys y CT Radar hacen internamente — no hay atajo.

¿Te chocaste con el límite de crt.sh? Prueba CT Radar

100 búsquedas al día en el plan gratuito. Cuotas documentadas. Respuestas 429 reales. Sin misterios.

Buscar ahora →