LetsEncrypt will create SSL certs that are valid for 3 months, and then is set to renew SSL every 2 months.
During initial SSL verification and subsequent renewals, LetsEncrypt will:
Verify the IP address for the cert matches what they see the domain name being tied to (which means that proxy servers can disrupt this verification)
Add a file to a folder named /well-known which will be used for a challenge process (redirects can interfere with this depending on where the redirects are)
Check ports 80 and 443 during the verifications; we’ve seen renewals fail due to port 80 being closed for instance
Check any alternate domains added to the cert - such as, if there is an alias domain or a www domain that was included in the SSL cert for the main domain. It’s an all or nothing verification, so if DNS records for an alt domain change, then that can cause a renewal to fail
@amiedema As you probably have a lot more expertise on this matter:
How to go around the fact that my site in cleavr has a root level (/) redirect while SSL still needs to be applied? All without manually interfering?
The root level redirect is what I’m not sure how to get around. What’s the purpose of it? An alias could also be added to a site, and then update the SSL cert by adding the alias as an alt domain.
My use case is having a website hosted on webflow (redirect target) where domain management at this level of detail is not possible.
Would you consider some kind of a “checkbox” on the ssl section that would then, when a new ssl certificate is being processed, shortly disable all root level redirects until ssl is installed?
In my opinion a server management software should not only be able to set up redirects to websites sitting on the servers being managed but also to redirect to outside.
But that might just be me thinking wrong about the process because of missing knowledge on server topics and i am willing to take another approach if feasable.
For CNAME records, you’d point one domain to another; such as www.siteA.com points to www.siteB.com with a cname record. CNAMEs can be managed in Cleavr if you brought in Cloudflare, DigitalOcean, or Porkbun DNS management profiles. Otherwise, you’d need to setup a CNAME record in the domain management site that you manage DNS records in.
In that case, I think the better placement of the redirect will be in the site’s NGINX config. Reason being, the redirects are processed first and NGINX will route based off of the first directive it encounters.
Remove the redirect from the ‘redirects’ section
Go to the site > site Nginx config and then add the redirect below the .well know acme challenge directive. This then should allow the SSL to process correctly.
Thank you for your help on this matter. Appreciate it!
So i added the directive as you suggested. I removed the redirect afterwards (for keeping the redirect alive as long as i add the directive).
After that I requested a new ssl certificate just for testing purposes (“SSL Certificates” → “Three Dots” → “Edit SSL Certificate” → Primary Domain is melaniebusch.archi and “Alternate Domains” has value “www.melaniebusch.archi” → Button “Update”)
After doing stuff for a while it shows an error without further clarification:
I’m not sure what I was thinking… LetsEncrypt still will check the root domain which will be redirected to a different one, which will cause the process to fail. I’ll think about it some more…
I was trying to see if a directive matching a referrer might work to not redirect LetsEncrypt traffic, but I can’t seem to get that to work.
Another option would be, if you are using Cloudflare, you can add an SSL at CF for the domain via using their proxy services, that way there is SSL from client to CF and you won’t need to manage certs on the server.
One last option would be to use a custom cert with a far out expiry date. CF issues certs that expire up to 15 years.