@omen OK, I figured out how configure Fastly now...
Please configure it like below:
Enable TLS - Yes
Verify Certificate - Yes
Certificate hostname - In my case, it is wildcard. But since you use the 'manual' provider, the hostname is subdomain.example.com.
SNI hostname - this is subdomain.example.com.
With the above settings, fastly serves up pages fine on http.
One thing to remember is, because you are using "manual" DNS provider, Cloudron requires "http" callbacks for Let's Encrypt to work. I am not sure how this works in fastly, does it allow you to have some URLs that are not "cached" ? I guess one way is to call the Cloudron app subdomain as "website.domain.com" but the domain in fastly should be something else like "realwebsite.domain.com" (meaning, name it different). This way, manual setting on Cloudron can continue to use HTTP reliably to get certificates.
If you want the domain names to be same, you have to use one of the automated DNS providers in Cloudron.
@nebulon Many thanks, @nebulon and @girish . The concern wasn't so much that I could not figure out what the status of my certs were external to Cloudron, but more that it would be nice if the area of the dashboard regarding certs would, as a matter of course, just say "You have 47 days remaining, and Cloudron should automatically update your certs in 17 days."
And, if I do mash the button to manually run a cert update, it would be nice to get a response in the dash that says "Success! New certs will expire in 90 days!" (Or, whatever it would say.)
I was mostly surprised that I got a certbot email saying I only had one day left, making me wonder what was up. (I did do a domain registration move at some point, and possibly other things that could have somehow upset the automatic update process. So, this isn't a bug report.) Not having a simple UI response to the act of hitting "update certs" (and instead being dumped into the log) is all I'm poking at.
I don't know how long my personal instance has been running (a month or two now), but it has been a joy. Thank you.
@aziz So, certificate for *.devz.cloud is already there, so if you install apps on subdomain it will work. Cert for devz.cloud (it is not a subdomain, so we have to get a separate cert from the wildcard cert) is getting rate limited.
You can just wait for 2-3 days to install an app on the bare domain and that should work. You should be able to install apps in subdomains in the meantime.
@humptydumpty That's right. No way to get wildcard certs with wildcard DNS.
To get a wildcard certificate, one needs to be able to program/automate the DNS. Let's Encrypt (acme) protocol requires one to programmatically setup TXT entries as part of getting the certificate. With a wildcard DNS, we have to now way to automatically setup those entries.
The protocol for normal certificates has a "http" based flow which allows it to work with a single wildcard entry.
@nj yes with the folder in place there adding the -r to solve this makes sense, however the initial issue is that this folder should not be there in the first place. As the name already suggests, I guess this was just some intermediate manual action to stash certs. Essentially if you don't actively use files in that folder then just delete it to solve this for future releases.
@scooke Interesting. The certificate and the PTR record check shouldn't have anything to do with each other. The PTR record check is really just dig -x IPADDRESS . Can you try that say 10 times over the course of an hour with your VPS server IP and see if it's consistent?
As for old certs, they are indeed preserved forever even if you remove the domain from Cloudron itself but the latest release will now clean up obsolete certs which are 6 months old.