I’ve just completed my first ADFS 4.0 implementation and I’m quite astonished at just how many stupid, petty and easily resolved bugs it suffers from.

Case in point, if you change the service certificate it doesn’t change the https certificate bindings. This means that even though your ADFS server is using your new certificate for its communications, the web service is still using the old one. It’s not IIS any more so you have to manually recreate the bindings via netsh.

There also seems to be a bizzare issue that only affects IE whereby if your ADFS farm name DNS record is a CNAME rather than an A record, any authentication attempts will fail with a 400 BAD REQUEST error. This doesn’t affect other browsers because why would it, it’s a fucking mental thing to do.



If you’ve configured the Server Authentication Certificate Template GPO option, which determines the certificate that the machine uses for Remote Desktop connections, and applied it to 2008 R2 or older servers then you may find that you’re getting a lot of duplicate certificates being issued. It’s a problem with an easy solution but it’s not an obvious one.

You see, if you read the documentation for the setting (something which is helpfully not included in the GPO explanation text in the GPMC) you’ll soon discover that:

Important
You must set the certificate template’s attributes Template display name and Template name to the same value.

Due to a disparity in the way the API checks to see if a certificate already exists on the machine for this purpose if the Template Name is not the same as the Template Display name it fails to identify that it already has a matching certificate and so requests a new one.

This problem is resolved in Server 2012 R2. It’s possibly resolved in Server 2012 as well but I don’t have a box to hand I can test with.

As far as I can tell the “Do not automatically reenroll if a duplicate certificate exists in Active Directory” option has no impact on this issue.



Scenario: During an AD migration I needed to remove all of the certificates from a migrated user’s local store which had been issued by the old domain’s CA. Not simply for housekeeping reasons but because the new domain makes use of credential roaming and we didn’t want a load of old certificates taking up space in AD for no reason.

The following code will remove all certificates issued by from the Personal (My) store of the currently logged in user. If you wanted to narrow the criteria you can also filter on any of: Subject, Issuer, Thumbprint, FriendlyName, NotBefore, NotAfter or Extensions. You can also target different containers and switch between User (CurrentUser) and Machine (LocalMachine) certificate stores. As far as I’m aware there’s no way to do this for a user that isn’t currently logged in.

$Store = New-Object System.Security.Cryptography.X509Certificates.X509Store("My","Currentuser")
$store.Open("MaxAllowed")
$certs = $store.certificates | ?{$_.Issuer -eq "CN=My Issuing CA 1, DC=my, DC=domain"}
$certs | %{$store.remove($_)}
$Store.close()

See also https://www.angryadmin.co.uk/?p=600



If you’re using certificate-based authentication for your wired or wireless network and have the Lync 2013 client installed then you may find that your users start getting prompted to select a certificate when connecting to the network for the first time. This is because the Lync client issues users certificates with blank Subject fields and Windows can’t work out which certificate to use.

There’s a hotfix available from Microsoft here: http://support.microsoft.com/kb/2710995/en-us but unfortunately it’s not available via WSUS so you’ll have to push it to your clients “manually”. Personally I would have thought that certificate-based wireless authentication in environments running Lync were relatively common, enough to justify a proper patch, but apparently not.



I spent a while recently wondering if it was possible to have certificates follow users between machines, in this case certificates used for 802.1x authentication, because I didn’t want our CA issuing a new certificate every time a user logged onto a new machine. It seemed logical that such a facility must exist but I couldn’t find anything useful until I stumbled upon it almost by accident while looking for something else certificate-related.

What I was after is Credential Roaming, which is basically a roaming profile system for certificates (and saved user credentials but that wasn’t really a consideration). Once enabled, credential roaming will store user credentials attached to their AD account object and download them to the local machine on logon, then on log off sync everything back up to the AD object again. Obviously there are things to consider here, especially if you have a lot of users and they have a lot of certificates, but you can set limits on the maximum store size (the default is 64k) and certificates are pretty small anyway – plus most of the features only work with Vista and later, but frankly if you’re still running XP then you’ve got to expect things not to work properly.



In light of today’s news that OpenSSL has been pretty broken for the best part of a year (see: here, amongst others), I decided to revisit the SSL configuration on my Forefront TMG servers with regard to their published websites. Digging around the internet I came across several useful pieces of information that I thought I’d share.

First up is Qualys’ SSL Server Test tool @ https://www.ssllabs.com/ssltest/index.html, which will give you a report on the state of your SSL setup, mine had some issues mostly due to oversights on my part.

Next, is this article on ISAServer.org which runs you through some non-obvious-but-crucial security tweaks you can make to your TMG server to improve its protocol support and avoid a couple of renegotiation issues.

Finally, I was directed to the IIS Crypto tool from Nartac Software, which doesn’t do anything you couldn’t do by hand (and does go back over a couple of protocol tweaks from the previous link), but does make it one hell of a lot easier. Don’t be fooled by the name, the windows crypto settings it changes are server-wide and don’t just affect IIS.

So, with a couple of hours of work I went from an F (Oops, that’ll teach me to forget about disabling SSLv2) to an A and now properly implement PFS for clients that support it.



Update: with appropriate irony I managed to bollocks up the formatting myself. Sorry, should be fixed now.

Courtesy of: http://www.orcsweb.com/blog/james/powershell-ing-on-windows-server-how-to-import-certificates-using-powershell/

However, the formatting is a bit borked so I’ve reproduced it here.

$certrootstore can be either LocalMachine or CurrentUser
$certstore can be any of: AddressBook, AuthRoot, CA, Disallowed, My, Root, TrustedPeople, TrustedPublisher

The script assumes the certs are in the same location as the script, if not you’ll need to modify the paths as well as the filenames.

function Import-Certificate{
     param([String]$certPath,[String]$certRootStore,[String]$certStore)
     $pfx=new-object System.Security.Cryptography.X509Certificates.X509Certificate2
     $pfx.import($certPath)
     $store= new-object System.Security.Cryptography.X509Certificates.X509Store($certStore,$certRootStore)
     $store.open("MaxAllowed")
     $store.add($pfx)
     $store.close()
}
 
Import-Certificate "$(Split-Path $MyInvocation.MyCommand.Path)\TrustedRoot.cer" "LocalMachine" "root"
 
Import-Certificate "$(Split-Path $MyInvocation.MyCommand.Path)\TrustedIssuingAuthorty.cer" "LocalMachine" "CA"