The default nginx config prevents LE from successfully generating a certificate if a manually uploaded certificate is installed #309

New Issue

MrUnknownDE · 2026-04-05T20:26:43+02:00

MrUnknownDE commented

2026-04-05 20:26:43 +02:00

Originally created by @brunophilipe on 12/8/2023

CloudPanel version(s) affected

2.4.0

Description

The default nginx config redirects all requests to https://www.*, which is a problem when the installed cert doesn't have the www prefix setup as an alias.

I was attempting to redirect traffic from an old server into one managed by CloudPanel, and for that to work I had to first install the existing cert from the old server, redirect DNS traffic, and only then submit a Let's Encrypt request.

However all LE requests would fail validation with a challenge mismatch. I attempted several times until I hit a rate limit.

While waiting for the rate limit, I found this thread on the Let's Encrypt forum, which clarified this problem. Once I rectified my config file to not redirect any .well-known requests (and after waiting for the rate limit time to elapse), my cert creation request succeeded.

How to reproduce

Create a new website
Upload a certificate issued on a different machine that doesn't include the www. prefix as an alias
Attempt to generate a Let's Encrypt cert
Request fails with challenge mismatch

Possible Solution

Change the default nginx config to never redirect .well-known requests to either HTTPS or to www.:

server {
  listen 80;
  listen [::]:80;
  server_name example.com www.example.com;
  {{root}}
  
  #skip challenge requests and send all other requests to HTTPS
  location ^/(?!\.well-known) {
    return 301 https://$host$request_uri;
  }
  
  auth_basic off;
  allow all;
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  {{ssl_certificate_key}}
  {{ssl_certificate}}
  server_name example.com www.example.com;
  {{root}}

  {{nginx_access_log}}
  {{nginx_error_log}}

  location ~* /.well-known {
    auth_basic off;
    allow all;
  }

  if ($scheme != "https") {
    rewrite ^ https://$host$uri permanent;
  }

…

Additional Context

As far as I can tell, Let's Encrypt does not cache DNS requests, so this doesn't seem to be a propagation mismatch.

*Originally created by @brunophilipe on 12/8/2023* ### CloudPanel version(s) affected 2.4.0 ### Description The default nginx config redirects *all* requests to `https://www.*`, which is a problem when the installed cert doesn't have the www prefix setup as an alias. I was attempting to redirect traffic from an old server into one managed by CloudPanel, and for that to work I had to first install the existing cert from the old server, redirect DNS traffic, and only then submit a Let's Encrypt request. However all LE requests would fail validation with a challenge mismatch. I attempted several times until I hit a rate limit. While waiting for the rate limit, I found [this thread](https://community.letsencrypt.org/t/404-error-issuance-to-cloudpanel-domain/136544/14) on the Let's Encrypt forum, which clarified this problem. Once I rectified my config file to *not* redirect any `.well-known` requests (and after waiting for the rate limit time to elapse), my cert creation request succeeded. ### How to reproduce 1. Create a new website 2. Upload a certificate issued on a different machine that doesn't include the `www.` prefix as an alias 3. Attempt to generate a Let's Encrypt cert 4. Request fails with challenge mismatch ### Possible Solution Change the default nginx config to never redirect `.well-known` requests to either HTTPS or to `www.`: ``` server { listen 80; listen [::]:80; server_name example.com www.example.com; {{root}} #skip challenge requests and send all other requests to HTTPS location ^/(?!\.well-known) { return 301 https://$host$request_uri; } auth_basic off; allow all; } server { listen 443 ssl http2; listen [::]:443 ssl http2; {{ssl_certificate_key}} {{ssl_certificate}} server_name example.com www.example.com; {{root}} {{nginx_access_log}} {{nginx_error_log}} location ~* /.well-known { auth_basic off; allow all; } if ($scheme != "https") { rewrite ^ https://$host$uri permanent; } … ``` ### Additional Context As far as I can tell, Let's Encrypt does not cache DNS requests, so this doesn't seem to be a propagation mismatch.

MrUnknownDE closed this issue

2026-04-05 20:26:43 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/cloudpanel-ce#309