Tell nginx to use a different config file?

[danb35]

This is actually somewhat on-topic, but it's quite a way outside "normal" Free/TrueNAS usage, hence my posting here in OT.

tl;dr: Is there a straightforward way, under FreeBSD (specifically, Free/TrueNAS), to tell nginx to use a different config file than the default /usr/local/etc/nginx/nginx.conf?

Background:

@Constantin and I are pondering how we can use HTTP validation to get ACME certs for a Free/TrueNAS server. Doing it with DNS validation is relatively trivial, assuming a suitable DNS host; I've already documented that. But we both have local CAs running, and would prefer to use those with HTTP validation. In order for that to work, the web server must be able to serve certain contents from /.well-known/acme-challenge/pseudorandomstring.

From what I can see of the default nginx.conf file, it won't handle such a request, and experimentation confirms this--it simply redirects to the GUI login page. I could, of course, open a ticket with iX to modify nginx.conf to handle that path, but that likely wouldn't be handled very quickly, even if it got the requisite number of votes, and I lack the requisite skill to make the necessary middleware changes and do a PR. So, I'd proposed a crude, but likely effective, workaround--when renewal is required,

• Save a backup copy of the system's nginx.conf file
• Overwrite with a new, bare-bones one that will handle the challenge request appropriately (and, ideally, refuse anything else)
• Issue the cert
• Replace the original nginx.conf

Simple enough to script, even if a bit brute-force. The GUI will have a few seconds of downtime when this happens, of course, but it should be very few.

But now I'm messing with the original config files, and if something goes sideways, I may be locked out of the GUI altogether. It should be pretty low-risk, but... But then I remembered that lots of software lets you set a rc.conf variable for the location of the config file--so maybe instead of overwriting the nginx.conf file, I could temporarily point nginx to a different file to serve the challenge token, and then point it back to the original. That way, I never have to touch the original file.

So I took a look at the nginx rc script, and that's where I got confused. It looks like it does support multiple nginx configurations, but they're tied to "profiles"--and Google isn't helping me understand what these are in this context.

 

[sretalla]

Wouldn't it be a case of starting the service (or running the nginx executable) with the config file parameter specified (presumably from the rc.d file)?

--conf-path=path

Since that's a path, maybe any .conf file in that path would be read or maybe you still need to have one called nginx.conf.

 

[Constantin]

I'd be happy to contact the folk at smallstep to see if they have any recommendations. Carl (the author of the blog post describing how to build a CA) was amazing diagnosing my issues with win-acme and how to fix them. It also helps that win-acme's verbose mode is fantastic re: showing every issue.

While adjusting nginx is one approach, as danb35 mentioned to me in a DM, a more elegant solution would be for the ACME page within the trueNAS UI to allow users to specify what directory will be accessed when a local ACME script tries to access the /.well-known/acme-challenge/ directory as part of the SSL certification-creation process. See System -> ACME DNS Authenticators. Then, TrueNAS could allow the user to specify which local directory would hold the needed contents of the /.well-known/acme-challenge/, and finally nginx could serve it up.

I created a suggestion re: revising the ACME UI and the underlying nginx infrastructure in the TrueNAS jira system. Perhaps they'll take us up on it. What do you think @morganL and @Kris Moore ?

 

[Arwen]

One thing I have seen on other embedded web servers, is a configuration option to allow user content. Perhaps that's what we need. An option to enable user content, and whence enabled, another option to specify the path to the web pages.

This would allow any generic web pages to be available, with the caveat that it would default to the TrueNAS GUI if you don't specify a path like;

https://MY_TRUENAS/.well-known/acme-challenge/pseudorandomstring

 

[Constantin]

Dan brown brought up a good suggestion over at Jira: simply have a well-documented location that nginx will serve up the acme-related files from and let the users do the rest.

in the spirit of the GUI to make things more visual and less CLI, I’d prefer being able to enable the relevant response and upload any needed files via the GUI. But in the interim, a fixed location for the info would be perfectly fine also.

 

[danb35]

GitHub - danb35/freenas-nginx-swap: Swap FreeNAS' nginx.conf for a temporary one, to obtain ACME certificates

Swap FreeNAS' nginx.conf for a temporary one, to obtain ACME certificates - danb35/freenas-nginx-swap

github.com

 

[natanscott]

I'd be happy to contact the folk at smallstep to see if they have any recommendations

 

[Constantin]

I’m not sure what small step can do. The issue is with TrueNAS and how Nginx is implemented, not the CA itself. My internal CA has been working flawlessly. Ditto the @danb35 script.