That is not enough info to work with. There is a wide variety of problems that cause that.
If it only happens after redirect a common cause is if you have IPv6 AAAA records for your domain that don't work properly. Let's Encrypt will fallback/retry with IPv4 but only for the initial request - not the redirect.
@tomryder-inspirenet please start a new thread and answer the questions on the form you will be shown.
@jc-rimu Same for you but please answer as much as you can in this thread. It is highly unlikely all such HTTPS requests from Let's Encrypt would be failing. LE issues over 7 million certs per day and a failure like that would be triggering vast alerts in their internal monitoring.
Below is the form. Heck, even an actual domain name would give us something to work with.
=========================================================
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):