cloudpanel-io/cloudpanel-ce

.well-known directory deleted after certificate renew

Closed this issue · 6 comments

CloudPanel version(s) affected

2.2.0
2.4.0
2.4.2

Description

.well-known directory is deleted from virtual hosts after certificate renew. This folder is used for several services as standard path, so a workaround is not the proper solution for that, it's not only used to issue certificates.
As example, there's a list of services that uses this folder as standard path:

  • BIMI (Brand Indicators for Message Identification)
  • LNURLp (Lightning Network payment)
  • Nostr (Domain validation for Nostr Network)
  • PKI Validation (default path used by some certification authorities)
  • security.txt (Security information proposed standard for websites)
  • Android/iOS Deep Links (App standard path for mobile deep link applications)

In some cases, CORS rules is also required, what makes rewrite paths more difficult

It's also well documented in IANA several usages for this folder: https://www.iana.org/assignments/well-known-uris/

Please fix this 😟 look Possible Solution section below.

How to reproduce

Store anything on .well-known folder
Renew certificate
.well-known folder is gone

Possible Solution

Let's Encrypt only uses the path .well-known/acme-challenge, so please just delete acme-challenge subfolder.

Additional Context

No response

Workaround this for now putting my .well-known on .persistent, changed the rules as below:

For reverse proxy:

  location ^~ /.well-known {
    auth_basic off;
    allow all;
    ### BEGIN fixing .well-known deletion
    try_files $uri $uri/ /.persistent$uri @reverse_proxy;
    # try_files $uri @reverse_proxy; #old record
    ### END fixing .well-known deletion
  }

For any other kind of sites:

  location ~ /.well-known {
    auth_basic off;
    allow all;
    ### BEGIN fixing .well-known deletion
    try_files $uri $uri/ /.persistent$uri =404;
    ### END fixing .well-known deletion
  }

For URLs with CORS required, I made this BEFORE /.well-know rule (the location line need to be updated to allow the files you want to):

  ### BEGIN Enabling Nostr domain validation and Lightning Address
  location ~.well-known/(nostr.json|lnurlp/*) {
    ### BEGIN fixing .well-known deletion
    try_files $uri $uri/ /.persistent$uri =404;
    ### END fixing .well-known deletion
    add_header Content-Type application/json;
    add_header Access-Control-Allow-Origin *;
  }
  ### END Enabling Nostr domain validation and Lightning Address

No answer...

This issue isn't the highest priority; you already have found a workaround for this.

Be a little bit patient as it is free software we are providing.

Plus one for this, just came across the same issue when trying to setup mta-sts. I'll use the workaround for now. Thanks @ivancarlosti !

Finally it is assigned as bug, yey o/

Thank you for reporting the issue.

We've fixed it in our dev branch, and it will be included in the upcoming version v2.5.0, scheduled for release at the end of November 2024.