From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Sassmannshausen Subject: bug#36389: nginx/certbot interaction doesn't work as documented Date: Wed, 26 Jun 2019 10:31:57 +0100 Message-ID: <875zos3d6a.fsf@gmail.com> References: <249AC56B-BE05-4162-B65D-618490163CB0@vllmrt.net> Reply-To: alex.sassmannshausen@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:35406) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hg4IZ-0002El-LM for bug-guix@gnu.org; Wed, 26 Jun 2019 05:33:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hg4IY-0001ag-DA for bug-guix@gnu.org; Wed, 26 Jun 2019 05:33:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:48947) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hg4IX-0001Zg-TF for bug-guix@gnu.org; Wed, 26 Jun 2019 05:33:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hg4IX-0000sH-Os for bug-guix@gnu.org; Wed, 26 Jun 2019 05:33:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Received: from eggs.gnu.org ([2001:470:142:3::10]:35104) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hg4He-0001ze-Gx for bug-guix@gnu.org; Wed, 26 Jun 2019 05:32:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hg4Hd-0000Eg-9K for bug-guix@gnu.org; Wed, 26 Jun 2019 05:32:06 -0400 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:37322) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hg4Hd-0000Cv-2r for bug-guix@gnu.org; Wed, 26 Jun 2019 05:32:05 -0400 Received: by mail-wr1-x42d.google.com with SMTP id v14so1885279wrr.4 for ; Wed, 26 Jun 2019 02:32:04 -0700 (PDT) In-reply-to: <249AC56B-BE05-4162-B65D-618490163CB0@vllmrt.net> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 36389@debbugs.gnu.org Hi Robert, Robert Vollmert writes: > I=E2=80=99ve tried setting up nginx with certbot on guix. Two immediate i= ssues: > > - certbot extends the nginx service to serve challenge files. It appears > that this nginx service extension conflicts (silently) with an independ= ently > configured nginx service. I.e., I had nginx previously configured, and > after adding certbot, my previous nginx kept running with the previous > configuration (even after herd restart nginx), while there was an addit= ional > nginx config in the gnu store with the certbot-specific fragments. cert= bot > activation called nginx to test that fragment, but apparently never sta= rted > nginx (successfully?). There were no errors. > > After removing the stand-alone nginx service and restarting nginx, it s= tarted > with the certbot configuration. This sounds odd, and I don't recall having this issue on my servers with nginx SSL server configuration extended with certbot service. > > - After this, /var/lib/certbot/renew worked successfully to register a > certificate, but then failed when calling the nginx deploy hook that I= =E2=80=99d > copied from the guix certbot documentation, because /var/run/nginx/pid > doesn=E2=80=99t exist. That might be a bug in the nginx package, not su= re. I can=E2=80=99t > find an nginx pid file anywhere, and no other errors related to it eith= er, > even though the config file includes > pid /var/run/nginx/pid; The pid exists on my servers running an SSL nginx server config configuration extended with certbot. I've found the certbot & nginx services, overall, work very well together. But there are a couple of gotchas in my experience: - The certbot service includes a redirect from port 80 to 443 for all except .well-known location. By itself this may cause no problems for you. - If deploying on a server that hitherto has no SSL certificate you have a chicken and egg problem: you will want your site to be configured to use the letsencrypt cert directories, to serve ssl (the redirect means any non-ssl deployments won't work anyway), but those directories don't yet exist as you haven't generated certs with certbot yet. Here's a journey that should work: - run system configuration with just the certbot service - use certbot to generate your initial certificates - reconfigure with additional nginx server configuration, pointing to the SSL certificates created by certbot If the above is not helpful, perhaps you could share the nginx configuration generated when you have both certbot & your custom server running? Can't promise anything, but we might be able to spot what's happening. Best wishes, Alex