From: MSavoritias <email@msavoritias.me>
To: Jack Hill <jackhill@jackhill.us>
Cc: help-guix@gnu.org
Subject: Re: Dependency cycle between certbot and nginx is not obvious.
Date: Tue, 7 May 2024 11:34:22 +0300 [thread overview]
Message-ID: <7308a298-4c0f-8803-9410-54e97fbbda1f@fannys.me> (raw)
In-Reply-To: <233b3255-1a47-06a9-6507-87bf00ba95bd@jackhill.us>
Another issue I just encountered seems to be that certbot domains and
nginx server names conflict and can't be the same if you just declare
them as strings.
Specifically the config becomes this:
user nginx nginx;
pid /var/run/nginx/pid;
error_log /var/log/nginx/error.log error;
events { }
http {
client_body_temp_path /var/run/nginx/client_body_temp;
proxy_temp_path /var/run/nginx/proxy_temp;
fastcgi_temp_path /var/run/nginx/fastcgi_temp;
uwsgi_temp_path /var/run/nginx/uwsgi_temp;
scgi_temp_path /var/run/nginx/scgi_temp;
access_log /var/log/nginx/access.log;
include
/gnu/store/fz71kvlyhzg6rq0whxr11xbxzfb18igi-nginx-1.23.3/share/nginx/conf/mime.types;
server {
listen 80;
listen 443 ssl;
server_name www.joinjabber.org joinxmpp.org www.joinxmpp.org ;
ssl_certificate /etc/letsencrypt/live/joinjabber.org/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/joinjabber.org/privkey.pem;
root /srv/http;
index index.html ;
server_tokens off;
location /support {
return 302 "https://chat.joinjabber.org/#/guest?join=support";
}
return 301 https://joinjabber.org$request_uri;
}
server {
listen 80;
listen [::]:80;
server_name joinjabber.org www.joinjabber.org joinxmpp.org
www.joinxmpp.org ;
root /srv/http;
index index.html ;
server_tokens off;
location /.well-known {
root /var/www;
}
location / {
return 301 https://$host$request_uri;
}
}
}
With certbot adding the second server block. I am going to open a bug
report for all of this. so we can track it.
MSavoritias
On 5/3/24 18:43, Jack Hill wrote:
> On Fri, 3 May 2024, MSavoritias wrote:
>
>> Hey,
>>
>>
>> I spent the better part of the day today trying to debug an error
>> that was happening while deploying a server with two server names in
>> the nginx field.
>>
>> My config was:
>>
>> (service certbot-service-type
>> (certbot-configuration
>> (certificates
>> (list
>> (certificate-configuration
>> ;; The first domain provided will be the subject CN of the
>> certificate, and all domains will be Subject Alternative Names on the
>> certificate.
>> (domains '("joinxmpp.org" "www.joinxmpp.org")))))))
>> (service nginx-service-type
>> (nginx-configuration
>> (server-blocks
>> (list (nginx-server-configuration
>> (server-name '("joinxmpp.org www.joinxmpp.org"))
>> (ssl-certificate "/etc/certs/joinxmpp.org/fullchain.pem")
>> (ssl-certificate-key
>> "/etc/certs/joinxmpp.org/privkey.pem")
>> (locations
>> (list
>> (nginx-location-configuration
>> (uri "/support")
>> (body '("return 302
>> \"https://chat.joinjabber.org/#/guest?join=support\";")))))))))))
>>
>>
>> turns out that this cant be deployed at once on the server. although
>> it is correct. The reason is that certbot/letsencrypt will complain
>> with the message:
>>
>> Hint: The Certificate Authority failed to download the temporary
>> challenge files created by Certbot. Ensure that the listed domains
>> serve their content from the provided --webroot-path/-w and that
>> files created there can be downloaded from the internet.
>>
>>
>> Mind you this error appeared on only one of the domains not both.
>>
>> This was solved by running the system once with certbot. Then
>> rebooting with the nginx service. That idea appear to me after i
>> found a mailing list thread from 5 years ago saying that there is a
>> dependency cycle between nginx and certbot and they cant run at the
>> same time the first time.
>>
>>
>> The reason I am sending an email is because I am not sure if this is
>> something that could be fixed somehow, or if this is unavoidable and
>> i should just send a patch revising the docs slightly to suggest that
>> if an nginx service is used with multiple domains in the server name,
>> you should start the system once with certbot and then reboot with
>> nginx.
>
> Hi,
>
> Indeed, this has been an annoyance. However, if I understand your
> problem correctly, I'm happy to report that it has now been fixed [0]!
> The start-self-signed? filed in certificate-configuration [1] should
> allow nginx to start before certbot has had a chance to get a proper
> cert signed by providing a structurally valid one for nginx to use.
> From the documentation:
>
>> start-self-signed? (default: #t)
>> Whether to generate an initial self-signed certificate during system
>> activation. This option is particularly useful to allow nginx to start
>> before certbot has run, because certbot relies on nginx running to
>> perform
>> HTTP challenges.
>
> However, that says that the default is #t, but it still doesn't work
> for you. I wonder what I'm missing.
>
> Best,
> Jack
>
> [0] https://issues.guix.gnu.org/46961#1
> [1]
> https://guix.gnu.org/en/manual/devel/en/html_node/Certificate-Services.html
prev parent reply other threads:[~2024-05-07 8:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 15:30 Dependency cycle between certbot and nginx is not obvious MSavoritias
2024-05-03 15:43 ` Jack Hill
2024-05-07 8:34 ` MSavoritias [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7308a298-4c0f-8803-9410-54e97fbbda1f@fannys.me \
--to=email@msavoritias.me \
--cc=help-guix@gnu.org \
--cc=jackhill@jackhill.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).