Friday, May 27, 2011

CRM 2011 IFD: Certificate Name Can Only Be 128 Characters Long

I learned recently that, as of Rollup 1, CRM 2011 On-Premise will only allow certificates to have names of 128 characters long for Internet-Facing Deployment (IFD).  This one was fun to track down but there is a fix (read: hack) at the bottom of this post.

In the hope that this might help you in your quest for better CRM, here's how it played out:

The server configuration was pretty simple and normal, with the possible exception of that last bullet, but we tried it without that also:
  • CRM Web Server (1) running all latest software, joined to corp domain
  • ADFS Server (1) running all the latest software, joined to corp domain
  • Wildcard cert purchased through internet cert issuer for *.mydomain.com
  • We replaced the default self-signed ADFS token-signing cert with our SSL wildcard cert
The first sign of trouble was when we went to configure Claims-based authentication in Deployment Manager.  We put in all of the usual values and then the snap-in crashed when we clicked Apply.  We were immediately sure if this was an issue with the snap-in or an issue with MMC.  So we ran Deployment Manager again and it said that claims-based auth was enabled, so we continued.

Then we configured IFD and all seemed well.  Next, on the ADFS server, we tried to create a Relying Party Trust for CRM.  This wouldn't allow us past.  So we popped open IE and tried to go to https://auth.mydomain.com/FederationMetadata/2007-06/FederationMetadata.xml.  This threw an ASP.net error, so we went to the log file on the CRM server to see what was up.

The error in the Application Event log was "CrmSecurityException: Relying Party Certificate was not found".  So we went through all kinds of checking to ensure that the cert was in the Personal and Trusted CA store on both servers and that the CRM app pool account had access.  We finally hit a breakthrough when we turned on tracing.  The error in the trace file was pretty much the same as the event log:  "Relying Party Certificate was not found., ErrorCode: -2147220906".  But what was interesting was the line before the error:

Query execution time: 0.0 seconds; database: MSCRM_CONFIG; command: SELECT Id, Name, CertificateData, StoreName, StoreLocation, StoreFindType FROM Certificates  WHERE (((ParentId is null) AND (Type = 'RelyingPartyEncrypting')) ) AND (IsDeleted = 0).

So I looked at the database and sure enough, there was no Relying Party cert in there.  I checked another server where IFD was working and found the record with Type = 'RelyingPartyEncrypting' so it became obvious that the config had failed.  Hence the crashing snap-in in Deployment Manager.  So we decided to trace which that error happened and were delighted to find that error in the trace file also.  We were not, however, delighted with the content of the error message:

Exception creating Certificate, Name=(CN=*.mydomain.com, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/resources/cps (c)11, OU=XXXXXXXXXX, O=*.mydomain.com, C=US, SERIALNUMBER=xxxxxxxxxxxxxxxxxxxxxxxx-wdfpf :Exceeded column length: Column Name)

When I looked in the database at the Certificates table, the Name column where this value is bound is an nvarchar(128).  Our name value for this cert is 162 characters, thanks to all the extra garbage which RapidSSL threw in there.  Then I tried exactly what you would have tried ... I did the unthinkable and resized the database column to 256.  No dice.  Same error in the same place.  I later received some information from a fellow CRM-er (pogo69) that there was also a metadata field which was being checked when Deployment Manager opens.  He suggested a temporary fix for this issue until Microsoft has a chance to release a hotfix.  I have tried it in my client's environment and it appears to work.  


Please note that this is an unsupported change and there could be unintended consequences including causing future Rollups to fail, having future Rollups or hotfixes overwrite (reverse) this change, and causing some unrelated functionality to fail.


You would need to run this in the MSCRM_CONFIG database:



ALTER TABLE Certificates ALTER COLUMN Name NVARCHAR(256);
 
  UPDATE
   MSCRM_CONFIG.dbo.ConfigurationMetadata
  SET
   ConfigurationMetadataXml =
     REPLACE(
      CAST(ConfigurationMetadataXml AS NVARCHAR(MAX)),
      'Name of the Certificatenvarchar128',
      'Name of the Certificatenvarchar256'
     );



Hopefully Microsoft will release a hotfix for this sometime soon.  If you are having this problem, even if this above fix works for you, then please login to Connect and vote up the following 2 issues and add them to your watch list: