Netgate is offering COVID-19 aid for pfSense software users, learn more.
Let’s Encrypt enforces rate limitations when using the production validation system, such as:
Five validation failures per account, per hostname, per hour
Each certificate may have at most 100 SAN entries
Only 50 certificates may be created per domain per week
A testing validation system exists for developers who are programming clients or administrators testing their settings. The test system has higher limits, which aid testing and development, but the test system does not produce certificates which are trusted publicly.
When validating using a method such as webroot or standalone the service must be available to the Internet on its standard port: 80 for HTTP or 443 for TLS-ALPN. This is a security limitation to prevent a user from running an alternate web server on a high- numbered port and obtaining a certificate for a server they do not normally control.
When creating a certificate, one or more fully qualified domain names (FQDNs) are listed on the certificate in the SAN list. Let’s Encrypt will query each of these domain names in DNS in different ways depending on the validation method.
When a validation method starts, the client obtains an authorization value from the server (authz).
For DNS-based methods, Let’s Encrypt checks for a TXT record in the form of
_acme-challenge.<domain name> which must contain the authorization value.
This proves that the person or system requesting the certificate controls DNS
records for the domain.
For File-based methods such as webroot or standalone, Let’s Encrypt connects to
an IP address obtained by resolving the A record for the FQDN and requests a
file from the web server at
.well-known/acme-challenge/ underneath the
webroot directory. This file contains the authorization value. This proves that
the person or system requesting the certificate controls web server for the