You could probably split it into two pieces, a root-requiring one that handles the certificates and a lower-rights side that does the network communication and writing to the web folder, but I think that's been tried a few times and never finished.
Thank you. The FAQ even seems to suggest it should be this way:
Whether root is required to run Certbot or not depends on how you intend to use it.
The end result story I hope for: One can run Certbot as an otherwise non-Administrator user, and have it successfully create / renew / write certificates and private keys to a directory on which one can apply one's choice of DACLs. If users want to use things like the
--webroot option with privileged directories, it can continue to run as Administrator privileges.
In ran into a nasty user experience issue at the end of implementing the priv check: Unprivileged users don't see
SeCreateSymbolicLinkPrivilege in an interactive desktop session of powershell.exe even though it's there when I run certbot using
runas for the same user. Nor does the interactive session have privilege to assign privilege.