starred/nginx-proxy-manager-NginxProxyManager

Fork 0

mirror of https://github.com/NginxProxyManager/nginx-proxy-manager.git synced 2026-04-25 17:35:52 +03:00

[GH-ISSUE #467] Default host does not include letsencrypt config #393

New issue

Closed

opened 2026-02-26 06:32:40 +03:00 by kerem · 4 comments

kerem commented

2026-02-26 06:32:40 +03:00

Owner

Originally created by @joshbenner on GitHub (Jun 20, 2020).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/467

The default site at /data/nginx/default_host/site.conf does not include the Let's Encrypt configuration at /etc/nginx/conf.d/include/letsencrypt-acme-challenge.conf.

The impact of this is that any Let's Encrypt certificate acquisition that would go to the default site cannot succeed. This means only hostnames with active hosts attached can create or renew certificates with Let's Encrypt.

Failure Example 1:

Create a new SSL cert with a hostname that is NOT in use on any hosts
Cert acquisition will fail

Failure Example 2:

Create a new SSL cert with one hostname that IS associated with a working host config, and a hostname that is NOT in use on any host.
Cert acquisition will fail

Success Example:

Create a new SSL cert with one hostname that IS associated with a working host config
Cert acquisition will succeed

The external Let's Encrypt service will attempt to make the challenge HTTP request to each of the domains in the certificate, and if any fail, the certificate is not issued. Those domains in the cert which are not associated with an active host config will fail, and so will the cert.

I suspect this may be related to difficult-to-reproduce errors such as #396 or #250, but it's pretty difficult to be sure.

I'm positive this was not always the case, as I was previously able to request an SSL cert from Let's Encrypt before I had setup the host config. I was also able to include additional hostnames in the Let's Encrypt certs that I was not yet using. Both of these approaches no longer work due to the issue described.

I suspect the fix is as easy as adding this to the default_host site.conf:

include conf.d/include/letsencrypt-acme-challenge.conf;

Originally created by @joshbenner on GitHub (Jun 20, 2020). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/467 The default site at `/data/nginx/default_host/site.conf` does not include the Let's Encrypt configuration at `/etc/nginx/conf.d/include/letsencrypt-acme-challenge.conf`. The impact of this is that any Let's Encrypt certificate acquisition that would go to the default site cannot succeed. This means only hostnames with active hosts attached can create or renew certificates with Let's Encrypt. Failure Example 1: 1. Create a new SSL cert with a hostname that is NOT in use on any hosts 2. Cert acquisition will fail Failure Example 2: 1. Create a new SSL cert with one hostname that IS associated with a working host config, and a hostname that is NOT in use on any host. 2. Cert acquisition will fail Success Example: 1. Create a new SSL cert with one hostname that IS associated with a working host config 2. Cert acquisition will succeed The external Let's Encrypt service will attempt to make the challenge HTTP request to each of the domains in the certificate, and if any fail, the certificate is not issued. Those domains in the cert which are not associated with an active host config will fail, and so will the cert. I suspect this may be related to difficult-to-reproduce errors such as #396 or #250, but it's pretty difficult to be sure. I'm positive this was not always the case, as I was previously able to request an SSL cert from Let's Encrypt before I had setup the host config. I was also able to include additional hostnames in the Let's Encrypt certs that I was not yet using. Both of these approaches no longer work due to the issue described. I suspect the fix is as easy as adding this to the default_host site.conf: ``` include conf.d/include/letsencrypt-acme-challenge.conf; ```

kerem

2026-02-26 06:32:40 +03:00

closed this issue
added the
stale

bug
labels

kerem commented

2026-02-26 06:32:41 +03:00

Author

Owner

@joshbenner commented on GitHub (Jun 20, 2020):

FWIW, it looks like 404 hosts also do not include it.

@joshbenner commented on GitHub (Jun 20, 2020): FWIW, it looks like 404 hosts also do not include it.

kerem commented

2026-02-26 06:32:41 +03:00

Author

Owner

@fbhdk commented on GitHub (Jun 21, 2020):

I am seeing this as well after finding out that a bunch of certs were expired

@fbhdk commented on GitHub (Jun 21, 2020): I am seeing this as well after finding out that a bunch of certs were expired

kerem commented

2026-02-26 06:32:41 +03:00

Author

Owner

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

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

@github-actions[bot] commented on GitHub (Mar 28, 2024): Issue is now considered stale. If you want to keep it open, please comment :+1:

kerem commented

2026-02-26 06:32:41 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (May 8, 2025):

Issue was closed due to inactivity.

@github-actions[bot] commented on GitHub (May 8, 2025): Issue was closed due to inactivity.

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#393

No description provided.

Rows
Columns