ADFS : The strange case of the wrong SAML signature

A customer was working fine and then within a short space of time Dev, QA and Production all stopped working for a Java SAML SaaS product with the error:

Microsoft.IdentityModel.Protocols.XmlSignature.SignatureVerificationFailedException: MSIS0038: SAML Message has wrong signature. Issuer: 'xxx'.

Back in the day, there was a bug in ADFS that produced this error but it was misleading - it had nothing to do with certificates. But I could find no reference to a new bug.

Coincidentally, the ADFS certificates rolled around the same time.

That's where we put our effort and nothing helped. We turned rollover off and on, we used the "urgent" construct to force new certificates etc.

Nothing doing :-(

In desperation, I asked the supplier to send us the contents of the key store.

Then I noticed that the thumbprint of their signing certificate didn't match the one in ADFS,

This certificate expires in 2026. Why on earth did in change?

So I did some digging. Turns out this was the "new kid on the block" syndrome. The guru who normally did this had left and they gave the job to a newbie.

He looked at the document he was given but did not realise that this was "as-built" not "deployment".

So every time he built a new build, he changed the signing certificate. He didn't supply it to ADFS.

That's why the error progressively rolled. The company wanted a fix and as the deployment rolled through the various environments, it broke.

Sometimes, you have to look outside of the square.

Again, best practice and supplying metadata would have helped.

To quote Sherlock Holmes:

"When you have eliminated the impossible, whatever remains, however improbable, must be the truth".

Enjoy!

Visual Studio : Unable to start debugging on the web server. A debugger is already attached.

Came across this error when we had more than one person working on a VS project which is hosted on a VM.

The setup script for a new user gives each person their own web site.

Because there is only one version of IIS, when multiple people try and debug their version, you get the error:

Unable to start debugging on the web server. A debugger is already attached.

The solution turned out to be simple. The debugger attaches to a process which is itself attached to an application pool.

Give each user an application pool i.e. make a new one in IIS Manager.

Attach each person's web site to their application pool in IIS Manager.

Just make sure that the pool is configured the same way as the original e.g. same .NET framework and managed pipeline.

Problem solved!

Enjoy!

Certificates : Finding a thumbprint and using PowerShell

I always use mmc as the wizard to manage certificates but I needed to do some certificate work and I wondered if there was a way of automating it.

Turns out you can with PowerShell.

Instead of \cd to a drive, you go to the certificate store with:

cd CERT:\\

Then:

PS Cert:\> dir

Location   : CurrentUser
StoreNames : {ACRS, SmartCardRoot, Root, Trust...}

Location   : LocalMachine
StoreNames : {TrustedPublisher, ClientAuthIssuer, Remote Desktop, Root...}

Then we can do things like:

dir .\\CurrentUser\My

dir .\\LocalMachine\My

which gives a list:

PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\My

Thumbprint                          Subject
----------                                -------

If we want to see the structure, we can do:

PS Cert:\currentuser> get-childitem

which gives:

Name : ACRS

Name : SmartCardRoot

Name : Root

Name : Trust

Name : AuthRoot

Name : CA

Name : UserDS

Name : Disallowed

Name : My

Name : TrustedPeople

Name : TrustedPublisher

Name : ClientAuthIssuer

If we want to find a certificate with a particular thumbprint, we can use:

Get-ChildItem -Path 'thumbprint' -recurs

which gives:

PS Cert:\> Get-ChildItem -Path 'CD...72' -recurse

PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\Root

Thumbprint                                Subject
----------                                -------
CD...72  CN=Microsoft Root Certificate Authority, DC=microsoft, DC=com

PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root

Thumbprint                                Subject
----------                                -------
CD...72  CN=Microsoft Root Certificate Authority, DC=microsoft, DC=com

or we can get a list:

Get-ChildItem -Path 'thumbprint' -recurse | Format-List -Property *

which gives:

PSPath                   : Microsoft.PowerShell.Security\Certificate::CurrentUser\Root\CD...72
PSParentPath             : Microsoft.PowerShell.Security\Certificate::CurrentUser\Root
PSChildName              : CD...72
PSDrive                  : Cert
PSProvider               : Microsoft.PowerShell.Security\Certificate
PSIsContainer            : False
EnhancedKeyUsageList     : {}
DnsNameList              : {Microsoft Root Certificate Authority}
SendAsTrustedIssuer      : False
EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
PolicyId                 :
Archived                 : False
Extensions               : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
                           System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}
FriendlyName             : Microsoft Root Certificate Authority
IssuerName               : System.Security.Cryptography.X509Certificates.X500DistinguishedName
NotAfter                 : 10/05/2031 11:28:13 AM
NotBefore                : 10/05/2011 11:19:22 AM
HasPrivateKey            : False
PrivateKey               :
PublicKey                : System.Security.Cryptography.X509Certificates.PublicKey
RawData                  : {48, ... 153}
SerialNumber             : 79...65
SubjectName              : System.Security.Cryptography.X509Certificates.X500DistinguishedName
SignatureAlgorithm       : System.Security.Cryptography.Oid
Thumbprint               : CD...72
Version                  : 3
Handle                   : 25...92
Issuer                   : CN=Microsoft Root Certificate Authority, DC=microsoft, DC=com
Subject                  : CN=Microsoft Root Certificate Authority, DC=microsoft, DC=com

Enjoy!

stackoverflow : Privileges

Stackoverflow has levels of privilege. As your reputation goes up, you get to be able to do more.

The top level is 25,000 that I just achieved.

My current ranking is 4242 out of the 8 million odd that have used stackoverflow.

So I need a new goal :-).

I decided that my next goal is to answer 1,000 questions.

Coincidentally, my stats show that I clocked up 750,000 page views as well.

Onwards.

Enjoy!