Use existing certificate even when a container is down, instead of a self-signed certificate

[Exagone313]

Hello,

When a container for a domain is down, nginx-proxy serves a 503 error with a self-signed certificate for the domain name letsencrypt-nginx-proxy-companion.

Since there is an existing certificate that is used when the container is up, nginx-proxy should be able to use it, to avoid displaying certificate errors to the clients during a deployment.

How can I do that?

I have considered creating a standalone certificate for all the needed domain names, but I haven't found instructions on how to use this certificate by default on any hosts even when containers are down.

Comparatively, when using a manually crafted nginx configuration (without nginx-proxy and acme-companon), the server blocks won't be removed and nginx will keep using the configured certificates for all the hosts even when the upstream service is down.

Thanks.

[Exagone313]

I have read the code in app/entrypoint.sh, it generates a default self-signed certificate in check_default_cert_key. It cannot be disabled. I understand that you need a valid (self-signed) certificate to start serving websites on HTTPS, but once a valid default certificate can be created, this self-signed certificate can be discarded.

I have created the issue #1062.

---

I'm also considering an alternative, by doing both steps:

• modify the template used in nginx-proxy so that it generates server blocks for existing certificates (may not be possible with simple templating, it probably needs an additional environment variable)
• add an option in acme-company to do not remove certificate symbolic links (in cleanup_links)

[buchdag]

The alternative I'd suggest is to use ninx-proxy default host feature to configure default "service unavailable" page.

This way if one of your container is down, and you try to access it you get the default host (with correct certificate) instead.

[Exagone313]

@buchdag Hello, thanks for your answers.

The default certificate way is currently fully manual or needs to be scripted:

• the first time nginx-proxy and acme-companion is launched, you can't create a symbolic link to or copy a certificate you don't yet have (and it's fine)
  • note that recent versions of nginx-proxy implements a trick so you no longer need a default certificate
• once you have a certificate, you would need to have a script that copies a valid certificate to default
• you can't properly make a symbolic link to such certificate, because it is removed in cleanup_links
  • if nginx-proxy is recent enough, the trick I linked above will be used as the default certificate is removed and the nginx configuration will be valid - the default certificate will be recreated on next restart
• if you make a copy of the certificate, you would need to maintain the copy periodically

I have not tested the default vhost feature, by reading the nginx-proxy template it seems that you need an additional container that matches DEFAULT_HOST with VIRTUAL_HOST, which seems to be over-engineering, but it could work. This part could be handled with a custom nginx configuration block (with if, return, default_type, charset), but an additional nginx container (or anything else) could work too.

While my problem can be fixed this way, I'd be more happy if acme-companion provided a more sane default for everyone, rather than serving a self-signed certificate when a container is down like it does actually.

An idea would be to create a symbolic link to a certificate, based on an environment variable (DEFAULT_HOST?), or link to the default self-signed one when none have been declared.

I'm not sure if that would be the best implementation, but it needs a period during when the behavior is hidden behind an environment variable (a feature flag) before it becomes the default.

[buchdag]

you can't properly make a symbolic link to such certificate, because it is removed in cleanup_links

This was unintentional and should be fixed in #1074

[buchdag]

An idea would be to create a symbolic link to a certificate, based on an environment variable (DEFAULT_HOST?), or link to the default self-signed one when none have been declared.

I also think this would be a correct way to handle this, I'll think a bit about how to best implement it.

[vialcollet]

Hi all
Using DEFAULT_HOST doesn't work because the certificate from DEFAULT_HOST would not match the initially targeted host.
Let's consdier this case:

• server url: mydomain.com
• DEFAULT_HOST mydomain.com
• subdomain: test.mydomain.com

When test.mydomain.com services are up and running, they are served with test.mydomain.com certificate, all good. However when the containers are stopped then the url remains test.mydomain.com but it is served with mydomain.com certificate which obviously doens't work.

This is causing issues as my services are frequently reported by Bugcrowd's VDP program and my secrity team is unhappy about it :(