Adding CRL data to WMRM SDK 10.1.2 based scripts

UPDATE: The code referenced on this page is written in ASP / VB Script. I recently created a complete ASP.net code sample that does everything this code does and more. I would recommend that you check it out by going here: https://blogs.msdn.com/mediasdkstuff/archive/2008/09/26/wmrm-sdk-10-1-2-best-practice-sample-code.aspx

I’ve talked to a lot of developers that are having problems implementing the new CRL requirement for WMRM 10.1.2 into their Windows Media DRM License Server scripts. Implementing the necessary changes isn’t very difficult but the info on the official KB (https://support.microsoft.com/kb/941826/en-us) isn’t really all that clear.

To try and help my fellow WMRM SDK developers out with this pain I’ve put together a quick sample that should demonstrate how to integrate the CRL requirements into their code. If you find that your users are getting prompted by WMP to install the CRL from https://go.microsoft.com/fwlink/?LinkID=75378 (https://support.microsoft.com/kb/919589/en-us) this code will prevent them from having to go to this URL and install the CRL manually. Your code will be installing the CRL for them. The code is based on the standard predelivery ASP script that ships with the WMRM SDK. I’ve modified the cod e to generate the CRL information and attach it to the license using WMRMResponse.AddRevocationData.

This code works. If you find that after running this code your users are still getting prompted to install the CRL then you haven’t updated the CRL on your License Server. The CRL information is stored in the registry on your license server. In order to be able to send the latest CRL data to the client via your code you need to make sure that you have the latest CRL data on the server.

Remember that in the WMRM SDK license agreement you agreed that you would update the CRL on your License Server once a month. You need to make sure that you are doing this. If you don’t update the CRL information on the server once a month, your users will get prompted for the CRL update once the CRL has expired on their machines.

So the next logical question is: “How do I update the CRL information on the server?” Just go to https://licenseserver.windowsmedia.com/v2revocation.asp hitting this page from the server will automatically install the necessary CRL information on your server and update the registry. You can easily automate this process. You can write a simple browser script in .net that hits this web page. Unfortunately scraping the script from the page won’t work because the CRL data is hard coded in the page. This means that you have to get the latest version of the page to get the latest CRL. One potential gotcha on scripting the server side CRL update; I think that the process that runs your script needs to have admin rights. 

The code additions are denoted with comments in the code. All changes were made to prelicgen.asp. To find the changes search for the following string: “BEGIN MS”. There are three code blocks that were added.

The first code block gets the revocation information from the client. This information is included in the challenge data sent from the client. As you know you, the challenge data contains information about the client including the revocation information. The introduction of the revocation information sent from the client is fairly new (WMP v11) and this is why older versions of  the player don’t prompt users for the CRL information.

The next code block calls “WMRMLicGen.SupportedCRLS”. I’m not sure why this property is called “SupportedCRLs”. I don’t know what an unsupported CRL would be. I also wasn’t able to identify exactly what this is for. It looks like it has something to do with DRM enabled devices but, I’m not sure. I’ll have to see if I can figure this one out and I’ll let you know.

The final code block calls WMRMResponse.AddRevocationData. This is the call that actually adds the data to the license. The fRevInfoPresent parameter is used to decide if we should evaluate the bstrRevInfo parameter. If the revocation data is present then we look at the client’s revocation list in bstrRevInfo and build a list of the changes and updates between what the client has and what is on the server. We then only send the changes and updates to the client. If we don’t have any revocation data from the client then we go ahead and send the entire list from the server to the client.

That’s it. Use the instructions on setting up the predeliery sample scripts in the SDK to get this up and running. But basically you should be able to drop these into an IIS application and call predel1.asp and then click on the button on the resulting page. Just make sure to update the global.asa file to use your keys. You can find the setup instructions here: https://msdn2.microsoft.com/en-us/library/bb614739(VS.85).aspx

You can find the code sample here: https://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=mediasdkstuff&ReleaseId=660