Category Archives: networks

Windows 10 and “No internet, secured”

Lots of people seem to have problems with internet access after upgrading to Windows 10, according to all sorts of discussions on the web.

Here’s one possible cause: the firewall.

I was working on a Dell laptop recently which had these symptoms, i.e. finding and connecting to the network (wifi or wired), but not getting as far as the internet.

It turned out that Comodo Internet Security’s firewall was getting in the way. I disabled the CIS firewall, and the connection instantly worked. After rebooting, I restored the firewall, and the connection still worked.

Self-signed multiple-domain SSL certificates

I’ve finally worked out how to create self-signed SSL certificates for multiple domain names with openssl. 

These notes relate to Debian GNU/Linux, but the principles will apply to other operating systems.

The first step to make the process easier and repeatable in the future is to copy the default configuration file from /etc/ssl/openssl.cnf to a working directory where you can adapt it

Let’s assume that you’ve copied /etc/ssl/openssl.cnf to ~/project-openssl.cnf.  Edit the new file and set the various default values to the ones that you need — that’s better than having to respond to openssl’s prompts every time you run it.

For real non-self-signed certificates, you would generate a certificate signing request (.csr) file, ready for a certificate authority to sign it for you.  In that case, you need to follow the instructions at

But for a self-signed certificate, the subjectAltName has to go in a different place.  Make sure you’ve got this line present and un-commented in the [req] section of the config file:

x509_extensions = v3_ca

and then this goes at the end of the [v3_ca] section:

subjectAltName = @alt_names
DNS.1 =
DNS.2 =
DNS.3 =
DNS.4 =

There is (apparently) a limit to the number (or total length) of the alternate names, but I didn’t reach it with 11 domain names.

It’s also possible to add IP addresses to the alt_names section like this:

IP.1 =
IP.2 =

Then to create the key and self-signed certificate, run commands similar to these:

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout project.key -out project.crt -config ~/project-openssl.cnf
cp project.crt /etc/ssl/localcerts/
mv project.key /etc/ssl/private/

Note that I move (rather than copy) the key to the private directory to avoid leaving a copy of it lying around unprotected.

You can check that the certificate contains all the domains that you added by running this:

openssl x509 -in project.crt -text -noout | less

Alternative approach

I haven’t tried this, but according to it’s also possible to create a CSR and then self-sign it like this:

openssl x509 -req -days 3650 -in project.csr -signkey project.key
 -out project.crt v3_req -extfile project-openssl.cnf


D-Link DSL-320b in bridged mode

photoI’m using a DSL-320B (version D2, firmware EU_1.25) as a simple ADSL modem, together with a router running OpenWRT.

Which ought to have been straight-forward, but it took me a while to find the right settings.

(Yes, it would be possible to get the DSL-320B to do the ADSL connection, and just connect via ethernet to the router, but that wouldn’t allow me to use the native IPv6 connection that I’ve signed up for.)

My ISP is UKFSN, a retailer for Entanet, who provide an ADSL2+ connection.  The published settings, which I’ve used for combined ADSL routers in the past, are:

  • VCI: 38
  • VPI: 0
  • Encapsulation: PPPoA VCMUX

For some reason, bridged mode with VC-MUX didn’t work — I tried all combinations of bitswap and SRA.

The settings that finally did work are:

ADSL Setup

  • Manual setup
  • Bridge Mode
  • Connection type: 1483 Bridged IP LLC
  • VPI: 0
  • VCI: 38

Advanced ADSL

  • Modulation type: Autosense
  • [  ] Bitswap enable (i.e. disabled)
  • [x] SRA enable (i.e. enabled)

When setting it up, I gave the DSL-320B address  But while bridging is actually happening, it doesn’t respond to that address, despite having a suitable static route set up.  That’s probably to be expected: as a bridge, the device doesn’t have an IP address of its own.