Local CA Fallback

[robertsLando]

I would like to know if this feature could be considered and also how difficult it's to add this to the actual implementation.

For my use case I let users configure their certbot nginx from a web page (that of course is served by the container itself), the problem I have is that an error in such process could lead the container in a state that is not recoverable, for this reason I would like to know if it's possible to add an env var that allows to fallback to local ca when local ca is not enabled and the certbot renew fails.

The alternative to this is to implement on my side a check that detects the fail someway and forces the localca env var to true

[JonasAlfredsson]

In what way do the container fail? Is the config corrupt or what is going on?

As it is now there is no supported way of switching willy nilly between local CA and certbot since they have different folder structure, and a wipe of the letsencrypt folder is necessary.
While I believe the local CA could forcefully overwrite the things necessary for it to "take over", I am not as sure of how certbot would handle it if it is to be restored.

[robertsLando]

In what way do the container fail? Is the config corrupt or what is going on?

Possible fails:

• Wrongly typed domain
• Port 80 not open
• Wrong configuration
• ACME challenge fails for some reason

As it is now there is no supported way of switching willy nilly between local CA and certbot since they have different folder structure, and a wipe of the letsencrypt folder is necessary.

I'm actually doing it without any problem by setting local ca env var to 1/0 right now

[JonasAlfredsson]

I do not fully comprehend how the failure manifests itself, and how local CA is able to prevent it.

The users are able to connect to the container on some admin interface (which allows any incoming domain?), where they then can enter a new domain which then fail to get certificates for some reason. The scripts then disable this config and thus making the admin interface unreachable?

Would it make sense to have this admin interface in a separate config which remains accessible even after other servers are configured?

[robertsLando]

Lets say I have a domain.com that points to the public ip X.X.X.X

by default local CA is on so the browser will ask you to "accept the risk" in order to open the page. Then you configure certbot from ui selecting for example Webroot as method, you apply the changes and under the hoods I restart the nginx container with the new env vars, the nginx container at this point gots some errors (for any possible reason) and now I have no easy way to recover from this except by ssh inside the machine and manually restart nginx container with local_ca to 1 so at least he can enter the app. The application that serves the admin iterface is the same that serves the application, it's not running in a separeted port, if a user is a superuser he can manage that part.

I understand this may be a really not usual use case of this container so no worries if you consider this not important to implement, was just curious to know your opinion on this, otherwise I will find some alternatives

[JonasAlfredsson]

This seems to be quite a unique setup and I have a hard time grasping the exact flow of events and possible error states, which makes an error handling implementation from me very difficult.

I actually think some external monitoring script would suit your need better since that could be tuned for your specific situation.

Else you could perhaps do something with an entrypoint.d script which could poll the nginx server and perhaps restart everything again with local CA in case it does not get a 200 response within 2 minutes?