Strong Ciphers for Apache, nginx and Lighttpd
Mozilla SSL Configuration Generator
Fantastically helpful bit of kit to help configure your servers.
Looks like NPS only supports TLS1.0 by default. So if you go restricting your ciphers too much you’ll find none of your NPS clients able to connect using EAP.
That’s a bit of a problem when you have an 802.1x secure network and every client is expected to authenticate. If a cipher is not available on both client and server then you’ll get a client unable to connect or reconnect when their sessions require.
So in order to expand the ciphers supported by newer systems you should ensure you can deliver them over a wider number of protocols , including TLS1.1 and 1.2.
To add these registry values, follow these steps:
|TLS version||DWORD value|
Any OR’ed combination of these values will enable the corresponding protocols. By default, TLS 1.0 is enabled. If any invalid value is configured, TLS 1.0 will be used.
Support for TLS1.0, 1.1 and 1.2 = 0xFC0. TLS1.1 and 1.2 only = 0xF00.
Create and set the following registry key value:
Hex value 800 = 2048
Disable the ciphers that use Diffie-Hellman by adding
!DHE into your ciphers list
Now when I run
nmap I get a very reduced list of available ciphers. Hopefully all my clients will be able to make use of one of them!
Following on from the Windows vulnerability for SWEET32, Here’s how to resolve the same issue with Tomcat 8. This use the OpenSSL format string for ciphers, so can also be applied to anything using the same cipher list.
Simply by adding the
!ECDHE-RSA-DES-CBC3-SHA to your existing
: delimited cipher list disables the cipher on the server. The prefix
! means NOT – which disables the cipher.
Alternatively you can simply disable all ciphers using triple DES using
When you encounter some other cipher vulnerability listed in you Nessus scan just copy the cipher name into the list prefixed with
!. Be wary that some of your connecting applications may not like this. So keep a log of what you added so you can rollback.
To use the AES 256 bit ciphers, it is necessary to install the JCE Unlimited Strength Jurisdiction Policy Files.
By default Tomcat gets installed with HTTP only and a number of default applications. Previously I linked documents on how to secure Tomcat. But put simply just delete the folders under
webapps that you don’t need for your application. So you pretty much get left with
manager in there.
My next step was to try to figure out how to get the connection changed from HTTP to HTTPS and apply a valid certificate to the connection.
You can specify what cipher suites Java uses by editing the file:
This file must also be used by the Java application. So if the application overrides this by using a
-Djava.security.properties=<URL> setting then you should modify the file specified by
The ciphers to disable are listed in the following keys:
The file is documented, so you should be able to figure out the required settings from the examples.
jdk.tls.disabledAlgorithms property in the policy file controls TLS cipher selection. The
jdk.certpath.disabledAlgorithms controls the algorithms you will come across in SSL certificates.
Oracle has more information about this here.
When we setup some virtual machines from a template and used temporary names for them because we needed to replace existing machines that were currently running on the domain, it seems the rename of the machine didn’t fully do the job after we decommissioned the old and renamed the new.
All the domain membership stuff went ok, but the certificate issued to the machine still had the temporary name. Even after deleting the wrongly named certificate we’d still get a certificate issued with the same name.
A quick trawl in the registry revealed that the following key needed to be changed to get the correctly issued certificate:
Once this was done the certificate was received with the correct name.
After buying a cheap SSL certificate I found I’d missed something important during the install.
Usually it’s just a case of copy the certificate and key files to /etc/ssl/certs and /etc/ssl/private, respectively and then pointing the Nginx config at them to get it working.
Well all was well in the GUI world of Linux and Windows browsers. But My Android said the certificate wasn’t trusted. Looks like there’s some CA intermediates that need sorting.
I’m beginning to think this is going to be a blog about SSL certificates as most of the articles seem that way inclined just now!
When it comes to IIS serving a single web site over HTTPS it’s pretty straight forward. Select bindings and add a new one for HTTPS. You should notice that at this stage you can’t enter in a host name as that field becomes greyed out when you choose HTTPS. This is the crux of our problem. You want to run another HTTPS site on port 443, but can’t.
Well you may not be able to do this from the GUI, but you can from the command line using an admin script.
Having updated the CA certificate it’s time to start rolling out the new SHA-256 algorithm to the other Windows servers. Group Policy (GPO) takes care of the new CA certificate distribution and the clients and servers are getting that in their Trusted Root stores automatically. But the servers have a range of certificate expiry dates and won’t expire for some time. So to satisfy the vulnerability scan results we’re having to update each server as we get to them.
This means visiting each server running MMC, adding in the Certificate Snap-in for the Local Computer and then renewing the certificate(s). Once that’s done it’s a case of telling the applications to use the new certificate.
Typically this means choosing the certificate in the Terminal Services Session Host management console, setting IIS to use the new certificate and updating SQL so that uses the new certificate too.