[GH-ISSUE #1024] Default host certificate leaks implementation information in organization subject #859

Closed
opened 2026-02-26 06:34:43 +03:00 by kerem · 7 comments
Owner

Originally created by @qriff on GitHub (Apr 17, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1024

Describe the bug
The generated default self signed host certificate leaks implementation name "Nginx Proxy Manager" in the "Organizational" (O) subject field.

To Reproduce
Steps to reproduce the behavior:

  1. Browse to default https host
  2. Review certificate details

Expected behavior
Field should be generic (not reference implementation), like localhost or empty, or definable.

In \docker\rootfs\etc\services.d\nginx\run
`

Generate dummy self-signed certificate.

if [ ! -f /data/nginx/dummycert.pem ] || [ ! -f /data/nginx/dummykey.pem ]
then
echo "Generating dummy SSL certificate..."
openssl req
-new
-newkey rsa:2048
-days 3650
-nodes
-x509
-subj '/O=Nginx Proxy Manager/OU=Dummy Certificate/CN=localhost'
-keyout /data/nginx/dummykey.pem
-out /data/nginx/dummycert.pem
echo "Complete"
fi
`

Originally created by @qriff on GitHub (Apr 17, 2021). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1024 **Describe the bug** The generated default self signed host certificate leaks implementation name "Nginx Proxy Manager" in the "Organizational" (O) subject field. **To Reproduce** Steps to reproduce the behavior: 1. Browse to default https host 2. Review certificate details **Expected behavior** Field should be generic (not reference implementation), like localhost or empty, or definable. In \docker\rootfs\etc\services.d\nginx\run ` # Generate dummy self-signed certificate. if [ ! -f /data/nginx/dummycert.pem ] || [ ! -f /data/nginx/dummykey.pem ] then echo "Generating dummy SSL certificate..." openssl req \ -new \ -newkey rsa:2048 \ -days 3650 \ -nodes \ -x509 \ -subj '/O=Nginx Proxy Manager/OU=Dummy Certificate/CN=localhost' \ -keyout /data/nginx/dummykey.pem \ -out /data/nginx/dummycert.pem echo "Complete" fi `
kerem 2026-02-26 06:34:43 +03:00
  • closed this issue
  • added the
    stale
    bug
    labels
Author
Owner

@l4rm4nd commented on GitHub (Apr 17, 2021):

I mean it is called a dummy certificate for a reason. You can easily replace it with your own certificate.

Just replace /data/nginx/dummykey.pem and /data/nginx/dummycert.pem with your own SSL cert.

openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj '/O=localhost/OU=localhost/CN=localhost' -keyout /data/nginx/dummykey.pem -out /data/nginx/dummycert.pem
<!-- gh-comment-id:821867721 --> @l4rm4nd commented on GitHub (Apr 17, 2021): I mean it is called a dummy certificate for a reason. You can easily replace it with your own certificate. Just replace ``/data/nginx/dummykey.pem`` and ``/data/nginx/dummycert.pem`` with your own SSL cert. ```` openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj '/O=localhost/OU=localhost/CN=localhost' -keyout /data/nginx/dummykey.pem -out /data/nginx/dummycert.pem ````
Author
Owner

@bmbvenom commented on GitHub (Aug 22, 2021):

I mean it is called a dummy certificate for a reason. You can easily replace it with your own certificate.

Just replace /data/nginx/dummykey.pem and /data/nginx/dummycert.pem with your own SSL cert.

openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj '/O=localhost/OU=localhost/CN=localhost' -keyout /data/nginx/dummykey.pem -out /data/nginx/dummycert.pem

I don't disagree with you, it is easy enough to replace with a new dummy cert. However, considering that ssllabs.com (and I can only assume similar tools) picks up this dummy cert in their "No SNI" scan I agree with @qriff that this could expose potential attack vectors and it should be fixed. As such I've submitted PR #1338

<!-- gh-comment-id:903216808 --> @bmbvenom commented on GitHub (Aug 22, 2021): > > > I mean it is called a dummy certificate for a reason. You can easily replace it with your own certificate. > > Just replace `/data/nginx/dummykey.pem` and `/data/nginx/dummycert.pem` with your own SSL cert. > > ``` > openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj '/O=localhost/OU=localhost/CN=localhost' -keyout /data/nginx/dummykey.pem -out /data/nginx/dummycert.pem > ``` I don't disagree with you, it is easy enough to replace with a new dummy cert. However, considering that ssllabs.com (and I can only assume similar tools) picks up this dummy cert in their "No SNI" scan I agree with @qriff that this could expose potential attack vectors and it should be fixed. As such I've submitted PR #1338
Author
Owner

@jc21 commented on GitHub (Aug 22, 2021):

Agreed :)

<!-- gh-comment-id:903342287 --> @jc21 commented on GitHub (Aug 22, 2021): Agreed :)
Author
Owner

@jstrat31 commented on GitHub (Aug 8, 2023):

Hello all, Sorry to bring those old issue backup, but we're currently failing our pen test for this very thing. pen testers scan ip only and get the dummy localhost certs, which causes us to get a medium finding. Took me longer than it should have to realize its the dummycerts form Nginx Proxy Manager. sslchecker.com also flags it when entering our IP.
Is there anyway to have NPM just not advertise these certs? I've tried deleting them, but they still show when connecting, and when I delete them, they're recreated on next reboot.

Thanks!!

<!-- gh-comment-id:1670370302 --> @jstrat31 commented on GitHub (Aug 8, 2023): Hello all, Sorry to bring those old issue backup, but we're currently failing our pen test for this very thing. pen testers scan ip only and get the dummy localhost certs, which causes us to get a medium finding. Took me longer than it should have to realize its the dummycerts form Nginx Proxy Manager. sslchecker.com also flags it when entering our IP. Is there anyway to have NPM just not advertise these certs? I've tried deleting them, but they still show when connecting, and when I delete them, they're recreated on next reboot. Thanks!!
Author
Owner

@l4rm4nd commented on GitHub (Aug 10, 2023):

Hello all, Sorry to bring those old issue backup, but we're currently failing our pen test for this very thing. pen testers scan ip only and get the dummy localhost certs, which causes us to get a medium finding. Took me longer than it should have to realize its the dummycerts form Nginx Proxy Manager. sslchecker.com also flags it when entering our IP. Is there anyway to have NPM just not advertise these certs? I've tried deleting them, but they still show when connecting, and when I delete them, they're recreated on next reboot.

Thanks!!

Use internal risk management and lower the severity to informational.

Pentesters will just report anything they find and apply a risk rating. It's your job too, to also assess the risk. As outlined, there is no risk by using a self-signed certificate for the NPM network service reachable by IP. It's a reverse proxy, which proxies hostnames / subdomains. Therefore, accessing the IP directly is not the key aspect of the product and neglectable.

In the end, it's still a proper SSL certificate. It's just self-signed and therefore not in the regular root trust stores of end devices and browsers, which will lead to warning messages. As for any internal PKI, you can just put the cert into all trust stores of your clients and it will be trusted. Applying a medium risk rating due to self-signed certificates is kinda harsh. May talk to the pentesters and challenge them. Ask for a recommendation on how to resolve properly. They will likely just lower the risk.

Cheers from a pentester

<!-- gh-comment-id:1672877889 --> @l4rm4nd commented on GitHub (Aug 10, 2023): > Hello all, Sorry to bring those old issue backup, but we're currently failing our pen test for this very thing. pen testers scan ip only and get the dummy localhost certs, which causes us to get a medium finding. Took me longer than it should have to realize its the dummycerts form Nginx Proxy Manager. sslchecker.com also flags it when entering our IP. Is there anyway to have NPM just not advertise these certs? I've tried deleting them, but they still show when connecting, and when I delete them, they're recreated on next reboot. > > Thanks!! Use internal risk management and lower the severity to informational. Pentesters will just report anything they find and apply a risk rating. It's your job too, to also assess the risk. As outlined, there is no risk by using a self-signed certificate for the NPM network service reachable by IP. It's a reverse proxy, which proxies hostnames / subdomains. Therefore, accessing the IP directly is not the key aspect of the product and neglectable. In the end, it's still a proper SSL certificate. It's just self-signed and therefore not in the regular root trust stores of end devices and browsers, which will lead to warning messages. As for any internal PKI, you can just put the cert into all trust stores of your clients and it will be trusted. Applying a medium risk rating due to self-signed certificates is kinda harsh. May talk to the pentesters and challenge them. Ask for a recommendation on how to resolve properly. They will likely just lower the risk. Cheers from a pentester
Author
Owner

@github-actions[bot] commented on GitHub (Mar 13, 2024):

Issue is now considered stale. If you want to keep it open, please comment 👍

<!-- gh-comment-id:1993072631 --> @github-actions[bot] commented on GitHub (Mar 13, 2024): Issue is now considered stale. If you want to keep it open, please comment :+1:
Author
Owner

@qriff commented on GitHub (Mar 14, 2024):

Seems fixed in merge for #1338

<!-- gh-comment-id:1996625250 --> @qriff commented on GitHub (Mar 14, 2024): Seems fixed in merge for #1338
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/nginx-proxy-manager-NginxProxyManager#859
No description provided.