mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-25 01:15:51 +03:00
[GH-ISSUE #865] Share ssl certificate between two containers #735
Labels
No labels
awaiting feedback
bug
cannot reproduce
dns provider request
duplicate
enhancement
enhancement
enhancement
good first issue
help wanted
invalid
need more info
no certbot plugin available
product-support
pull-request
question
stale
troll
upstream issue
v2
v2
v2
v3
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nginx-proxy-manager-NginxProxyManager#735
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @andycandy-de on GitHub (Feb 3, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/865
Hello,
is it possible to share ssl certificates between two npm containers? That would be nice. I want to setup a local npm (private network) and a public npm(connected with the internet). I set up a pihole, so I can link some subdomains directly to the local npm. The host configuration must be detached but the ssl validation must be done with the public npm. So it would be a great feature to share the certificates between two containers.
@theRAGEhero commented on GitHub (Feb 8, 2021):
isn't possible right now? I've always seen the possibily to select the certificate that you want. Or maybe I'm wrong?
@andycandy-de commented on GitHub (Feb 9, 2021):
I shared the folder including the ssl certificate with both containers, but just the one who created the certificates knows them. The other container don't show the certificates. Neither in the "SSL Certificates" view nor in the "New Proxy Host" dialog. What's wrong?
@lieven121 commented on GitHub (Feb 11, 2021):
This is because the certificates aren't looked up trough the files they are stored in the database and there is a ref to where they should be.
This would be more a feature request if you would want that functionality.
@andycandy-de commented on GitHub (Feb 11, 2021):
Thank you for the response. I think this would be a nice feature. Can I move this issue to a feature request?
@SteveGBuck commented on GitHub (Mar 17, 2021):
Is it not suitable to just have one container exposed to the Internet and use access lists to restrict the sites you want to keep internal?
@andycandy-de commented on GitHub (Mar 18, 2021):
@SteveGBuck thank you for your response. I thought about this solution, but I don't want to setup the Services this way. The reason is simple. I just want some services public and some services local. To use the access lists exposes the local services to the internet with a protection layer. But this is in my opinion also an unnecessary security issue. So I just want to access my local services with a non-public NPM. But It would be nice to get the certificates from the public NPM.
@SteveGBuck commented on GitHub (Mar 18, 2021):
@andycandy-de Understood, I have this same fear as it does feel risky that the only separation between your internal services and external ones are a rule to determine which subnet the request has come from (though I guess isn't that really fundamentally what a firewall does anyway?).
I do try to mitigate some risk by only having the web server of my application containers in the same docker network as NPM. I try to keep all the application and database containers in their own seperate application default docker network. I also run a threat prevention application on my router for added protection. But I'm no security expert and I'm sure there's other measures I should consider.
@andycandy-de commented on GitHub (Mar 22, 2021):
@SteveGBuck yes, of course just the public services should be accessable for the NPM. The required back end services should just be accessable for the public service and not for the NPM. That's also how I configured my setup.
I don't understand how do you want to protect the Services with a subnet rule. Can you explain that to me?
@SteveGBuck commented on GitHub (Mar 22, 2021):
@andycandy-de All I mean is that if you navigate to "Access Lists" in the top menu of NPM. Create a new access list that has only your internal subnet for your internal network. Then you can set this access list rule to you hosts you want to keep internal only. Then if you try to access this site from outside your network you will get 403 forbidden message.
@sovanyio commented on GitHub (Mar 24, 2021):
Came here to say that something like this would be useful for existing letsencrypt configs.
I currently have a wildcard cert set for my local domain that is setup with a DNS challenge that I would rather have the host system continue to manage.
Replicating my proxy configuration without being able to use this existing certificate is currently blocking my adoption of the project. I know that this is my problem and not the project's but it would be nice if ssl certs were portable for myself and not treated like docker containers ;).
Maybe something at the start of the container that looks at what is available under the directory and creates the db entries.. I might look at this myself
@JakobTewes commented on GitHub (Jan 28, 2022):
@andycandy-de, I´m interested in the "expose certificates to filesystem", too.
From my perspective this totally makes sense, as there is more than "just http" needing ssl encapsulation such as mqtt.
@shodanx2 commented on GitHub (Sep 6, 2022):
Hi,
This discussion seems to have stalled.
Here is a clear use case where this is needed.
I am running nginx proxy manager in a docker container and I also run a docker-mailserver container.
The docker-mailserver container needs SSL certifications for SSL/TLS but I don't want it to handle it's own separate set of certificates, I want it to use the ones managed by NPM.
After a freshly installed NPM you will find the following certificate files in your installation directory
And while I'm having other problem so I can't test this (*)
but, I suspect that because the path are "NPM-1" instead of the actual name of the certification, the mailserver will not find the certificates on its own, they will need to be copied from "NPM-1" to "example.com" and once you do that, they will no longer be updated by the NPM container.
Although i will attempt to just create symlinks
And then a symlink from the NPM folder to the docker-mailserver folder
Unfortunately, that does not work
Ok change of plans, I will edit the docker-compose.yml
And as far as I can tell this works !!
Ok, so as far as this issue is concerned here is my recommendation
I don't know why NPM calls it's live certification folder NPM-1 NPM-2 and so on
However I would suggest automatic create of symlink to the appropriate domain names
so ln -s letsencrypt/live/NPM-1 letsencrypt/live/example.com
@Jarsky commented on GitHub (Jan 13, 2023):
To add to your comment @shodanx2, Certbot has a function called renewal-hooks which you can read about here:
https://eff-certbot.readthedocs.io/en/stable/using.html#pre-and-post-validation-hooks
This allows you to create validation scripts for pre and post using bash.
There is also a hook called 'deploy' which will run after the new certificate has been generated.
With NPM docker, as part of creating the docker you would map the /data folder.
You can also map to the letsencrypt folder. So if you're using docker-compose it might look something like this:
So the location of the deploy renewal-hooks would be located in the below path in this example:
/opt/nginx-proxy-manager/letsencrypt/renewal-hooks/deployYou can create a bash file e.g 'mailserver.sh' and make it executable (e.g chmod +x mailserver.sh)
Then use bash to define what you want to do during deploy. Heres an example of what it could look like.
So in this example, during the deploy of the certificate
You can create another pem file for npm-2, and another for npm-3 etc.....
You can then access the certs from any container through
/opt/nginx-proxy-manager/data/certsAlternatively if you dont have letsencrypt on your host, you could make the directory and symlink it to use the default location in your apps/containers:
EDIT: OK so it seems the global variable $RENEWED_LINEAGE isnt working in NPM....
Might be related to the other issues with SSL Certificates....you can still use the above, but have to comment out the $RENEWED_LINEAGE check, which means it will run with every certificate renewal in NPM rather than the specific one youre targetting
@JakobTewes commented on GitHub (Jan 13, 2023):
Thanks for sharing that @Jarsky and @shodanx2!
Personally I’d love, having a beautiful integrated solution (with web representation) for this, as I see it as a high value feature.
kr
Jakob
@shodanx2 commented on GitHub (Jan 14, 2023):
Thank you for the explanation, I will put this into practise the next time I setup one of those servers and will report what I learned here.
@github-actions[bot] commented on GitHub (Mar 20, 2024):
Issue is now considered stale. If you want to keep it open, please comment 👍
@JakobTewes commented on GitHub (Mar 20, 2024):
Plz keep this open 👌
@wakawakaaa commented on GitHub (May 25, 2024):
In this case best approach would be to just provide path to tls certificates in docker-compose.yml file, which is done like traefik does it.
tls:
certificates:
- certFile: /path/to/domain.cert
keyFile: /path/to/domain.key
stores:
- default
So, nginx-proxy-manager will use this certificate as a default and one in the list of ssl certificate can be selected.
Please have this feature implemented. thanks
@vincent1890 commented on GitHub (Aug 28, 2024):
up
@SpongeManiac commented on GitHub (Apr 2, 2025):
It's a shame this still hasn't been addressed. I am attempting to run GitLab behind NGINX Proxy Manager, and the container registry requires access to the SSL certificates, which are not easily accessed.
@github-actions[bot] commented on GitHub (Oct 16, 2025):
Issue is now considered stale. If you want to keep it open, please comment 👍
@JakobTewes commented on GitHub (Oct 16, 2025):
ouch…still a nice feature