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 alsoaccepts OCSP requests with SHA-256 used as hash algorithm.
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!
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!
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.
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.