Support mod_gnutls with Apache


I'd like to see support for mod_gnutls in addition to mod_ssl when using the --apache option.

Searching the forum I found a several year old thread Certbot Apache Plugin - GnuTLS instead of OpenSSL which suggested to use the 'webroot' option instead. Is this this the only option?


1 Like

Welcome to the Let's Encrypt Community :slightly_smiling_face:

For http-01 challenges for certbot, in addition to the --webroot authenticator there is also the --standalone authenticator, which is not preferable since it would require stopping Apache before performing authentication.

What you are suggesting is related to the Apache installer though and not the Apache authenticator.

1 Like


I'm sorry I got confused with the terms.

I guess I can issue a apache reload command after installing updated certs?


Bingo. :slightly_smiling_face:

Try something like this to have your renewals be fully automated:

sudo certbot certonly --apache -d "," --deploy-hook "apachectl -k graceful"

Just be sure your Apache configuration is correctly setup to point to the certificate and private key symlinks in the live directory for your certificate. Remember to reload Apache with sudo apachectl -k graceful once you make your configuration changes.

1 Like

Not sure how difficult it would be for certbot-apache to support mod_gnutls. AFAIK it doesn't really do much with mod_ssl currently too, except some enabeling/disabeling and using it for the <IfModule> section around the HTTPS VirtualHost..


Using --apache requires mod_ssl which is what I want to avoid.

Perhaps --webroot is what I need, and then use a deploy-hook to reload apache config. How would it work with certbot renew?

1 Like

Also for the apache authenticator plugin? If --apache doesn't work, please try -a apache which would just set the authenticator to "apache".


I can assure you that the apache authenticator (which is all that's in play with certonly) does not use mod_ssl.

1 Like

I just tried this:

# certbot certonly --webroot --dry-run -d -w /var/www/domains/
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Simulating renewal of an existing certificate for
The dry run was successful.

- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See for instructions.

So this seems to work. Next I need to see if renewal works too =)

1 Like

Well, if you're not going to use the apache installer anyway, it would make sense to just use the webroot authenticator too in stead of the apache authenticator.

That said, I'm trying to get a local Apache with mod_gnutls working so I can try to add mod_gnutls support to certbot.

1 Like

Please remember to use the deployment hook I gave you though, even if you use the webroot authenticator.

And always put the -w parameter before its corresponding -d parameter.


Yes. :slight_smile:

I have added renew_hook = /etc/letsencrypt/renewal-hooks/ in the /etc/letsencrypt/renewal/ Should that be enough when running certbot renew later?

1 Like

I'd like that too. Makes initial installation easier and provides the community with another option to openssl.

1 Like

I've developed a very rough stub for GnuTLS support in the certbot-apache module:

But locally, it works.. Sort of.. I can succesfully get a cert from my locally ran Pebble and the apache installer generates a working le-ssl.conf file with GnuTLS directives inside, based on which module is active. Not sure how this would work if both are active tho, if that's even possible.It then just uses the first one from the if .. else which is mod_ssl.. But there probably aren't many people out there running both modules at the same time I guess.

I still had a Listen 443 encased in a <IfModule mod_ssl.c>. Preferably, this would be something that would also be handled correctly, but I didn't put any effort in that yet.


@Osiris Cool.

I've done a manual edit on my configs.

  • change -D SSL to -D GNUTLS
  • replace 00_default_SSL_vhost.conf with a 00_default_GNUtLS_vhost.conf:
<IfDefine GNUTLS>
	Listen 443
		<VirtualHost _default_:443>
			ServerName localhost
			Include /etc/apache2/vhosts.d/default_vhost.include
			ErrorLog /var/log/apache2/ssl_error_log
			TransferLog /var/log/apache2/ssl_access_log

			GnuTLSEnable on
			GnuTLSPriorities NORMAL
			GNUTLSExportCertificates on
			GnuTLSCertificateFile /etc/ssl/apache2/server.crt
			GnuTLSKeyFile /etc/ssl/apache2/server.key

			## Per-Server Logging:
			# The home of a custom SSL log file. Use this when you want a compact 
			# non-error SSL logfile on a virtual host basis.
			<IfModule log_config_module>
				CustomLog /var/log/apache2/ssl_request_log "%t %h \"%r\" %b"
					# "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
  • changed /etc/letsencrypt/options-ssl-apache.conf to:
GnuTLSEnable on
GnuTLSExportCertificates on
GnuTLSDHFile /etc/letsencrypt/dhparam_4096.pem
  • Do need to tweak the GnuTLSPriorities to work with more browsers while keep forward secrecy etc in SSL Server Test (Powered by Qualys SSL Labs)
  • Another issue is that Apache LogFormat / CustomLog doesn't seem to accept %{SSL_PROTOCOL} and %{SSL_CIPHER} for some reason. I'd like some input here if you have.
1 Like

I'm curious, what's your use for GNUTLSExportCertificates?

Those variables should be available:


In the man it states:

With GnuTLSExportCertificates enabled, `mod_gnutls` exports the same
environment variables to the CGI process as `mod_ssl`.

So I thought it would have added back the missing variables SSL_PROTOCOL, SSL_CIPHER for the LogFormat/CustomLog, but it didn't help =(

1 Like

That is specifically referring to the certificate itself, not the other variables. Are you using the correct variable suffix in your CustomLog/LogFormat string? I.e., %{SSL_PROTOCOL}x is used with mod_ssl, but I'm not sure if mod_gnutls enables the use of that x suffix. Apache itself has the e suffix for environment variables and the mod_gnutls manual says the variables such as SSL_PROTOCOL are exported as environment variables. Maybe %{SSL_PROTOCOL}e would work?


%{SSL_PROTOCOL}e works. Thanks for that tip!

Also a better ciphersuite is:

Qualys SSL test gives A+ on and no WEAK ciphers listed, while works with all modern browsers :slight_smile:


You can probably remove the CCM ciphers too, as CCM isn't widely adopted and doesn't offer any benefit above GCM. Heck, my Chromium doesn't even support it, nor can I find any client on Qualys SSL Labs - Projects / User Agent Capabilities that does support it, although I only checked major recent browsers, not all clients.