My blog has moved and can now be found at

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Thursday, January 14, 2010
« Cloud Computing Thoughts from Catalyst09... | Main | Standards Based Provisioning and SPML »

I am currently conducting some testing involving SAML Attribute Authorities. We are currently using an OpenSSL based CA to issue the digital signature and encryption certificates used to provide message level security for all entities involved. In particular, this allows us to encrypt the response to an attribute query using the public key of the requester such that only the requester is able to decrypt the response using their corresponding private key.

openssl.cfgToday I got a call from one of the vendors who have been testing against us noting that they were having issues decrypting the response. They did some troubleshooting on their end and noted that the stateorProvinceName part of the certificate's Subject DN that they were seeing on their end was NOT matching what was coming across in my response.

Specifically on their end, the stateorProvinceName part of the Certificate DN looked like "S=MD" while what I was returning was "ST=MD".

Cert_pemIn the course of troubleshooting the problem on my end, I checked out the openssl.cfg file for the CA. It was set up correctly.

I then looked at the public certificate that was generated (pem format). It too had State in the format that I was expecting (ST=MD).

I also pulled up the certificate in a java tool called Portecle which allows you to work with keystores etc. Same result.

The interesting thing about this particular vendor is that their product is built on top of Windows, .NET and WCF. So their usage of digital signatures and encryption/decryption functionality is leveraging Microsoft technologies and the.NET platform. So I changed the pem extension on the public certificate to cer and opened it on my Windows desktop.

Certificate WindowsAnd there it was... "S=MD"

From what I understand, per RFC 2256 which is Normative for LDAP, the correct field name for "STATE" is st which "... contains the full name of a state or province (stateOrProvinceName)".

If I can extrapolate what I am seeing here, it would appear that both the UI in Windows and the programmatic access to this information is via the same API, which is telling them S=MD.

I did a bit of search on the web and this issue seems to have up in some cases regarding Windows 2003 certificate services, so I don't think I am alone here. I also believe that I have done everything right on how the key-pair itself is generated.

But I am at a bit of stand still as I am not sure of what guidance to provide the vendor. Some questions that I have are:

  1. Is this a known problem, or is this being caused by some oversight/mistake on my part (would not be the first time)?
  2. Is there any particular function/API call that someone working in .NET/WCF could use such that they are working with the actual Subject Name?

I am hoping that people out there have encountered this issue, identified where the problem is, and come up with some sort of a solution.  Any pointers would be deeply appreciated.

Tags:: Security
1/14/2010 10:41 PM Eastern Standard Time  |  Comments [0]  |  Disclaimer  |  Permalink   
Comments are closed.