You are here
Reposted from account approval/welcome thread
I would like to use the Tunrkey Nextcloud LCX on my Webserver.
As my webserver can only serve the domains with a public IPv6 addresses (no public IPv4 addresses availabe), I use cloudflare DNS proxy, to get a valid pubic Ipv4 address for my nextcloud instance. This works great and I am able to run nextcloud, get updates and installing apps.
But I've come over one problem with renewing the certificates for my domain. For the first three month all was good, and the nextcloud was secured with a cloudflare edge-certificate, but this ran out today and I was not able to renew the certificate.
Openconfconsole shows me an error:
dehydrated-wrapper: FATAL: │ │ dehydrated exited with a non-zero exit code.
In short, I would like to get some help, to solve this issue and learn how to get valid certificates with the use of cloudflares proxy DNS function.
If this forum could help me, would be great!
Thanks for approving me!
Thanks for approving me!
If you need some logfiles, please let me know how I can provide you with necessary information.
Apologies I'm a bit slow getting back to you.
Apologies I'm a bit slow getting back to your issue. I got sidetracked with some priority stuff.
Also FYI, if you sign in with your website account, you can post without needing for me to approve it. So even if I'm a little slow, someone else might jump in to help you in the meantime. You'll also be able to start a new thread if have a different issue in the future. ("guest" users can only post comments on existing threads).
Anyway, to your current issue...
I'm 99% sure that the issue is Cloudflare related. I'm pretty sure that they redirect http to https by default, so even if you have port 80 open, Let's Encrypt won't be able to connect to your server, so the challenge (domain validation) will fail. Although if that is the issue, it's weird that it worked the first time. Although perhaps that was before you configured Cloudflare? Or changed some settings in Cloudflare since?
Regardless, I know it can work as this site is running on a TurnKey server and also uses Cloudflare. Obviously HTTPS is working here. I do vaguely recall needing to adjust something in Cloudflare setting to make it work though.
I'm pretty sure that the change needed does have implications, but I wouldn't expect it to have any impact on the IPv6 IP.
Unfortunately I can't log into Cloudflare at the moment so can't give you specifics. If you want to continue with HTTP-01 validation you'll need to have a poke around in the Cloudflare settings yourself. As I say, it should be something to do with disabling the HTTP to HTTPS redirection. If you can't find it, have a google for "lets encrypt cloudflare http-01 fails" or similar and you should get some helpful results - probably either on the Let's Encrypt or Cloudflare forums. If you go that way and find a solution, it'd be great if you could post back with the info to make it easier for other TurnKey users who might hit the same issue.
Alternatively, if your server is a relatively recent TurnKey server (which it sounds like it is) then you could use "DNS-01" validation instead. Make sure that your TurnKey server is v18.x like this:
And look for 18.x in the line that returns. E.g. if it's v18.1 you'll get this:
So long as it's v18.x then make sure that you have the latest Confconsole version:
Then run confconsole:
Select Advanced >> Get certificate >> DNS-01 and follow the prompts.
You will need to provide authentication details so your server can create (and destroy) the DNS records that are needed to validate your domain. IIRC there is some basic Cloudflare config included by default, but you will still need to check what is required for Cloudflare and enter the relevant details into Confconsole. If need be, you can check the Cloudflare docs too.
If I'm wrong and it doesn't already included some basic/example config, please let me know and I'll check it out myself and tell you exactly what you need to do - and include it in future releases of Confconsole.
Good luck and please let me know how it goes regardless.
No apologies needed at all. I
No apologies needed at all. I am glad that you take the time to help me to fix the issue.
How do I sign in with an website account, or how do I get one? The nextcloud is not running on my own domain, so I can not share the domain easily name without permission.
I am on
turnkey-nextcloud-18.1-bookworm-amd64
confconsole is already the newest version (2.1.6+2+ge808780).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
As said the domain on proxmox is only hosted with a public IPv6 and an internat IPv4. Cloudflares proxy option turns it into an publich cloudflare IPv6 plus public IPv4.
I will try to pause cloudflare for 24h and see if that helps and then try to reissue the DNS-01 certificate. Maybe it is cloudflare that cached a previous certificate and needs some time to delete it and to accept a new one?
In Cloudlfare I genereated a DNS token and put it into confonconole setttings, also the domainname + wilcard for the domain with *.
Looks like this works on other LXC turnkey nextcloud containers I use in combination with the domain also hosted on a plesk server with Cloudflares origin certificate there. There only the DNS for the subdomain to the nextcloud has an IPv6, like the domain mentioned above.
So do I need to take some steps to download and install the cloudflare certificate into the turnkey-container if I'd like to use cloudflares origin certificate, which lasts for 15 years?
It would be nice if you could pinpoint me to a manual how to do so, if this is possible.
Otherwise, if auto renewing with Letsencryt would work, I do not have a problem to authenticate the domain with this type of SSL.
I will report back, if pausing cloudflare will do the trick.
Thanks so far. If you have any other input and ideas, please let me know!
You already have a website/forums account and it's enabled :)
You have a website/forums account already and I just double checked and it is approved/activated already. :)
Log in using your email and the password you set when you signed up ~3 days ago. If you don't recall your password, then you can reset it. Please let me know if you have any issues.
Back to your cert issue. My initial thought was that something had changed on your end between you initially (successfully) getting the cert and renewal. As you may be aware, LE certs are only valid 90 days. Is there anything that you can think of that you (or someone else) have changed since you initially got the cert? In particular I'm thinking firewall config, networking & routing config, Cloudflare config, etc. Although please share any server and/or environment changes you can think of between the successful cert and the failure. Even if it doesn't seem relevant, who knows, perhaps it might be?
Regardless, rereading your posts and thinking about it a bit more I wonder if there is some edge case bug/issue with Confconsole that for whatever reason we aren't seeing. TBH I'm fairly confident because as I mentioned we have a number servers getting renewing certs fine - but perhaps?
Assuming that the IPv6 config has existed right from the start, I highly doubt that'd a factor. If that has changed since you launched then perhaps?
Probably the first thing I should have asked for was the log file. I.e. the output of:
And the contents of the Confconsole LE config:
One final thing to check is the permissions of the cron job (what triggers the cert renewal). Given what you've reported (TurnKey server & confconsole versions) I expect it to be ok, but just in case...:
Hopefully that will help us sort it out...
Hi, basically the only thing
If I use the dns-01 challenge
Sorry again for slow reply...
I'm sorry (again) for my slow reply. Unfortunately your post came just after I left for some time off over Christmas/New Year. I'm back this week but I've only just noticed your post now... :(
Anyway, the first thing I noticed is that the base domain appears to have a valid certificate!? So the current cert should work ok as is. Here's the relevant log output:
However it looks like it's also trying to generate a certificate for a wildcard domain: *.cloud-example.xy - which is failing
Certificates for wildcard domains can't be renewed via a HTTP-01 challenge. So even though it appears that you have a valid cert for the "main" domain, it is failing on the wildcard one. IIRC the way that the TurnKey Let's Encrypt plugin works is that it won't consider the process successful unless all domains configured are updated successfully. It still doesn't explain why it stopped working though, it should have never worked! I can only assume that initially it wasn't configured to get a wildcard cert and sometime within the 90 days while it was working, someone added the wildcard domain.
A wildcard domain is possible via DNS-01 validation. However there is something wrong with the DNS-01 Cloudflare config. The DNS record is not being created, so the Let's Encrypt validation fails. It looks like for some reason when Confconsole tries to create the required DNS record accessing Cloudflare fails.
Either there is something wrong with your Cloudflare credentials or other Confconsole DNS-01 config; or there is a bug in Confconsole. It's working fine for me, but I use AWS Router53. I do have a Cloudflare account though, so if you remain stuck, then when I get a chance, I'll test it out.
Regardless, I suggest that you delete all the config files starting with 'confconsole' in /etc/dehydrated, then start again via Confconsole. If you don't need a wildcard domain, then getting a cert via HTTP-01 should work fine - so long as you have "Always Use HTTPS" disabled in Cloudflare (SSL/TLS >> Edge Certificates). If you need/want the wildcard domain then you'll need to persevere with the DNS-01 config. I suggest deleting the API key you generated (assuming that it's not used for anything else) and generate a new one.
Let me know if you have any joy...
No worries, at all! Maybe it
No worries, at all! Maybe it has had something to do with a couple of reasons you mentioned!
What I did, I created a new container and transfered database and data to the new nextcloud.
Then Certification worked out of the box with HTTP-01 challenge.
And yes, I tried several time with and without wildcard, maybe that was source of an error too. But maybe also, that in the new instance of the container all files in /etc/dehydrated from the old installation where gone.
I will observe now, how it looks like in about three month, when the renewing starts again.
For now I am good. I will get back and report and I really appreciate your help and time you put in your answers!
Glad to hear that you are back up and running.
Glad to hear that you are back up and running. Why it stopped working is still something of a mystery, but at least you found a workaround.
Hopefully it will just keep working this time. But please feel free to post back if you have issues again.
Please also feel free to start another thread(s) if you have any new/different issues, general questions, suggestions for us or any other Turnkey Linux feedback (good or bad).
Nextcloud Let's Encrypt certificate problem when behind nginx
Thanks for posting the nginx.conf!
Great thinking to also post your nginx.conf! Thanks for that, I can now see exactly what is going on. And perhaps that was even the problem before and I just missed it?
Anyway, looking at your confconsole LE log output, Let's Encrypt is expecting the change to be served from this URL: http://nextcloud.solidarit.gr/.well-known/acme-challenge/
But your Nginx config is redirecting https://nextcloud.solidarit.gr/.well-known to https://nextcloud.solidarit.gr/index.php/.well-known (note the 'index.php' in there). This bit of your nginx.conf:
Nextcloud isn't running while the challenge is being served. That means that the url your Nginx proxy is trying to redirect to is not available so Nginx returns a 502 (Bad Gateway - proxy can't connect to the backend).
Even if that URL returned the correct challenge and gave a 200 (ok) I'm fairly sure it would still fail because LE only works on http URLs it will fail with a https URL and IIRC their docs note that there should be no redirect regardless.
Having said that, I am unfamiliar with how NC uses those urls for the web dav functionality. I have a suspicion that you probably want that redirect for Nextcloud (although I could be wrong). If that's the case then you still want to redirect /.well-known while NC is running - but not while your server should be serving a LE challenge.
So I see a few options:
Just remove that redirect in nginx conf and cross your fingers; maybe it will stop web dav working, maybe not?I think that the last is the best solution. Because the Apache server in the NC appliance won't be running when the challenge is served there will be no redirect, but when the webserver in your NC server is running, the redirect will occur just like it does now.
Actually, just looking at the NC docs it appears that the NC .htaccess file should already include this:
That should redirect those NC urls already. But when I was testing our appliance before I noticed that NC was complaining about those urls not redirecting as they should. TBH I'm not sure why because the config we ship looks right - it should process the NC .htaccess file so already do those redirects?!
Anyway, that doesn't seem to be the case, so I suggest removing the redirects from Nginx (at least that last one) and update the NC apache config on your NC server to include the code snippet from the NC docs.
Put it in the 443 virtual server block in /etc/apache2/sites-available/nextcloud.conf - i.e. between these 2 lines.
Then restart your Nginx proxy (to apply the updated proxy config) and for good measure, also restart Apache on your Nextcloud server. Clear your cache and cookies (at least for your NC url) and then double check that all works as it should with NC. Assuming it does, then try again to get a cert. I would expect it to "just work".
Fingers crossed...
Add new comment