Seneste opdatering: 22. okt. 2024 | Se al dokumentation

Bemærk: Den engelske version er blevet opdateret siden oversættelsen (12. dec. 2024) Se på engelsk

Let’s Encrypt giver kaldsgrænser for at sikre rimelig brug af så mange mennesker som muligt. Vi mener, at disse kald grænser er høje nok til at arbejde med for de fleste mennesker som standard. Vi har også designet dem, så fornyelse af et certifikat næsten aldrig rammer en kalds grænse, og således at store organisationer gradvist kan øge antallet af certifikater, de kan udstede uden at kræve intervention fra Let’s Encrypt.

Hvis du aktivt udvikler eller tester en Let’s Encrypt klient, så benyt venligst vores staging miljø i stedet for produktions API. Hvis du arbejder på at integrere Let’s Encrypt som udbyder eller med et stort websted, bedes du gennemgå vores Integrations Guide.

Hvordan vores kald begrænsninger virker

Grænser beregnes, per anmodning, ved hjælp af en utæt spand algoritme. Denne tilgang giver fleksibilitet i, hvordan du bruger dine tildelte kald. Du kan enten fremsætte anmodninger i fuld fart – op til den fulde grænse – eller udjævne dine anmodninger for at undgå risikoen for at blive begrænset.

Hvis du har ramt en kaldsgrænse, har vi ikke en måde at nulstille den midlertidigt. Ingen grund til bekymring - din kapacitet for denne grænse vil gradvist genopfyldt over tid, at tillade dig at fremsætte flere anmodninger uden du behøver at gøre noget. Tilbagekaldelse af certifikater nulstiller ikke kaldsgrænser, fordi ressourcerne til udstedelse af disse certifikater allerede er blevet forbrugt. For mere information, se venligst Prøv igen efter overskridelse af kalds grænser.

Grænser For Kontoregistrering

Følgende grænser gælder, når abonnenter anmoder om en ny konto ved hjælp af new-account API’et. Overskridelse af disse grænser er meget sjældent. Vi anbefaler, at store integratorer anvender et design, som bruger en konto til mange kunder.

Begrænsninger For Certifikatudstedelse

Følgende grænser gælder, når abonnenter anmoder om et nyt certifikat ved hjælp af new-order API’et. Overskridelse af disse grænser er mere almindeligt, især for store hosting-udbydere eller organisationer, der udsteder certifikater for mange værtsnavne.

Begrænsnings undtagelser for fornyelser

Let’s Encrypt genkender en ny certifikatordre som en “fornyelse” på to måder: den foretrukne metode er via ACME Renewal Info (ARI), som er undtaget fra alle -satsgrænser, og den anden bygger på ældre detektionslogik, som betragter ordrer med nøjagtig samme sæt værtsnavne som fornyelser, men kan stadig være underlagt visse kapacitetsgrænser.

ARI Fornyelser

Fornyelser koordineret af ARI tilbyder den unikke fordel ved at blive fritaget for alle kapacitetsgrænser. Klienter, der understøtter ARI med jævne mellemrum tjekker med Let’s Encrypt’s servere for at afgøre, om dit eksisterende certifikat bør fornyes. Når det optimale fornyelsesvindue er nået, anmoder klienten udtrykkeligt om en ny ordre, der angiver det certifikat, den erstatter. Hvis den nye ordre indeholder mindst et værtsnavn, der matcher det certifikat, den agter at erstatte, og certifikatet er ikke tidligere blevet erstattet med ARI, ordren vil ikke være underlagt nogen satsgrænser.

Ikke-ARI-fornyelser

Hvis din klient eller hostingudbyder endnu ikke har tilføjet support til ARI, din ordre kan stadig betragtes som en fornyelse af et tidligere certifikat, hvis det indeholder nøjagtig samme sæt værtsnavne, ignorerer kapitalisering og rækkefølgen af værtsnavne. For eksempel, hvis du har anmodet om et certifikat for værtsnavne [www.eksempel.com, example.com], kan du anmode om fire yderligere certifikater for [www. example.com, example.com] før du rammer på Nye certifikater pr. eksakt sæt af Værtsnavne kapacitetsgrænse. Hver af disse nye ordrer vil blive betragtet som fornyelser og ville være fritaget fra Nye Ordrer per konto og Nye Certifikater per Registreret Domæne satsgrænser. I modsætning til ARI fornyelser vil disse ordrer ville stadig være underlagt Authorization Failures per Hostname per Account og New Certificates per Exact Set of Hostnames.

Genforsøg efter at have ramt kapacitetsgrænser

Alle vores kapacitetsbegrænsning fejlmeddelelser følger det samme format. For eksempel:

too many new registrations (10) from this IP address in the last 3h0m0s,
retry after 1970-01-01 00:18:15 UTC.

Du bør være i stand til at foretage den samme anmodning efter den angivne dato og tidspunkt. Hvis din anmodning overstiger kapaciteten af mere end en af vores grænser, vil vi altid returnere fejlmeddelelsen for den grænse, der nulstiller længst i fremtiden.

Forsøg Efter Header

Vi inkluderer en Retry-After header i alle rate limit fejlsvar, der angiver varigheden af din klient bør vente, før den forsøger igen.

Du kan få en liste over certifikater udstedt for dit registrerede domæne ved at søge crt.sh eller [Censys](https://search. ensys.io/#),, der bruger den offentlige Certificate Transparency logs.

Anmodning om overskridning

Hvis du er en stor værtsudbyder eller organisation, der arbejder på integrationen til Let’s encrypt, har vi en [kaldsbegrænsende -form] (https://isrg. ormstack.com/forms/rate_limit_adjustment_request), der kan bruges til at anmode om højere satsgrænser. Det tager et par uger at behandle anmodninger, så denne formular er ikke egnet, hvis du blot skal nulstille en hastighedsgrænse hurtigere end den nulstiller på egen hånd.