Skip to content

letsencrypt updates: renew location for .well-known, add support for multiple hostnames #992

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Aug 19, 2025
Merged

letsencrypt updates: renew location for .well-known, add support for multiple hostnames #992

Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
06a522c
FEATURE: add DISCOURSE_HOSTNAME_ALIASES
featheredtoast Aug 2, 2025
b519bf1
remove unnecessary line
featheredtoast Aug 3, 2025
b865ad0
format function
featheredtoast Aug 3, 2025
0832bf8
remove commented multi_accept line
featheredtoast Aug 19, 2025
4d2a524
Implement feedback
featheredtoast Aug 19, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 27 additions & 2 deletions templates/web.letsencrypt.ssl.template.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,20 @@ run:
LE_WORKING_DIR="${LETSENCRYPT_DIR}" ./acme.sh --upgrade --auto-upgrade
LE_WORKING_DIR="${LETSENCRYPT_DIR}" ./acme.sh --set-default-ca --server letsencrypt

cat << EOF > /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In, for example, samples/web_only.yml, we tell operators to uncomment both web.ssl.template.yml and web.letsencrypt.ssl.template.yml.

However, the configure-letsencrypt and configure-ssl scripts are writing to the same outlet. So future changes to the latter are going to be mysteriously overwritten by the former.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair point - perhaps something simple we could do is bundle the /.well-known passthrough location into the base ssl template? It's not a path used by Discourse anywhere, and maybe it's... well known... enough that it's OK to have in the base ssl template.

server {
listen 80;

location ~ /.well-known {
root /var/www/discourse/public;
allow all;
}
location / {
return 301 https://${DISCOURSE_HOSTNAME}$request_uri;
}
}
EOF

cat << EOF > /etc/nginx/letsencrypt.conf
user www-data;
worker_processes auto;
Expand All @@ -41,7 +55,6 @@ run:

server {
listen 80;
listen [::]:80;

location ~ /.well-known {
root /var/www/discourse/public;
Expand All @@ -51,6 +64,11 @@ run:
}
EOF

if [ -f "/proc/net/if_inet6" ] ; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this file exist if IPv6 is enabled but no interfaces have v6 addresses?

We want to listen on :: even if there are current addresses, in case one appears in the future.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll admit this was a somewhat blind attempt at mimicking what the web_ssl does here:

discourse_docker/templates/web.ssl.template.yml

Lines 62 to 65 in e957176

if [ -f "/proc/net/if_inet6" ] ; then
sed -i 's/listen 80;/listen 80;\nlisten [::]:80;/g' /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf
sed -i 's/listen 443 ssl;/listen 443 ssl;\nlisten [::]:443 ssl;/g' /etc/nginx/conf.d/outlets/server/20-https.conf
fi

But if this isn't necessary, perhaps we can remove the references in both places and simplify everywhere

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't actually know what the behavior is when IPv6 is enabled but not configured anywhere. Maybe that if test is OK?

If listen [::]:80 does not error when IPv6 is not available that sure looks like the cleanest option. I'll try and figure out a test.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Survey says "yes". The default install on Debian has listen [::]:80 default_server; Running echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6 turned off IPv6. The service still starts fine afterwards.

sed -i 's/listen 80;/listen 80;\nlisten [::]:80;/g' /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf
sed -i 's/listen 80;/listen 80;\nlisten [::]:80;/g' /etc/nginx/letsencrypt.conf
fi

sed -Ei "s/^#?ACCOUNT_EMAIL=.+/ACCOUNT_EMAIL=${LETSENCRYPT_ACCOUNT_EMAIL}/" \
/shared/letsencrypt/account.conf

Expand All @@ -71,8 +89,15 @@ run:
LETSENCRYPT_DIR="/shared/letsencrypt"
/usr/sbin/nginx -c /etc/nginx/letsencrypt.conf

extra_domains() {
if [ -n "$DISCOURSE_HOSTNAME_ALIASES" ]; then
domains=$(echo $DISCOURSE_HOSTNAME_ALIASES | sed "s/,/ -d /g")
echo "-d $domains"
fi
}

issue_cert() {
LE_WORKING_DIR="${LETSENCRYPT_DIR}" ${LETSENCRYPT_DIR}/acme.sh --issue $2 -d ${DISCOURSE_HOSTNAME} --keylength $1 -w /var/www/discourse/public
LE_WORKING_DIR="${LETSENCRYPT_DIR}" ${LETSENCRYPT_DIR}/acme.sh --issue $2 -d ${DISCOURSE_HOSTNAME} $(extra_domains) --keylength $1 -w /var/www/discourse/public
}

cert_exists() {
Expand Down