# Support mod\_gnutls with Apache **URL:** \ **Category:** Feature Requests\ **Created:** [July 3, 2021, 5:51pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015 "2021-07-03T17:51:06Z")\ **Posts on this page:** 20\ **Page:** 3
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [July 5, 2021, 5:56am UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/41 "2021-07-05T05:56:58Z")
> [@JamesLE](#): > > Alas, SHA-1 is still specified in some parts of [RFC 6960](https://datatracker.ietf.org/doc/html/rfc6960). 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. ---
**Author:** ![Forza](https://avatars.discourse-cdn.com/v4/letter/f/74df32/32.png) [@Forza](https://community.letsencrypt.org/u/Forza)\ **Post date:** [July 6, 2021, 7:25am UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/42 "2021-07-06T07:25:26Z")
> [@JamesLE](#): > > Alas, SHA-1 is still specified in some parts of [RFC 6960](https://datatracker.ietf.org/doc/html/rfc6960). This thread from MozDev may be relevant: [https://groups.google.com/g/mozilla.dev.security.policy/c/ImCmDRMj-JU](https://groups.google.com/g/mozilla.dev.security.policy/c/ImCmDRMj-JU) 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](https://github.com/airtower-luna/mod_gnutls/blob/677754f5c7f0f2cf455e8f95d86c3220a9f6b29e/src/gnutls_ocsp.c#L150) (from december 2016) ---
**Author:** ![JamesLE](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jamesle/32/49364_2.png) [@JamesLE](https://community.letsencrypt.org/u/JamesLE)\ **Post date:** [July 6, 2021, 8:01pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/43 "2021-07-06T20:01:33Z")
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! ---
**Author:** ![Forza](https://avatars.discourse-cdn.com/v4/letter/f/74df32/32.png) [@Forza](https://community.letsencrypt.org/u/Forza)\ **Post date:** [July 8, 2021, 3:48pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/44 "2021-07-08T15:48:00Z")
Hi. I created an issue as best I could describe it. Feel free to suggest improvements! > > > \[mod\_gnutls\](https://github.com/airtower-luna/mod\_gnutls) uses SHA256\[\[1\]\](https…://github.com/airtower-luna/mod\_gnutls/blob/a6b3ae34c7bb069bf166530ed6fab71b7cd2139d/src/gnutls\_ocsp.c#L201) to sign its OSCP requests. This fails because the OSCP responder doesn't support the SHA256 signed OSCP requests\[\[2\]\](https://github.com/letsencrypt/boulder/issues/1494). > > We've discussed the situation a little bit on the Let's Encrypt community forum\[\[3\]\](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/31) and came to the conclusion to bring the issue back here again. > > I am not fully vested in the OSCP standards but I think they do not prohibit SHA256. OTOH they are published before the SHA1 deprecation debate so perhaps it wasn't relevant to support anything but SHA1 at the time. mod\_gnutls has enforced SHA256 signed OSCP requests since as far back I can find source code for (\_mod\_gnutls-0.8.0-beta June 2016\_)\[\[4\]\](https://github.com/airtower-luna/mod\_gnutls/blob/4bc17ae03ea019d9954d3d131c9ab4247267c890/src/gnutls\_ocsp.c#L130). > > IMHO I think that SHA256 signed requests should be supported, even if the security benefits shows to be small. > > \[1\] https://github.com/airtower-luna/mod\_gnutls/blob/a6b3ae34c7bb069bf166530ed6fab71b7cd2139d/src/gnutls\_ocsp.c#L201 > \[2\] https://github.com/letsencrypt/boulder/issues/1494 > \[3\] https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/31 > \[4\] https://github.com/airtower-luna/mod\_gnutls/blob/4bc17ae03ea019d9954d3d131c9ab4247267c890/src/gnutls\_ocsp.c#L130 ---
**Author:** ![jesperkristensen](https://avatars.discourse-cdn.com/v4/letter/j/46a35a/32.png) [@jesperkristensen](https://community.letsencrypt.org/u/jesperkristensen)\ **Post date:** [July 8, 2021, 5:28pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/45 "2021-07-08T17:28:06Z")
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. ---
**Author:** ![Forza](https://avatars.discourse-cdn.com/v4/letter/f/74df32/32.png) [@Forza](https://community.letsencrypt.org/u/Forza)\ **Post date:** [July 8, 2021, 6:16pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/46 "2021-07-08T18:16:05Z")
> [@jesperkristensen](#): > > RFC 6960 and/or RFC 5019. 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](https://github.com/airtower-luna/mod_gnutls/issues/3) ---
**Author:** ![aarongable](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/aarongable/32/42043_2.png) [@aarongable](https://community.letsencrypt.org/u/aarongable)\ **Post date:** [July 9, 2021, 4:28pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/47 "2021-07-09T16:28:17Z")
Thanks everyone! I've responded on both [our github issue](https://github.com/letsencrypt/boulder/issues/5523) and the [mod\_gnutls issue](https://github.com/airtower-luna/mod_gnutls/issues/3). 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! ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [July 9, 2021, 5:37pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/48 "2021-07-09T17:37:57Z")
> [@Forza](#): > > Update: [mod\_gnutls does not support Let's Encrypt OSCP · Issue #3 · airtower-luna/mod\_gnutls · GitHub](https://github.com/airtower-luna/mod_gnutls/issues/3) 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](https://mod.gnutls.org/newticket) ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [July 9, 2021, 6:05pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/49 "2021-07-09T18:05:04Z")
In the past I've seen activity regarding GnuTLS over on GitLab: [gnutls / GnuTLS · GitLab](https://gitlab.com/gnutls/gnutls) ~~The repo there looks official and is active. The Github repo on the other hand has only seen 3 issues in it's lifetime...~~ ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [July 9, 2021, 6:09pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/50 "2021-07-09T18:09:42Z")
Looks like that's for the GnuTLS library? And not mod\_gnutls? ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [July 9, 2021, 6:13pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/51 "2021-07-09T18:13:52Z")
Whoops my bad, confused the two. ---
**Author:** ![Forza](https://avatars.discourse-cdn.com/v4/letter/f/74df32/32.png) [@Forza](https://community.letsencrypt.org/u/Forza)\ **Post date:** [July 29, 2021, 11:02am UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/52 "2021-07-29T11:02:29Z")
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. ---
**Author:** ![Forza](https://avatars.discourse-cdn.com/v4/letter/f/74df32/32.png) [@Forza](https://community.letsencrypt.org/u/Forza)\ **Post date:** [August 5, 2021, 11:03am UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/53 "2021-08-05T11:03:49Z")
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](https://wiki.tnonline.net/w/Blog/Let's_Encrypt_with_Apache_and_GnuTLS) ![450px-Screenshot_SSL_Server_Test_A+1](https://global.discourse-cdn.com/letsencrypt/original/3X/d/0/d072beeaddb9ddf2e53f35faf459b7e3a9f448d8.png) ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [August 5, 2021, 6:11pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/54 "2021-08-05T18:11:18Z")
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. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [August 5, 2021, 6:17pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/55 "2021-08-05T18:17:06Z")
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. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [August 5, 2021, 6:21pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/56 "2021-08-05T18:21:10Z")
Built-in excellence! ---
**Author:** ![Forza](https://avatars.discourse-cdn.com/v4/letter/f/74df32/32.png) [@Forza](https://community.letsencrypt.org/u/Forza)\ **Post date:** [August 5, 2021, 7:19pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/57 "2021-08-05T19:19:50Z")
> [@Osiris](#): > > 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. 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](https://letsencrypt.org/docs/challenge-types/) using a pre-existing directory in your webserver. ---
**Author:** ![Forza](https://avatars.discourse-cdn.com/v4/letter/f/74df32/32.png) [@Forza](https://community.letsencrypt.org/u/Forza)\ **Post date:** [August 5, 2021, 7:24pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/58 "2021-08-05T19:24:37Z")
> [@rg305](#): > > 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. But isn't this true with systemd timers as well, unless RandomizedDelaySec is used by default on most distros? > [@Osiris](#): > > 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. This is good. I don't need to add a random delay myself 🙂 ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [August 5, 2021, 7:33pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/59 "2021-08-05T19:33:20Z")
> [@Forza](#): > > But isn't this true with systemd timers as well `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: ```nohighlight [Timer] Unit=snap.certbot.renew.service OnCalendar=*-*-* 02:37 OnCalendar=*-*-* 20:30 ``` and after reboot: ```nohighlight [Timer] Unit=snap.certbot.renew.service OnCalendar=*-*-* 04:12 OnCalendar=*-*-* 13:59 ``` ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [August 5, 2021, 7:54pm UTC](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015/60 "2021-08-05T19:54:24Z")
> [@Forza](#): > > I've updated the text as follows. Is that better? Sounds 100 % OK! [Previous page](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015.md?page=2) [Next page](https://community.letsencrypt.org/t/support-mod-gnutls-with-apache/155015.md?page=4)