Chicken or the Egg initial config for nginx+certbot docker as non root

certbot's flexibility is another matter. Personally, I think giving people instructions on how to modify their configurations would frequently be safer than trying to do it for them.

But Certbot's autoconf adds improvements (protocol-related options) that I woudn't add. And whenever the container is restarted with a new image, will maybe add some new security update to nginx directives.
Maybe I would follow install instruction with security options at first time, but I certainly won't check what's new at next update.
Instead of, if cerbot do it for me, that's just great! :slight_smile:

1 Like

Have you tried

server {
    server_name mydomain.com;
    listen 8000;
...
 }

If that doesn't work, using the dummy listen 8444; directive looks to be the right approach to me, and I would just block/not-publish the 8444 port on docker or the firewall.

You're basically dealing with an edge case around the implementation details of certbot's design, and trying to get the benefit of two incompatible systems by invoking certbot in a way that not really anybody uses.

Certbot is designed to either:

  • Upgrade HTTP to HTTPS, or
  • Update your HTTPS Certificates
  1. When you just had listen 8443; you were getting duplicate errors because --https-port 8443 told certbot to upgrade nginx http blocks to https on 8443. So you are invoking certbot with a target https port of 8443, and feeding in a http block for the same port. Could certbot better detect that? Sure - but this is a very unique edge case.

  2. When you started with the dummy certificate, Cerbot picked up that you were just upgrading that certificate - so it just renewed the certs and ignored the rest -- so your existing config values didn't get obliterated. Most users would be incredibly mad if certbot overwrote their ssl configuration on renewal. Running certbot enhance after installation on this might install the missing elements, if not... it could be a good idea to file a Feature Request for a new certbot renew flag that would upgrade the various ssl params to the active setup.

2 Likes

Yes, I have a both in my working nginx config: a 'listen 8000;' (non ssl) section for http CA access, and the dummy 'listen 8443;' section for certbot certifacte install.

I remove it after certbot installation, but indeed it's just unreachable from outside docker network as I don't publish this port anyway.

Yes I already tried all ' certbot enhance' option, but none added the protocol-related options. Indeed, instead of trying to upgrade an inital 'listen 8443'' to ssl, that would be another nice solution to add an enhance parameter to add protocol-related options. I was wondering why it's missing as there are some other security parameter...
Nginx would be just started with a working ssl config using a dummy certificate , and certbot would update certificate and add the security option I'm looking for :slight_smile:

But it sounds like you're not running anything on 8000 though, right?

If that's the case, try running certbot with your 8443/8444 host as 8000. That should upgrade 8000 to support ssl, and then you can disable the port.

In my experience, the easiest way to leverage a lot of these tools is to let them create the extra hosts and then just disable (or never enable) them with firewalls. Having that 8444 host in nginx that is not visible to docker will do nothing.

1 Like

I'm not running anything on 8000 because it's used as forward from external 80, that's why I don't want it upgraded to https.
Atm I'm upgrading 8443 from 8444 and it's running fine, as expected.
Meanwhile a nicer solution, I have created the feature request for another 'certbot enhance' parameter to add protocol-related options.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.