Local CA Fallback

[robertsLando]

Local CA Fallback

[JonasAlfredsson]

Yes, I think it is better to close it because I have only seen you request it, and I don't think I have time for such a special usecase :)

[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?

[JonasAlfredsson]

This issue has been open for quite a while, did you manage to find a solution to your setup?

[robertsLando]

@JonasAlfredsson Nope but no worries feel free to close this as I think it is a really custom use case.