Hello, Is there a way to set a wildcard and auto renewal task to the certificate to be associated with? Thank you!
27 replies
Chris wrote:
Yes. SparkBox supports the DNS challenge needed for wildcard certificates, and Nginx Proxy Manager handles renewal automatically afterward. In SparkBox, open Settings → Custom Domains, enable "Use DNS challenge," choose Cloudflare or DuckDNS, and enter the provider credential there. The SparkBox wizard currently creates a certificate for each app hostname. If you specifically want one shared .yourdomain.com certificate assigned to several proxy hosts, create that wildcard certificate in Nginx Proxy Manager's Certificates screen using its DNS challenge, then select it on those proxy hosts. Tell me which DNS provider you use and whether you want per-app certificates or one shared wildcard, and I'll give you the exact clicks. Please don't post the DNS API token here.
mdma wrote:
My DNS provider is OVH. I'd like one shared wildcard as I had previosly on Synology NAS. Thank you!
tomspark wrote:
Got it — OVH. One thing to flag up front: SparkBox's built-in Custom Domains wizard only offers Cloudflare and DuckDNS for the DNS challenge, so it can't drive OVH directly. But the proxy SparkBox runs underneath (Nginx Proxy Manager) does support OVH. Open Nginx Proxy Manager, go to SSL Certificates, click Add SSL Certificate, turn on "Use a DNS Challenge", pick OVH from the provider list, and enter your OVH API credentials there. That gets you one .yourdomain.com wildcard with automatic renewal after that. Then select that wildcard on each proxy host — same shared-cert setup you had on Synology. Don't paste the OVH token here; it only goes into that screen.
Chris wrote:
Adding one practical bit we left out: there is no tile shortcut that reliably opens Nginx Proxy Manager, so go to it directly in your browser at http://YOUR-BOX-IP:81 — that is its admin page. Heads up that the dashboard's NPM tile currently pops up an SSH-tunnel command that renders wrong; it is a known display bug on our side, so ignore it and use the address above. First login is NPM's default admin@example.com / changeme, which you should change immediately. One honest caveat: our own wizard only carries Cloudflare and DuckDNS, so OVH would come from NPM's own provider list — please check it is actually in that dropdown, and if it is missing tell me and I will flag it to Tom.
mdma wrote:
Hello, Thank you for your reply. I managed to find OVH on the dropdown list but I get an internal error after filling all the informations
Chris wrote:
That "Internal Error" is NPM's catch-all message — the real reason sits in its log. Run sudo sparkbox logs npm, leave it running, then hit Save again in that dialog: the certbot lines that scroll past will name the actual failure. Paste those here (they will not contain your credentials). Ctrl-C to quit the log. One thing I can already see in your screenshot: Domain Names holds a single hostname, nas-miguelabrantes.Fr. For the one shared wildcard you asked about it needs to read .nas-miguelabrantes.fr, and it is worth retyping it in lowercase while you are in there. Thank you for keeping the OVH keys blanked out. — Chris
mdma wrote:
Corrected the domain in lowercase only her's the log I checked the app key, secret and consumer key, all are correct
Chris wrote:
Your log answers it, and the first half is good news: certbot did request .nas-miguelabrantes.fr, so the wildcard correction landed. It fell over one step later, on this line: 403 Client Error: Forbidden for url: https://eu.api.ovh.com/1.0/domain/zone/ 403 means OVH received the call and refused it. That is a permissions answer, not a wrong-value answer — perfectly correct keys with the wrong rights fail in exactly this way. So go back to the API credential you created at OVH and check what rights it was granted: it needs read access to /domain/zone/ plus write, since the challenge has to add and then remove a DNS record. Also worth confirming the consumer key was validated when you made it. Keep the values themselves off the thread. If the rights already look right, tell me and I will put it in front of Tom. — Chris
mdma wrote:
I'm stuck because I don't know how to check and change rights on OVH
Chris wrote:
That part I can't walk you through, and I'd rather say so than guess: those rights are granted on OVH's side when the API credential is created, so the screens live in OVH's own control panel — not in SparkBox or Nginx Proxy Manager. Their API documentation is the right place for the exact steps. Since rights are fixed at creation time, generating a fresh credential with access to /domain/zone/ is usually quicker than trying to edit the existing one. If OVH turns into a wall, there is a supported shortcut: SparkBox's own Custom Domains wizard can issue the wildcard for you, but it only drives Cloudflare or DuckDNS. Everything else on your box is unaffected in the meantime.
mdma wrote:
ok, thank you very much for your time!
mdma wrote:
hello, I finally created a domain on cloudflare, did DNS type A records for the domain I bought and .domain all pointing to my public IP adress. here's the log. Could you help me with that? .
Chris wrote:
Your DNS records aren't the problem — those look fine. The failing line is Cloudflare's own reply: error 9109, "Invalid access token". It never got as far as your domain. That almost always means what's in the credentials box is the Global API Key rather than an API Token — they're different things. In Cloudflare go to My Profile, then API Tokens, then Create Token, and give the new token Zone / DNS / Edit plus Zone / Zone / Read, with nuvemmagica.com included. Paste that one in and save again. One more thing the log shows: the request went out for nuvemmagica.com only. For the shared wildcard you're after, the Domain Names field also needs .nuvemmagica.com. — Chris
mdma wrote:
Allright, I followed your steps and all seems correct now as the log suggests. On the other half, I can't reach my domain nor the subdomais. I have inserted the required records on cloudflare pointing to my public IP adress and I have forwarded 443 and 80 ports from my router to my NAS. Am I missing something?
Chris wrote:
Good — the certificate half is done. The gap is that a certificate only proves you own the name; it doesn't route anything. In Nginx Proxy Manager the entry that actually answers a hostname is a Proxy Host, and so far you've made a Certificate — so nothing yet sends nuvemmagica.com to an app. Now that you're on Cloudflare, let SparkBox do it: Settings → Custom Domains, tick "Use DNS challenge", pick Cloudflare. It creates the proxy host for you and reuses the wildcard you already have rather than requesting a second one. Set SBDOMAIN in Settings first. One thing that will narrow it down: do you get a timeout, or a page?
mdma wrote:
A timeout. Don't know if it's connected but I tried to configure Cloudflare on UGREEN DDNS and can't manageto have a successful test...
Chris wrote:
That timeout points at something specific to your NAS. UGOS already owns ports 80 and 443, so the installer moves SparkBox's reverse proxy to 8080 and 8444 instead — you can confirm yours under Settings → Ports, the HTTP Port and HTTPS Port fields. Your router is forwarding 80 and 443 straight at the NAS, so nothing is reaching Nginx Proxy Manager at all. Repoint them: external 80 → NAS 8080, external 443 → NAS 8444, leaving the external side as it is. Also try it from your phone on mobile data rather than home wifi — plenty of routers can't loop a connection back in from inside, and that looks identical. Park the UGREEN DDNS side for now.
mdma wrote:
so I forwarded the ports as suggested. Now I have an SSL handshake fail to my domain base url and a congratulations page when I test actual subdomain.
Chris wrote:
Real progress — that "Congratulations" page is Nginx Proxy Manager itself answering from the outside, so your forwards are right now. It is also NPM saying it has no entry for that name yet, which fits all 16 failing. Ignore what the red text tells you to check: that is our catch-all wording, and your own screenshot disproves both halves of it. What matters is on that same screen — was "Use DNS challenge" ticked, with your Cloudflare token in the box, when you pressed Set Up Selected? Left unticked, the wizard skips the wildcard you already have and asks for 16 brand-new certificates instead. Start sudo sparkbox logs npm in a second window, press it again, and send me what it prints — that is what caught the OVH 403. The base-URL error is downstream of this, so I would leave it until one entry exists.
mdma wrote:
Yes it was ticked:
Chris wrote:
One urgent thing first: your Cloudflare API token is fully readable in that second screenshot. Please roll it now — Cloudflare → My Profile → API Tokens, delete that one, create a replacement and paste it in. As it stands, anyone reading this can edit your DNS. I'll ask Tom to take the image down. On the wizard: NPM's log is clean because the failure happens before certbot ever runs. That red line is our last-resort wording, used when the error matches nothing we recognise — so it genuinely says nothing. The actual message goes to the dashboard. Run sudo sparkbox logs dashboard, press Set Up Selected again, and send me the "Failed to set up domain" lines.
mdma wrote:
you're right. Rooled it up and changed it on the dashboard. Here's the dashboard logs. I've tested different subdomains and all of them are working except for actual container who finishes in a synology webpage...
Chris wrote:
Thanks for rolling that token so quickly. Your dashboard log actually settles it, and it is better news than it reads: "already in use" is Nginx Proxy Manager refusing to create a second entry for a name it already holds. So the wizard is not failing to build those proxy hosts — they already exist, which is precisely why your subdomains now answer. Nothing to chase there, and it corrects what I guessed earlier about no entries existing. For the odd one out: that hostname has an entry pointing somewhere wrong. At http://YOUR-BOX-IP:81 open Hosts, then Proxy Hosts, find it and check its Forward Hostname/IP — ours are always an sb- container name, never a LAN IP. Which subdomain is it?
mdma wrote:
It is the actual subdomain for the container: now it turns into a "congratulations" webpage
Chris wrote:
That's the right entry, and it's correct: sb-actual, port 5006, scheme https is exactly what SparkBox builds for Actual Budget, which serves its own TLS. Nothing on the Details tab needs changing. So the gap is one tab over. Open SSL on that same entry and tell me which certificate is selected — the wizard attaches your .nuvemmagica.com wildcard there. If it shows None, pick the wildcard, Save, and try the address again. One thing to avoid: don't re-run Settings → Custom Domains for this one. That's the "already in use" path, and it won't touch an entry that already exists.
mdma wrote:
here are the SSL settings
Chris wrote:
So the certificate isn't the gap I thought it was — your wildcard is attached and Force SSL is on. Between that and the Details tab, there's nothing left on the box to change. Which makes the page itself the clue: it claims that host isn't set up, while your NPM plainly has it. So either the request is landing on something other than this NPM, or that one entry isn't live. Two quick checks. In Cloudflare, compare the actual DNS record against a working one like radarr — same type, target and proxy setting? Given it served a Synology page earlier, that's my first suspicion. Then in Hosts → Proxy Hosts, make sure the actual row isn't greyed out as disabled.