Category Archives: Windows

Common Problems installing a Custom Certificate for RDP

There are a quite a few good guides for configuring your own CA signed certificate for RDP; however, details it’s easy to gloss over and most of the troubleshooting is buried in the comments:

  • Create an RDP certificate with an RSA key. The signing key of the CA does not matter.
  • Create an RDP certificate with the TLS (web) Server EKU, not the Remote Desktop EKU.
  • Add the certificate to the Personal certificate store, not the Remote Desktop certificate store.

Example errors:

Error log when using an RDP certificate with an ECDSA key.

An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The TLS connection request has failed.
Schannel with an ECDSA certificate

Windows 10 and Remote Desktop 10 on macOS report an Unknown/Invalid EKU.

Unknown Key Usage
Unknown Key Usage on Windows 10

Set-WmiInstance error trying to use a certificate in the Remote Desktop certificate store.

Set-WmiInstance : Invalid parameter

WMIC error trying to use a certificate in the Remote Desktop certificate store.

wmic error: Description = Invalid namespace

Adding OIDs to XCA

Adding OIDs to XCA is a straightforward process. I was able to follow the official guide at https://hohnstaedt.de/xca-doc/xca-13.html with minimal issues.

First, ensure you download XCA v2.x from the official download page https://hohnstaedt.de/xca/index.php/download. The instructions didn’t make sense at first since I was running xca v1.4.1.

Create a file named “oids.txt” in the user’s XCA directory:

  • Windows: C:\Users\<username>\AppData\Roaming\xca
  • macOS: ~/Library/Application Support/data/xca
  • Linux: ~/.xca
C:\Users\Admin\AppData\Roaming\xca\oids.txt
oids.txt on Windows

Add the OID(s) to oids.txt using the format “<oid> : <short_name> : <long_name>”. In the example below, I added a (Microsoft) Remote Desktop Authentication OID (1.3.6.1.4.1.311.54.1.2):

1.3.6.1.4.1.311.54.1.2: rdpAuth: Remote Desktop Authentication
oids.txt content

Copy the eku.txt file from the XCA installation location to the user’s XCA directory:

  • Windows: C:\Program Files\xca
  • macOS: /Applications/xca.app/Contents/Resources
    This can be accessed through the command line or right clicking on the xca application and selecting “Show Package Contents”
  • Linux: /usr/share/xca or /usr/local/share/xca

Note: The whole file eku.txt file must be copied, because xca only parses the first eku.txt it encounters.

Add a line to the user’s eku.txt referencing your new EKU:

rdpAuth
Add the new EKU to the list of pre-defined EKUs

Close and re-open XCA and your new EKU will be available:

xca: Remote Desktop Authentication EKU
XCA Key Usage Tab

After adding the Remote Desktop Authentication EKU, I found out it is no longer supported/recognized. The Microsoft Remote Desktop 10 app on macOS and Windows 10 both report the EKU as invalid/unknown.

Unknown Key Usage
Unknown Key Usage

Blocking Windows Updates

To block Windows 10 Updates, block lookup of the following domains:

  • *.windowsupdate.microsoft.com
  • *.update.microsoft.com
  • *.windowsupdate.com
  • *.wustat.windows.com
  • *.ntservicepack.microsoft.com
  • *.stats.microsoft.com
  • *.mp.microsoft.com
  • *.data.microsoft.com
  • *.events.data.microsoft.com

This list differs from the lists I’ve been able to find published by Microsoft; notably stats.microsoft.com, mp.microsoft.com, and data.microsoft.com. I developed the list above by watching DNS queries while checking for updates and blocking domain names until the check for updates failed.

Since I’m using Dnsmasq, I’ve added a config file in /etc/dnsmasq.d/ so I can easily disable the blocking when I am ready to install updates:

address=/windowsupdate.microsoft.com/#
address=/update.microsoft.com/#
address=/windowsupdate.com/#
address=/wustat.windows.com/#
address=/ntservicepack.microsoft.com/#
address=/stats.microsoft.com/#
address=/mp.microsoft.com/#
address=/data.microsoft.com/#
address=/events.data.microsoft.com/#

Solved: Word 2013 does not immediately save files

After repeatedly working on a file, hitting save, attaching the file to an email, and realizing I sent the unsaved version of the file; I decided to dig into this odd behavior of Microsoft Word 2013.

My initial workaround was completely closing all Word windows, but I didn’t want to have to close all of my documents to save one.

After a little more digging a simple setting solves this problem. Go to File -> Options -> Advanced. Scroll down to Save and uncheck "Allow background saves".