Sslciphersuite order violates ncsc guidelines

Feature Requests
1

Testing TLS/SSL of my website by using the Dutch National Cyber Security Centre’s (NCSC) guidelines (https://english.ncsc.nl/publications/publications/2019/juni/01/it-security-guidelines-for-transport-layer-security-tls). When I go to https://internet.nl to test my domain, I receive warning messages about the ciphers my site is using. Some of the ciphers are phased out, others are in an incorrect order (the guideline apparently recommends a descending order) and some other cipher related messages.

Is it possible for letsenrypt to generate an SSLCipherSuite in accordance with NCSC’s guidelines?

2

Hi @masteryoda,

Welcome to the community forum!

I have a few questions for you;

  1. What is the domain you’re testing?
  2. What client did you use to issue a certificate for your domain?
  3. Did the client automatically configure your webserver vhost?
  4. What webserver are you using?

I am going to assume you’re using Apache specifically because of the keyword SSLCipherSuite https://httpd.apache.org/docs/current/mod/mod_ssl.html

I believe the list of cipher suites at https://github.com/certbot/certbot/blob/master/certbot-apache/certbot_apache/_internal/centos-options-ssl-apache.conf#L11 is based on https://ssl-config.mozilla.org/.

2 Likes
3

Hi Phil_LE,

Domain I’m testing is nextcloud.jahetken.net.
I used Certbot as client to issue the certificates.
No, Certbot did not generate the vhosts, but it did create a file called “options-ssl-apache.conf” that contains the SSLCipherSuite list.
Indeed, I’m using Apache.

4

Please see the following certbot document about cipher suite choices.

According to SSLCipherSuite · Issue #5354 · certbot/certbot · GitHub,

Once you've used Certbot to install your certificate, you can change the TLS config and Certbot will not change it back when running certbot renew.

5

Can you fill out answers to the other questions in the questionnaire below?

Can you also show us the Apache virtual host(s) involved? And any other SSL-related settings from ssl.conf or httpd.conf or other included files?

The options-ssl-apache.conf file doesn’t do anything on its own. Apache doesn’t look in /etc/letsencrypt/ unless it’s told to. If you use Certbot’s apache installer to configure Apache, it will add an Include directive to use it. If you used certbot certonly, or removed the Include from Apache’s configuration, that file won’t be involved.

Looking at the SSL Labs report for your website, it looks like you’re not using the Certbot Apache configuration – your settings are more secure than it is!

(Certbot’s Apache defaults are based on an older version of Mozilla’s intermediate configuration. They’re still fine, but contain some bottom-priority, mediocre settings that security scanners will warn about and that could be removed.)

Taking a quick look at what the Internet.nl scan says, not everything it says looks necessary or common (though not bad). Copying Mozilla’s current modern or intermediate configuration and ignoring any remaining complaints Internet.nl has would work.

Additionally, SSL Labs reports an issue with how Apache is configured: Your certificate is sent twice, which is incorrect, wastes bandwidth and will make some clients unable to access your website. There’s probably an issue with how SSLCertificateFile and SSLCertificateChainFile are set.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

6

By the way (although your particular ciphersuite configuration may well not have been set up by Certbot), Certbot normally uses a version of the recommendations from Mozilla at

https://ssl-config.mozilla.org/

I looked at this for a long time before we settled on that choice (including looking at an earlier version of the Dutch NCSC’s recommendations!). We did have an issue proposing the creation of Certbot options to automatically set ciphersuite preferences according to the user’s choice of recommendation sources, but we’ve ultimately decided that this would probably be confusing, challenging to maintain, and little-used since the Mozilla recommendations are also created and updated based on expert input and are acceptable to a very wide range of users.

If you look into this and find that there is a big discrepancy between Mozilla’s and NCSC’s current recommendations, I’m happy to try to help get you in touch with the people involved in creating both sets of recommendations and see if they can offer some rationales for the differences and/or try to bring their recommendations closer together in future updates.

2 Likes
7

The (:443) vhost contains an Include for options-ssl-apache.conf at the end.
Domain name is already provided.
My web server is (include version): Apache/2.4.25 (Raspbian)
The operating system my web server runs on is (include version): Debian 9 Stretch (Raspbian)
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.28.0

I don’t understand why the certificate is sent twice.

8

It could indeed be that NCSC’s guidelines and recommendations are a bit extreme. After all, my site is running fine, despite the messages.
I understand that youǘe settled, for reasons of maintainabality, for just one cipher suite (in this case Mozilla).
But I was wondering if Certbot could contain an option where the user could specify a cipher suite of choice. Apparently this was considered, if I understand you
correctly, but not implemented. This is fine with me.

9

Did you add that? Or use Certbot's Apache installer?

What command did you run to issue the certificate?

Edit: I forgot to include:

You have complete freedom to edit options-ssl-apache.conf or Apache's configuration files as you like. If you want to use custom settings, Certbot won't stop you.

10

I initially used the TLS-SNI-01 challenge to generate my LE certificate using Certbot. But since this was no longer supported, I switched to the HTTP-01 challenge. This required port 80 to be open. This also meant I had to modify /etc/apache2/sites-available/nextcloud-le-ssl.conf (which was generated before by Certbot and contained just the one :443 vhost) to now also contain a :80 vhost (containing a Redirect directive pointing to the https url of my website). This has been and still is working fine.

Here’s what /etc/apache2/sites-available/nextcloud-le-ssl.conf looks like:

<VirtualHost 192.168.178.35:80 [2001:984:e2cf:1:df84:6298:91b:80b0]:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request’s Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
ServerName nextcloud.jahetken.net

   # Redirect requests to HTTPS 
   Redirect permanent "/" "https://nextcloud.jahetken.net/" 

   # Available loglevels: trace8, ..., trace1, debug, info, notice, warn, 
   # error, crit, alert, emerg. 
   # It is also possible to configure the loglevel for particular 
   # modules, e.g. 
   #LogLevel info ssl:warn 

   ErrorLog ${APACHE_LOG_DIR}/error.log 
   CustomLog ${APACHE_LOG_DIR}/access.log combined 

   # For most configuration files from conf-available/, which are 
   # enabled or disabled at a global level, it is possible to 
   # include a line for only one particular virtual host. For example the 
   # following line enables the CGI configuration for this host only 
   # after it has been globally disabled with "a2disconf".  
   #Include conf-available/serve-cgi-bin.conf
DocumentRoot "/var/www/html/nextcloud" ServerName nextcloud.jahetken.net ServerAdmin webmaster@localhost 
   <IfModule mod_headers.c> 
      Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" 
   </IfModule> 

   ErrorLog ${APACHE_LOG_DIR}/error.log 
   CustomLog ${APACHE_LOG_DIR}/access.log combined 

   <Directory /var/www/html/nextcloud/> 
      Options +FollowSymlinks 
      AllowOverride All 

      <IfModule mod_dav.c> 
         Dav off 
      </IfModule> 

      SetEnv HOME /var/www/html/nextcloud 
      SetEnv HTTP_HOME /var/www/html/nextcloud 
      Satisfy Any 

   </Directory> 

   SSLCertificateFile /etc/letsencrypt/live/nextcloud.jahetken.net/cert.pem 
   SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.jahetken.net/privkey.pem 
   SSLCertificateChainFile /etc/letsencrypt/live/nextcloud.jahetken.net/fullchain.pem 
   Include /etc/letsencrypt/options-ssl-apache.conf
11

cert.pem contains your cert. fullchain.pem contains your cert and chain. Combined, that sends cert + cert + chain.

If you have Apache 2.4.8 or newer, you can use:

   SSLCertificateFile /etc/letsencrypt/live/nextcloud.jahetken.net/fullchain.pem 
   SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.jahetken.net/privkey.pem

If you have an older version of Apache, you need to use:

   SSLCertificateFile /etc/letsencrypt/live/nextcloud.jahetken.net/cert.pem 
   SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.jahetken.net/privkey.pem 
   SSLCertificateChainFile /etc/letsencrypt/live/nextcloud.jahetken.net/chain.pem

I'm confused, though. Is that part of your port 80 virtual host? If so, SSL is off and those SSL settings are being ignored, right? Do you have another port 443 virtual host? Where is HTTPS actually on? Did you paste parts of two virtual hosts in the post?

1 Like
12

Sorry for the confusion. I see now that during copy/paste of the .conf content certain parts were skipped.
The file /etc/apache2/sites-available/nextcloud-le-ssl.conf contains 2 vhosts: one for 80 and the other one for 443. The SSLCertificate… lines are part of the 443 vhost. The 80 vhost was only added by me manually to enable renewing the certificate using the HTTP-01 challenge. All port 80 requests to my site are redirected (in the vhost) to 443. Hope this clarifies the situation a bit.

I’m running Apache 2.4.25. I’ve copied the 2 SSLCertificate… lines as suggested. The SSL Labs still reports A+ grade. I’m not sure how to tell if certificates were sent twice, but it still says that 2 certificates were provided. Is this what you referred to earlier? The #2 certificate is called Let’s Encrypt Authority X3, as far as I’m able to tell.

13

No, it was different before. It's correct now. :slightly_smiling_face: Before, SSL Labs said that 3 certificates were provided (your certificate, your certificate again, and Let's Encrypt Authority X3) and showed a warning saying that there were "extra certificates".

1 Like
14

Thanks for helping getting this fixed :clap:

1 Like
15

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