-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is mod_md's idea of a fallback cert? #317
Comments
Maybe this needs to be added to the README, but let's clarify here first. The motivation for this discussion seems to be: "What happens when Lets Encrypt stops working (for whatever reason)? How can I protect my site?" ACME fails for a New Managed Domain (MD)For any virtual While the module is negotiating with Lets Encrypt for a "real" certificate, visitors to this site will see the fallback. Their browser will not trust it, but they may "click through". Once the ACME certificate is there, and the server is reloaded, the fallback is archived and replaced with the new cert. Should the ACME server fail to give a new certificate, errors will be logged, notifications will be triggered (see ACME fails for an existing MDLet's assume the initial setup worked and you got certificates from Lets Encrypt. Then, for some reason, renewals stop working. What will First, it will continue to use the certificate it has. Even if it already expired. The client browser then will not trust it, but the user may "click through". The module will keep on trying to get you a new cert, using a backoff delay in retries, but do try that at least once per day or more often. It will tell you about this via With the default settings, a Lets Encrypt cert lives for 90 days and Apache will renew it 30 days before its lifetime runs out. So, this failure would need to go unfixed for 30 days before your users notice. You can lower some risks of failures by adding a second ACME server to you config. See how to setup a failover CA in the documentation. Your own "fallback" cert?There is no way to configure This seems as good as providing your own self-signed fallback, as in all cases users will get a warning and need to "click through". Now, if you are able to generate a valid fallback certificate at all times, you do not need mod_md in the first place. Then just use your own cert all the time. |
"Click-through" does not happen in all cases, unfortunately. A warning is not issued if a site has HSTS records present. You simply universally get a "cannot establish a secure connection" error, and not all browsers even indicate it is related to HSTS. Thus, a cert (wildcard or otherwise), signed by our own "internal" CA which would allow us to continue to use things, until LE did its thing. It would be useful to have the behavior of how the fallback cert is generated (perhaps just copied from somewhere else on disk?) configurable. |
Second, note my logs entry above, it implies the existence of a fallback entry that is per domain:
Whereas the File Storage section of the readme only references those being in the main folder, and not the per-domain folders. In the readme, you say "What is happening? At start up, mod_md generated a self-signed certificate for the new https host to use and switch that host to 503 responses. This made sure that your server started without delay and that your other hosts could start working." but there's no mention made that this is the "Fallback" cert mentioned. === And, third, finally, on the main apache site -- NO mention is made of how and when these fallback certs are generated. Maybe that needs a fix with an actual apache bug, but it would be nice to point them to a corrected readme here (i.e. mention the filenames in the readme, and in the File Storage section above. |
This would not only affect the fallback on a new site, but especially the behaviour when a cert has expired, correct? This would only be possible on a server reload, however, since once a certificate has been loaded, it is fixed for the runtime of the server. Hmm... As for the documentation, this can always be improved and you are welcome to add a PR for better explaining things. So far, the fallback cert was treated as an initial thing with no peculiar interest to users, since it usually disappears after some minutes. However, your use case is new. To get the benefits you describe, you need clients with an updated root store, which is outside enterprises generally frowned upon. (If I understand your case correctly.) I do not doubt that your motivations are valid. However, I'd like to spend my free time more on things benefitting a wider range of users. |
Just an idea: if you have your internal "CA" anyway, why not give it an ACME server (pebble is quite uncomplicated) and configure that server as fallback for mod_md? That should give you exactly what you want. |
That's a thought -- right now, my initial goal, as well as the one in the email from a couple years ago on apache users is "understand in which cases the fallback cert is used". Ignoring HSTS (and just so I can suggest better docs), is there a way to configure mod_md to treat a site using the fallback cert as a valid site, instead of the 503? Also, is there a global fallback cert, as mentioned in the file storage of the README, or is that a typo? |
No. I think your idea of what a "fallback" certificate is and what
No, there is not for some considerable time. The documentation was not updated. I just removed the mention. Thanks for pointing out. |
Okay, so:
Is that a correct understanding? If so, I guess my only other question is (for documenting this), what params are used to generate that cert (key strength, algorithm, lifetime, subject name?) My assumption of "fallback" (based purely on that word -- I would have used "initial" or "preliminary" or something) could have been any of:
But I see this isn't correct. Hopefully you can understand my confusion, and why I was mystified that it wasn't documented. (To be clear, I'm not asking for it to be any of those, just explaining my thought process.) |
Yes.
It's all in the code. The generation is in
Naming is hard. All is fine. |
From a mail to apache-users mailing list:
The text was updated successfully, but these errors were encountered: