Remove support for TLS 1.0, 1.1 in Nginx


I’ve just been looking through the existing threads that I can find on this topic and none seem to cover what I’m looking for. To wit, they mostly deal with an apache-only directive (“SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1”) which feels like a bad hack in that it must be done on a per-host basis. I don’t want to modify each host to tell it that it should only accept the good one of the servers three protocols; I want the server to only support the good protocol!

Background: I just set up SSL and put a site live. I did the, got an A, and am now attempting to cover the warnings to up the score (not just for the sake of the score).

Environment: Debian 9 vm running nginx reverse proxy
Cetbot config file was autogenerated at /etc/letsencrypt/options-ssl-nginx.conf (see below). It warns you not to manually modify it yet it seems to contain everything needed. I am quite sure that my MANUAL step would be to remove the offending protocols from the ssl_protocols line and then do the same for the ssl_ciphers line. However, this solution would be a ticking time bomb that I do not want.

Since the file is autogenerated, it seems like there should be a way to pass to certbot which protocols/ciphers to allow. This would logically modify the include file which would pass its effect on to any ssl enabled domains.

Please advise as to how this can be accomplished.


This file contains important security parameters. If you modify this file

manually, Certbot will be unable to automatically provide future security

updates. Instead, Certbot will print and log an error message with a path to

the up-to-date file that you will need to refer to when manually updating

this file.

ssl_session_cache shared:le_nginx_SSL:1m;
ssl_session_timeout 1440m;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;



Hi @teotikalki

active Tls.1.0 / Tls.1.1 isn’t direct relevant to get an A+.

You need HSTS and TLS_FALLBACK_SCSV to get an A+, if you have A.

But if a system doesn’t support TLS_FALLBACK_SCSV (like IIS), then removing Tls.1.0 and 1.1 (+ HSTS) works.

Then the server supports only one protocol, so a downgrade attack is impossible.

1 Like

@JuergenAuer Good to know. I’m going to look into HSTS and TLS_FALLBACK_SCSV.

This does not, however, mitigate my desire to accomplish what I stated. I also feel that there very much should be a way to control what is generated in that file. I just read an article about the deprecation of those protocols in 2020; it IS a good step to take (please refer to the ‘not JUST for the sake of the score’ comment).

So… thank you again for your information which I am most definitely grateful for and am pursuing… but it doesn’t address my question at all.
So it’s clear, my direct question is this: How do I make certbot generate /etc/letsencrypt/options-ssl-nginx.conf with DESIRED parameters?


I don’t see any option there:

configuration file

So I don’t think there is a global option.

So create your own file and deploy it.

Or create a deploy-hook script that replaces the standard file with your individual file.


Thank you for the prompt reply. I will file this as a bug report.


I believe Apache allows SSL related settings to be placed outside of any vhost and thus will be served globally. That said, and as you are NOT using Apache, you may also provide a similar stand “default” include line in each vhost that would make it very simple for you to make changes to the entire system from within just one single configuration file.

I really don’t see how certbot, or any acme client, is to be held responsible for the way a cert is used.
To me that security responsibility is clearly that of the admin; and it was there before, and will be there long after, any client is used to obtain a cert.

That said, if there is anything in your quest to better secure your system that anyone here can help with, or at least to point you in the right direction with, all you need do is ask.


Don’t you mean “feature request”? If it doesn’t already exist.


I think bug report and feature request are mostly interchangeable, right?

Perhaps one way this flag could be implemented could be to mirror the modern, intermediate, old settings used by and .

That way, a Certbot user could specify --tls [modern,intermediate,old] (modern, today, represents only TLSv1.2) and expect for it to be automatically kept up to date with whatever the best/moderate/most-compatible practices are at any point in time, respectively.

On the other hand, if you are being particularly picky about your TLS configuration, the Apache/nginx Certbot installers might not be for you, and you should stick to certonly.

1 Like

I thought Certbot had an open issue about more flexible Apache/Nginx TLS configuration options, but I just did a couple quick searches and couldn’t find anything. :confused:

There’s obvious value in having a --modern option or something, but the question is where you stop adding more and more complicated and specific options. :smile:

I’m 99% sure you can just edit the /etc/letsencrypt/options-ssl-* file.


There was: (and a few others related to that one).

But @bmw closed all of those as far as I can see because of “high flux on certbot” related to that matter. Although anything resembling a user setting for the TLS settings isn’t currently (two years later…) implemented.

1 Like

I tried to explain my (and many other people on the Certbot team’s) opinion on this issue at

We could potentially revisit that, but the short version is you should feel free to modify /etc/letsencrypt/options-ssl-nginx.conf with the values you want. What will happen is when we ship updates to that file in the future, we will print a warning once that there were updates to the file which we did not apply because of your modifications. That warning will include the copy of the updated file included in Certbot’s installation which you can look at and copy over changes if you wish.


Doesn’t sound really user friendly to me.

I will remove myself from this discussion, before I might say some stuff which I might regret later.

closed #13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.