It all depends on how much backwards compatibility you require. You can use your sites statistics to figure out how many customers/visitors you’ll be loosing when you disable TLSv1.0 and TLSv1.1. If that’s acceptable, it would be best to disable those indeed.
And why did you think the grade B was being caused by the Let’s Encrypt certificate? Did you think a Let’s Encrypt was less secure or something? Why do people still think that? Sigh…
[quote="Osiris, post:2, topic:131796, full:true"]
It all depends on how much backwards compatibility you require. You can use your sites statistics to figure out how many customers/visitors you'll be loosing when you disable TLSv1.0 and TLSv1.1. If that's acceptable, it would be best to disable those indeed.[/quote]
where do I find that information? I am using Apache on Debian
I never gave it much thought to be honest.
I can't seem to disable TLS 1.0 and 1.1 despite trying. I changed
I tried reloading the configuration, then when that did not work, I stoped the server and started it again. Still it seems TLS 1.0 and 1.1 and being supported.
It’s weird, as I purposely mis-typed a command in the ssl configuration file, and when I tried to reload Apache it reported an error.
root@NEW:/etc/apache2/mods-available# /etc/init.d/apache2 reload
[....] Reloading apache2 configuration (via systemctl): apache2.serviceJob for apache2.service failed.
See "systemctl status apache2.service" and "journalctl -xe" for details.
failed!
So Apache must be reading the file.
I typed the command suggested, and it would indicate that the virtual host is being read. Note there are some files with similar names, like kirkby and kirby, and the .com and .co.uk. Also with and without www - I suspect there’s a way around that, but I’m not sure how, so I have them in separate files.
root@NEW:/etc/apache2/mods-available# /usr/sbin/apachectl -S
AH00557: apache2: apr_sockaddr_info_get() failed for NEW
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:443 is a NameVirtualHost
default server dhars.org.uk (/etc/apache2/sites-enabled/dhars.org.uk-le-ssl.conf:2)
port 443 namevhost dhars.org.uk (/etc/apache2/sites-enabled/dhars.org.uk-le-ssl.conf:2)
port 443 namevhost g8wrb.co.uk (/etc/apache2/sites-enabled/g8wrb.co.uk-le-ssl.conf:2)
port 443 namevhost kirbymicrowave.co.uk (/etc/apache2/sites-enabled/kirbymicrowave.co.uk-le-ssl.conf:2)
port 443 namevhost kirkbymicrowave.co.uk (/etc/apache2/sites-enabled/kirkbymicrowave.co.uk-le-ssl.conf:2)
port 443 namevhost www.dhars.org.uk (/etc/apache2/sites-enabled/www.dhars.org.uk-le-ssl.conf:2)
port 443 namevhost www.g8wrb.co.uk (/etc/apache2/sites-enabled/www.g8wrb.co.uk-le-ssl.conf:2)
port 443 namevhost www.kirbymicrowave.co.uk (/etc/apache2/sites-enabled/www.kirbymicrowave.co.uk-le-ssl.conf:2)
port 443 namevhost www.kirkbymicrowave.co.uk (/etc/apache2/sites-enabled/www.kirkbymicrowave.co.uk-le-ssl.conf:2)
*:80 is a NameVirtualHost
default server dhars.org.uk (/etc/apache2/sites-enabled/dhars.org.uk.conf:1)
port 80 namevhost dhars.org.uk (/etc/apache2/sites-enabled/dhars.org.uk.conf:1)
port 80 namevhost g8wrb.co.uk (/etc/apache2/sites-enabled/g8wrb.co.uk.conf:1)
port 80 namevhost kirbymicrowave.co.uk (/etc/apache2/sites-enabled/kirbymicrowave.co.uk.conf:1)
port 80 namevhost kirkbymicrowave.co.uk (/etc/apache2/sites-enabled/kirkbymicrowave.co.uk.conf:1)
port 80 namevhost kirkbymicrowave.com (/etc/apache2/sites-enabled/kirkbymicrowave.com.conf:1)
port 80 namevhost www.dhars.org.uk (/etc/apache2/sites-enabled/www.dhars.org.uk.conf:1)
port 80 namevhost www.g8wrb.co.uk (/etc/apache2/sites-enabled/www.g8wrb.co.uk.conf:1)
port 80 namevhost www.kirbymicrowave.co.uk (/etc/apache2/sites-enabled/www.kirbymicrowave.co.uk.conf:1)
port 80 namevhost www.kirkbymicrowave.co.uk (/etc/apache2/sites-enabled/www.kirkbymicrowave.co.uk.conf:1)
port 80 namevhost www.kirkbymicrowave.com (/etc/apache2/sites-enabled/www.kirkbymicrowave.com.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33
Yes but Apache is notorious for running at all cost.
Which means that there may be multiple SSLProtocol statements.
And even though they all will be processed and must by syntaxically correct, the last one is the one that will eventually be used.
So technically that amounts to a parameter/statement overlap/overwrite - but Apache says nothing to you about it.
If I had to guess, I would say that you are modifying one in the default file or main config file and there exists another via an include statement.
Yes but you also need to consider proper programming.
If you will be using that one (recommended), then you should remove the other - as it serves no purpose (other than to confuse future editors)
root@NEW:/etc/apache2/mods-enabled# ls -l *ssl*
lrwxrwxrwx 1 root root 26 Aug 14 14:07 ssl.conf -> ../mods-available/ssl.conf
lrwxrwxrwx 1 root root 26 Aug 14 14:07 ssl.load -> ../mods-available/ssl.load
but Let's Encrypt only has one file,
/etc/letsencrypt/options-ssl-apache.conf
so it begs the obvious question, if I remove ssl.conf, should I remove ssl.load? Also, the Let's Encrypt file has warnings about editing the file manually
# 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.
Anyway, editing the Let's Encrypt file, to
# SSLProtocol all -SSLv2 -SSLv3
SSLProtocol all -SSLv2 -SSLv3 -TLSv1.1 -TLSv1
does disable TLS 1.0 and 1.1, so my website gets an A from SSL Labs.
SSLProtocol can be used per VirtualHost, perhaps for having backwards compatibility for some VirtualHosts, but not for others. Therefore, I wouldn't recommend removing all other SSLProtocol directives, unless you're absolutely certain it won't break anything.
All the TLS enabled virtual host files end with le-ssl.conf
It is pretty safe to say that they all have an include for SSLProtocol.
So I don’t see anything else left to break.
As for the two enabled mods, we should have a look at the full contents of those files before delete/removing/disabling either of them (completely).
Then you are misunderstanding their implementation.
They include that file only within the vhost config they modify - so it has zero effect on anything else you may be doing within your config.
But in this case, as you are not doing anything else, you really don’t need both.
