icing
File permissions and MDMessageCmd
When running a MDMessageCmd script for "renewing", "renewed", and "expiring", it would be useful to access the certificate file, e.g. to report the SANs, dates, key type.
For "renewing" and "expiring", the certificate can be obtained from a host (e.g. by openssl s_client), though this is inconvenient.
For "renewed" - the new certificate is in staging, but although that is accessible to the unprivileged user (www,apache) the contents of staging aren't documented.
For "installed", the script runs privileged.
I don't see why the certificates (pubcert*.pem) in both staging and 'domains/*can't be protected g+r,o+r`. They are (or will be) public; there are no secrets to protect.
Can you document at least where to find the certificates? And change the permissions on the certificate files?
Along the same lines, what happened to the environment variables that we passed to scripts (e.g. MD_STORE, 'MOD_MD_VERSION', ...) back when I was working on event handling? I don't see them in the sources (or the documentation) - did they get dropped in a merge?
(References still in contrib/md_events/md_events).
The environment variable were dropped since we could not find a reliable way to make them work on Windows. The env created for the subprocess was missing vital variables needed on that platform, if I remember correctly.
It is certainly possible to document the files in the domain and staging directory. That has been stable for a long time.
What is the use case for making files in staging accessible beyond the apache user that runs the script? I am not in favour of weakening permissions for something hypothetical.
I don't understand why envvars would be unreliable on Windows. CGI scripts depend on them. Although I don't run httpd under windows, environment variables have to work. I'm pretty sure that my code attempted to pass the same variables that CGI scripts do. If I missed something, it should be fixed - not throw out the whole mechanism. If you can find the details of what went wrong with Windows, please open a bug and assign it to me after you restore the code that worked for Unix.
Even if there's an insoluble problem, it still doesn't make sense to limit all other platforms due to a problem with Windows. HTTPD has entire modules that only work on specific platforms. mod_systemd on Linux; mpmt_os2 on OS/2, mpm_winnt on Windows, ... I'm pretty sure that I've come across individual features that are platform specific, too. Cross-platform compatibility is great when it's possible, but when it's not, we shouldn't limit the more capable platform. Note that in this case, shell scripts are likely platform dependent anyway.
So please put the environment variables back. They work for all Unix platforms. For those platforms, they make the scripting easier. And within that group, platform-independent. If there are scripts that work on Windows too, but we really can't get the envvars to work, we can turn off envvars on Windows. Those scripts can always default them (if undefined/null). Not a desirable outcome, but such scripts would be no worse off than today. And life would be better for Unix.
Permissions are more about domains than staging.
Certificates in staging are accessible to the script user, don't need to be accessible to others. Certificates in domains are not, but access for the scripts would be helpful. Group access would suffice. But in both cases, certificates are by definition public. Once they're installed, one can get them over the network. There's nothing to be gained by over-protecting them. Keys are a different matter, of course.
If an event script can access certificates, e-mails can be more descriptive. For example, they can include the (new) expiration date, new SANs, key type, serial #, etc. For expiring certificates, the actual expiration date. And can escalate based on days remaining rather than the single "soon" of the event. There's also no reason for scripts to wait for the server running mod_md to install certificates that will be used on other servers. As soon as they're ready, it should be possible to move them to where they're needed. Documenting staging supports that model.
I'm serious about security. But that means protecting what needs to be protected. And not over-protecting what doesn't.
Unless someone makes the code that adds environment variables to mod_md scripts that preserves all existing env vars (which might be possible but I failed to achieve), breaking existing deployments is not an option.
Documenting files in staging and domains seems fine, as I already said.
Opening up file permissions I see as a no goal. The script at install time has all needed permissions and can do whatever it wants. This is the time that the module announces the new certificates to be ready and valid.