Stuff I'm Up To

Technical Ramblings

Strong Ciphers — February 16, 2017
TLS and NPS — February 9, 2017


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.

Ensure you have the required update patch for your system

To add these registry values, follow these steps:

  1. Click Start, click Run, type regedit in the Open box, and then click OK.
  2. Locate and then click the following subkey in the registry:
  3. On the Edit menu, point to New, and then click DWORD Value.
  4. Type TlsVersion for the name of the DWORD, and then press Enter.
  5. Right-click TlsVersion, and then click Modify.
  6. In the Value data box, use the following values for the various versions of TLS, and then click OK.
    TLS version DWORD value
    TLS 1.0 0xC0
    TLS 1.1 0x300
    TLS 1.2 0xC00

    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.

  7. Exit Registry Editor, and then either restart the computer or restart the EapHost service.


Support for TLS1.0, 1.1 and 1.2 = 0xFC0. TLS1.1 and 1.2 only = 0xF00.


SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (Logjam) — February 3, 2017
SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (Logjam) – Tomcat —
SSL 64-bit Block Size Cipher Suites Supported (SWEET32) – Tomcat —

SSL 64-bit Block Size Cipher Suites Supported (SWEET32) – Tomcat

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 !3DES.

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.

Tomcat and HTTPS — January 31, 2017

Tomcat and HTTPS

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 host-manager and 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.

Continue reading

Java SSL/TLS Ciphers — January 30, 2017

Java SSL/TLS Ciphers

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<URL> setting then you should modify the file specified by <URL>.

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.

The 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.

Continue reading

Renamed Machine & Wrong Certificate Name — January 27, 2017

Renamed Machine & Wrong Certificate Name

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:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName

Once this was done the certificate was received with the correct name.

Comodo SSL Certs & Android — October 10, 2016

Comodo SSL Certs & Android

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.

Continue reading

Cheap SSL Certificates —
IIS & Multiple HTTPS Bindings — October 7, 2016

IIS & Multiple HTTPS Bindings

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.

Continue reading

MSSQL Server SSL Certificate — October 5, 2016

MSSQL Server SSL Certificate

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.

Continue reading