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:

2 comments:

  1. it would be the best way to create your own self signed certificate for token signing.
    In this case you can specify the length by yourself, makes it much easier.
    Your solution temp. solves the issue but it is strong unsupported and
    you can get a real issue when you install the next updaterollup, when the setup wizard aspects an
    DynamicsConultant
    http://www.dynamics-crm-2011.de/dynamicscrm2011-anwender/crm2011-integratoren/crm-deployment/adfs-and-crm-2011-troubleshooting

    database field with 128 characters it will bring an exception and the installation will fail. All people who have done this must role this back when they have no need anymore (means when it is fixed by microsoft or when they get issues with updaterollups)

    ReplyDelete
  2. I agree that there is a strong risk that future updates would fail due to changing the column length. However, it's a trade-off that must be considered. The only "good" solution is for Microsoft to issue a hot fix. It would also be far better to search for an online cert authority who issues certs with shorter names. But this won't be ideal for those who have wildcard certs which are used by multiple sites and want to manage just 1 cert.

    Using a self-signed certificate will not be a reasonable option for many businesses. Self-signed certs open up major security risks if you have anyone accessing your site on a machine which you don't control. They are subject to man-in-the-middle attacks and can't be revoked. Man-in-the-middle attacks can very easily lead to password compromise or worse. So the choice is between having to deal with some headaches from a CRM upgrade or creating a major hole in your network perimeter security. For a small business, this security risk may be acceptable but I don't know many IT Directors at larger companies who would be willing to open up their network to such attacks unless they had no other choice.

    ReplyDelete