Monday, November 23, 2015

Long-term self-signed certs

While I'm a big proponent of using an enterprise-class certificate authority—either based on internal offline root/online issuing or public CAs—there are some instances when using a self-signed cert fits the bill. Unfortunately, most of the tools for creating a self-signed cert have defaults that result in less-than-stellar results: the digest algorithm is sha1, the cert is likely to have a 1024-bit key, and the extensions that define the cert for server and/or client authentication are missing.

With a ton of references discoverable on The Interwebz, I spent a couple of hours trying to figure out how to generate a self-signed with the following characteristics:

  • 2048-bit key
  • sha256 digest
  • 10-year certificate life (because, duh, I don't want to do this every year)
  • Accepted Use: server auth, client auth
It took pulling pieces from several different resources, documented herein:

Required Software

OpenSSL (command-line software)
Text editor (to create the config file for the cert)


  1. Create a text file that specifies the "innards" of the cert:
    default_bits = 2048
    encrypt_key = no
    distinguished_name = req_dn
    prompt = no

    [ req_dn ]
    CN={replace with server fqdn}
    OU={replace with department}
    O={replace with company name}
    L={replace with city name}
    ST={replace with state name}
    C={replace with 2-letter country code}

    [ exts ]
    extendedKeyUsage = serverAuth,clientAuth
  2. Run the following openssl command (all one line) to create the new private key & certificate:
    openssl req -x509 -config {replace with name of config file created above} -extensions "exts" -sha256 -nodes -days 3652 -newkey rsa:2048 -keyout host.rsa -out host.cer
  3. Run the following openssl command to bundle the key & cert together in a bundle that can be imported into Windows:
    openssl pkcs12 -export -out host.pfx -inkey host.rsa -in host.cer

What's happening

The text file sets up a number of configuration items that you'd either be unable to specify at all (the extensions) or would have to manually input during creation (the distinguished name details).

The request in the second step creates a 2048-bit private key (host.rsa) and a self-signed certificate (host.cer) with a 10-year lifetime (3652 days) with the necessary usage flags and SHA256 digest.

Friday, June 5, 2015

Resurrecting a TomTom XL

I'm a longtime fan of TomTom GPS devices, and thanks to my friends over at w00t, I've bought quite a few over the last score years, gifting some and reselling others.

While my most reliable mapping/routing service (recently) has been Waze on my iPhone, I've had an older TomTom XL·S 310/340 that I've kept in the company car, because sometimes Waze isn't always available or accurate—more because of Verizon CDMA limitations than anything else, but that's a different story—and having a dedicated device is super convenient.

I've been doing a bunch of travel in that company car, and the out-of-date map on the TomTom has become a bit of an annoyance, so unlike the XL I have for the personal car with lifetime map updates, I had a conundrum: do I purchase a new map ($45), subscribe to a year of updates ($49), punt and live with just the iPhone, or purchase a new device for home and move the one with lifetime maps to the company car and let the XL·S go to the electronics graveyard?

Because the device had been working flawlessly otherwise—with the exception of essentially zero battery life—I went ahead and selected the Map Update service.

After attaching the device to my PC and downloading several updates to the TomTom Home management application, the purchased map update was immediately available as an installable option. This old unit only had 2GB of local storage, so the old map had to be deleted before installing the new update; I bravely went ahead with the update process.

And after a goodly while, received errors that Home was unable to copy a file to the device, so it aborted the process. The management app itself suggested disconnecting, reconnecting and retrying the update, so I did that.

A common sight: errors writing to internal storage
Unfortunately, repeating the process didn't help: it might error out at a different file, but over and over, it would still fail.

As it happens, however, when the TomTom is attached to the PC, it shows up as a removable USB drive. When interacting with the Home application, it can create backup copies of the filesystem on the PC, and by comparing the data on the properly-updating home XL, I was able to make some assumptions about the XL·S filesystem. Instead of relying on the Home application to properly transfer the map to the device, I let Windows do it, copying the map data from the downloaded ZIP file to the removable device that was the TomTom's internal storage.

One problem: I was missing a file from the map download.

TomTom uses DRM to keep non-subscribers from using their maps. I was fine with that: as a subscriber, I should have rights to use those maps. However, some searching on the interwebz didn't net me any solutions. Luckily, I also thought to look on my PC where Home was running; there was a second download that had an "" file. Inspecting it, I found a .dct file; a quick google search informed me that this was my DRM key.

By putting the map and the DRM key on the TomTom manually, I now had a map that was usable by the device.

Or did I?

While I knew I could operate the device and use the map via the Home management app, the device refused to boot independently. Again, I used my google-fu and discovered that I should be able to wipe the local storage and get Home to reinstall the boot image and application software. And after wiping, but prior to doing the install, I performed Windows filesystem checks to make sure the TomTom local storage was functional and free of errors.

The Home tool worked as documented, but once again, after trying to add the map update, copy/install errors became my bane. I tried again to use Windows to copy the map update and DRM file, and lo... success! Not only would the device operate with the Home app, but it worked when independently powered.

So that's the trick:

  1. Wipe the TomTom local storage. Completely.
  2. Let Home reinstall the boot image and mapping application. This could require several restarts of the device, including hard resets (press and hold the power button until the TomTom logo appears and the drum sound is played).
  3. Extract the PC-based map to the TomTom local storage.
  4. Extract the .dct file to the map folder on the TomTom local storage.
  5. Restart the TomTom.
The device was working perfectly, so I continued with adding the MapShare corrections, and as the image above shows, I ran into another file transfer error. Following this error, the device refused to restart properly, getting stuck at the indemnity acknowledgement screen and spontaneously restarting. I reconnected the device and removed the most recent files from the map folder—the ones that didn't match the files received in the map update or the DRM file—and restarted the device, and it recovered nicely.

Update 2:
Before anyone asks: the .dct file that's the DRM key is specifically created by TomTom for my use on this device alone and is unusable on any other device, with any other map. The device serial number and map thumbprint are both part of the decryption key for DRM, so even if I didn't care about TomTom's IP rights and the possibility of litigation for it (which I actually do on both accounts), sharing the DRM file with the world wouldn't help anyone. So no, I will not share any of the files I received from TomTom in this update process.

Wednesday, June 3, 2015

Maximum NTFS Volume Expansion

A peer recently had an issue when working on a client system: After adding a second shelf of SAS-attached drives to a physical Windows Storage Server and doubling the available capacity of the environment from ~20TB to ~40TB, he was unable to extend the existing NTFS volume after extending the SAS array group.

The error was "The volume cannot be extended because the number of clusters will exceed the maximum number of clusters supported by the filesystem."
The original volume was reportedly formatted "using the defaults," which under most circumstances would mean it was using 4K clusters. Why wouldn't it allow extending the volume?

Because NTFS (as currently implemented) has a cluster limit of 232-1 clusters per volume.

When you "do the math," that cluster limit does impose some hard limits on the maximum size of the NTFS volume, irrespective of the actual drive space that is available for the volume. And trying to use tricks like dynamic disks and software RAID won't help: those tricks modify the underlying disk structure, not the NTFS filesystem that "rides" on top of it.

Max NTFS Volume by Cluster Size
size (B)
512 2,199,023,255,040 2,147,483,648 2,097,152 2,048 2
1024 4,398,046,510,080 4,294,967,295 4,194,304 4,096 4
2048 8,796,093,020,160 8,589,934,590 8,388,608 8,192 8
4096 17,592,186,040,320 17,179,869,180 16,777,216 16,384 16
8192 35,184,372,080,640 34,359,738,360 33,554,432 32,768 32
16384 70,368,744,161,280 68,719,476,720 67,108,864 65,536 64
32768 140,737,488,322,560 137,438,953,440 134,217,728 131,072 128
65536 281,474,976,645,120 274,877,906,880 268,435,456 262,144 256

We knew that we had a functioning 20TB volume, so we verified my theory that the volume was actually formatted with 8K clusters (the smallest size that would support 20TB) using DISKPART's FILESYSTEM command. Sure enough: 8192 was the cluster size.

We gave the client several options for addressing the issue, including the purchase of software that could "live adjust" the cluster sizing. In the end, the client chose the "migrate->reformat->migrate" option, and while it took a long time to perform (20TB is a lot of data!), it was successful.