How can I encrypt using Nginx Proxy Manager certificates?

[RealHypnoticOcelot]

I use Nginx Proxy Manager as a reverse proxy, and that includes provisioning certificates from Let's Encrypt. NPM stores certificates like this:

The FQDN isn't included in the folder name, and as far as I can tell that trips things up with DMS. Is there any way around this? Thanks in advance!

[polarathene]

SSL_TYPE=letsencrypt does expect a specific layout yes. Caddy has a similar issue where it has storage based on provisioner (LetsEncrypt vs ZeroSSL) and how that can change at renewal if you haven't locked it down to only one provisioner.

If NPM is similar to this with non-deterministic location over time, you'll have a problem. You may need to write a script that monitors the location and knows how to detect the latest certificate and copy that over to a static location that you can use with DMS.

We do have SSL_TYPE=manual which allows you to specify the location for the certificate and key via ENV when it doesn't match the SSL_TYPE=letsencrypt layout. Presently that lets you set the full file path too. In future we might implement something smarter that takes a location to a folder and checks all files for the latest valid DMS certificate, there is a TODO tracking issue for this open at the DMS repo just no one has had time to contribute it yet.

You could also reach out to NPM for advice on how you might get a deterministic path, perhaps via symlink that NPM updates?

[RealHypnoticOcelot]

Okay, thanks!

So I've been messing around with SSL_TYPE=manual, although without much success. What I did was mount /services/nginx-proxy-manager/letsencrypt/live/npm-43/ to /tmp/dms/custom-certs/ in the container, and modified these lines in the configuration:

SSL_CERT_PATH=/tmp/dms/custom-certs/fullchain.pem
SSL_KEY_PATH=/tmp/dms/custom-certs/privkey.pem

Unfortunately, DMS is having some issues recognizing the files for one reason or another. This is the error I get when I set SSL_TYPE=manual:

ERROR start-mailserver.sh: TLS Setup [SSL_TYPE=manual] | File /tmp/dms/custom-certs/privkey.pem or /tmp/dms/custom-certs/fullchain.pem does not exist!

The .pem files in that folder are symlinks to the files in the archive/npm-43/ folder, so my first thought was to try those files directly, but I had the same issue. I also double-checked that the permissions were correct for the files, and they all seem to have the right permissions.

Maybe I'm missing something really obvious here? I'd also be up to ask NPM if they could make the change to the folder names on their end.

[polarathene]

I think it depends on how the symlink is defined (relative/absolute).

If you only mounted the sub-directory npm-43, then you'd likely have the problem we document with mounting advice for SSL_TYPE=letsencrypt with symlinks, you need to ensure the parent directories are also mounted so the relative symlink can be followed, otherwise how will we find the original?

---

my first thought was to try those files directly, but I had the same issue. I also double-checked that the permissions were correct for the files, and they all seem to have the right permissions.

Did you make sure the container was created again, not just restarted?

DMS will only run start-up scripts for a fresh container instance, not restarts of the same container. It's advised to do a fresh container when troubleshooting config issues.

SSL_TYPE=manual will then manually copy these two files to another location internally and configure that.

Do note that if you bind mount each file directly, it will be mounting the inode which has some caveats (any updates to the file on the host won't be sync'd / detected). Thus you should only bind mount directories (the inode bind is the same, but any changes to files associated to that directory will be noticed within the container).

Everything should work fine AFAIK, I've used the feature in the past and we have test suite coverage for this with our own test certificate we've created.

[RealHypnoticOcelot]

Sorry for the egregiously late response, but I figured it out! It's actually a lot simpler than I thought it'd be. So, first all you have to do is bind the Let's Encrypt directory Nginx Proxy Manager generates like so:

- /services/nginx-proxy-manager/letsencrypt:/etc/letsencrypt

I found out that you could actually set the folder it looks for by setting the environment variable SSL_DOMAIN(which isn't there by default) to the name of the folder, in my case npm-43:

SSL_DOMAIN="npm-43"

No other changes necessary!

[polarathene]

SSL_DOMAIN is not meant to be a public variable (the Traefik compose.yaml example in our docs does have it only because it's not been verified yet if it's still necessary for wildcard provisioned domains), you shouldn't be relying on internal details as they're subject to change.

So while SSL_DOMAIN appears to have been introduced specifically for Traefik's acme.json with wildcard certs support, you've identified another scenario where the provisioned cert doesn't quite align with the DMS FQDN and used SSL_DOMAIN as a workaround. SSL_DOMAIN is likely to removed fully in a future refactor and as it's not publicly documented in our ENV page, it is possible that could be done without a breaking change release.

I'm not familiar enough with NPM to know why it's provisioning differently with names such as npm-43 but that doesn't sound particularly stable, especially since you have those earlier npm-* folders there too. It'll likely be addressed with a future refactor to DMS cert support (which will help with Caddy as well).

---

You should follow my advice as I mentioned in March. I referenced these docs:

---

The FQDN isn't included in the folder name, and as far as I can tell that trips things up with DMS.

So you originally had this issue with SSL_TYPE=letsencrypt and switched to SSL_TYPE=manual which then had a different issue:

SSL_CERT_PATH=/tmp/dms/custom-certs/fullchain.pem
SSL_KEY_PATH=/tmp/dms/custom-certs/privkey.pem

What I did was mount /services/nginx-proxy-manager/letsencrypt/live/npm-43/ to /tmp/dms/custom-certs/ in the container
The .pem files in that folder are symlinks to the files in the archive/npm-43/ folder
Unfortunately, DMS is having some issues recognizing the files for one reason or another.

At which I pointed out the symlink concern with how LetsEncrypt is typically managed (which is the same layout you've shown earlier), and referenced the docs I linked and shared a screenshot snippet of above.

If you followed that advice then you would have instead mounted /services/nginx-proxy-manager/letsencrypt/ to /tmp/dms/custom-certs/ and then adjusted your SSL_CERT_PATH + SSL_KEY_PATH to the correct path.

SSL_TYPE=manual
SSL_CERT_PATH=/tmp/dms/custom-certs/live/npm-43/fullchain.pem
SSL_KEY_PATH=/tmp/dms/custom-certs/live/npm-43/privkey.pem

Where npm-43 is the folder name for the desired certificate with a domain name that isn't matching up with the DMS FQDN, as per your original issue.

With the changes I just communicated, this should allow you to properly use LetsEncrypt with SSL_TYPE=manual with the different domain directory you had, whilst mounting that whole letsencrypt folder for the symlinks to work as intended.

Use your current approach for now if you like, it's understandably simpler than the SSL_TYPE=manual config I explained. SSL_DOMAIN may get removed at a later date in which case you'd need to switch to what I've shown, unless a larger refactoring of cert support is done which may also make the above advice outdated too as making SSL_TYPE redundant is planned.

[RealHypnoticOcelot]

You know, I tried a lot of different variations of mounting the letsencrypt folder properly and setting the cert and key paths, and somehow I never landed on that! That sure is embarrassing! I'll stick with your solution, as it's less likely to be deprecated(at least as a non-breaking change); I'll also consider switching away from Nginx Proxy Manager towards something that exhibits more standard certificate behavior. Thank you so much for your time and patience!