But not mandated for the OCSP requests hashAlgorithm, which is just defined as AlgorithmIdentifier, which isn't restricted further.
Fact is: GnuTLS uses SHA-256 exclusively and this is currently giving errors on the OCSP server. We're not asking to change the way Let's Encrypt signs its OCSP requests (which already is RSA with SHA-256 by the way, its just the hash algorithm that's SHA-1..), but also accepts OCSP requests with SHA-256 used as hash algorithm.
I'm with Osiris here. I can't see that SHA256 is discouraged or forbidden in that RFC. Also the SHA1 "deprecation" came in about 3 years after that RFC was published.
If it is the policy to LE to only allow SHA-1 then I will mention this on GnuTLS mailing lists to see if they are willing to includ SHA-1 once again. Looking at the source-code they dropped SHA1 many years ago. https://github.com/airtower-luna/mod_gnutls/blob/677754f5c7f0f2cf455e8f95d86c3220a9f6b29e/src/gnutls_ocsp.c#L150 (from december 2016)
Understood; I've mentioned this to my colleagues. If someone wouldn't mind opening a Boulder issue with a summary of the current GnuTLS implementation, and referencing the old issue #1494, that would be very helpful to let us track this in a more structured way. Thanks!
Hi. I created an issue as best I could describe it. Feel free to suggest improvements!
Baseline Requirements section 4.9.10 says "OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019."
RFC 6960 does not say which hash algorithms to support.
RFC 5019 section 2.1.1 says "Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values."
So it seems unwise for a client to use anything other than SHA1 for this. It might be good to file an issue against gnutls to support RFC 5019.
But that doesn't prevent Let's Encrypt from supporting other hash algorithms if they like.
In effect both are correct but not compatible. I think your remarks are valid and I'll bring those to mod_gnutls mailing lists and or github issue 
Update: mod_gnutls does not support Let's Encrypt OSCP · Issue #3 · airtower-luna/mod_gnutls · GitHub
Thanks everyone! I've responded on both our github issue and the mod_gnutls issue. Basically, we only allow SHA1 in OCSP requests because doing so is profiled by the "lightweight OCSP profile for high-volume environments", which we definitely count as 
See details in the bugs!
While indeed I've linked to that repository too (because mod_gnutls' own Trac was constantly down...), I'm not sure if that's really the official mod_gnutls repository.
It seems Trac is working again now, maybe you can open the issue at the official location? https://mod.gnutls.org/newticket
In the past I've seen activity regarding GnuTLS over on GitLab: gnutls / GnuTLS · GitLab
The repo there looks official and is active. The Github repo on the other hand has only seen 3 issues in it's lifetime...
Looks like that's for the GnuTLS library? And not mod_gnutls?
Whoops my bad, confused the two.
Hello everyone!
Just wanted to mention that the developer of mod_gnutls fixed the issues with OSCP stapling and Let's Encrypt!
You'd have to use sources from github until there is a new release to have the fixes.
Thank you all for the help and input.
Hello everyone! Based on the feeback and comments in this thread I decided to make a blog post with the settings and options I ended up using for my own website. Hopefully it can help someone else get going with mod_gnutls. 
https://wiki.tnonline.net/w/Blog/Let's_Encrypt_with_Apache_and_GnuTLS
I have but one critique: The automated renewals shown are scheduled via cron.daily entry.
This will not scale well; as all that follow this path will be running their job at the exact same time.
Luckily, that's only an issue for older versions of certbot: when run non-interactively, certbot nowadays pauses for a random amount of time before doing any renewing.
Although I too have a small note on the Wiki:
Using Certbot webroot installer
There is a clear distinction between "installers" and "authenticators" within certbot: an installer will interface with a webserver and can actually install the certificate by modifying its configuration. An authenticator can respond to a certain challenge and by that can validate an authorization. For example, a DNS authenticator plugin can "do" a dns-01 challenge and the nginx and apache authenticator plugins can do the http-01 challenge (and are installers too!) The webroot plugin is not an installer, but an authenticator providing the http-01 solution.
Built-in excellence!
Thanks for that clarification. And thank you for having a look at the article! I must admit it was confusing for me (the installer vs authenticator parts) so your input is very much appreciated.
I've updated the text as follows. Is that better?
In order to use Certbot with GnuTLS you have to use the webroot authenticator which instructs certbot to use the http-01 challenge method using a pre-existing directory in your webserver.
But isn't this true with systemd timers as well, unless RandomizedDelaySec is used by default on most distros?
This is good. I don't need to add a random delay myself 
cat /etc/systemd/system/snap.certbot.renew.service
contains:
ExecStart=/usr/bin/snap run --timer="00:00~24:00/2" certbot.renew
In a test Ubuntu system...
cat /etc/systemd/system/snap.certbot.renew.timer
contained:
[Timer]
Unit=snap.certbot.renew.service
OnCalendar=*-*-* 02:37
OnCalendar=*-*-* 20:30
and after reboot:
[Timer]
Unit=snap.certbot.renew.service
OnCalendar=*-*-* 04:12
OnCalendar=*-*-* 13:59
Sounds 100 % OK!