Simply put, Lync does not support certificates that are issued using the Cryptography API: Next Generation providers. At the time of this writing, Lync 2010 and Lync 2013 only support certificates that are issued using legacy Cryptography API providers. To determine if your certificate was issued with CryptoAPI:NG support, use these quick instructions:
Using certutil.exe, you can examine the information about the certificate.
Certutil.exe –v –store my “certificateserialnumber”
A lot of data will be returned, but you need concern yourself with only a single piece of that information. If you do a search and find Microsoft Software Key Storage Provider, then your certificate has been issued using the new CryptoAPI:NG provider and won’t work with Lync.
If you say to yourself, “So what!? I’m going to use the certificate anyway!”… Attempting to assign a certificate that is used using the CryptoAPI:NG providers within Lync will result in an error and the certificate cannot be used:
An error occurred: “System.Security.Crpytography.Cryptographic.Exception” “The buffer supplied to a function was too small.”
Personal Thoughts
Having done a number of Lync deployments, I had not run into this particular issue yet and was a bit puzzled at why this was the first time I had seen it. It took some time and lab work, but was able to consistently reproduce it and determine what was occurring. Does this issue constitute the end of the world? No, of course not. Does it mean Lync is insecure and broken? Absolutely not. Read on to calm yourself.
Background
Lync relies heavily on certificates and anyone familiar with it knows that. Microsoft has taken extensive measures in documenting the certificate requirements for Lync:
http://technet.microsoft.com/en-us/library/gg195673(v=ocs.14).aspx
http://technet.microsoft.com/en-us/library/gg195752(v=ocs.14).aspx
http://technet.microsoft.com/en-us/library/gg195796(v=ocs.14).aspx
http://technet.microsoft.com/en-us/library/gg425950(v=ocs.14).aspx
http://technet.microsoft.com/en-us/library/hh202161(v=ocs.14).aspx
What is not well documented publically is that Lync doesn’t include support for CryptoAPI:NG. I could not find a single reference anywhere that denotes this in TechNet. If anyone out there can find this information, please let me know and I will update this post to reflect that.
What is CryptoAPI:NG?
As with anything in IT, things advance. CryptoAPI:NG is simply that – an advancement of the cryptographic stack that was introduced in Windows Vista and Windows Server 2008. For details on this, check out this Technet article that gives great details into what advancements are included and this Technet article that describes applications that are currently supported. There are two important things to remember here:
- CryptoAPI:NG was introduced with Windows Vista and Windows Server 2008. If you have Windows XP and Windows Server 2003, you need not be concerned because those OS’s don’t support it.
- While OS support might have been added, applications must explicitly opt-in for support to use the new CryptoAPI:NG features.
For every Lync installation this means that there is the potential to see this issue. Lync will be installed on Server 2008 or newer, but the chances of seeing this heavily depend on your internal PKI configuration and how certificate templates are configured.
Does my PKI support CryptoAPI:NG?
First of all, only Server 2008 Certification Authorities or newer support CryptoAPI:NG. If you only have Server 2003 Certification Authorities then you need not worry as you won’t ever see this issue.
Second, the default templates are not configured for CryptoAPI:NG support so you will never see this issue using the default Web Server template.
Third, if you are using custom certificate templates then there is a possibility the template has been configured to require the new CryptoAPI:NG providers.
To determine if the certificate template is configured for CryptoAPI:NG support, use these quick instructions:
On your Certification Authority, open the Certification Authority MMC.
Right-click Certificate Templates and click Manage
Right-click the applicable template and click Properties
Click on the Cryptography tab
If the following settings are checked, then CryptoAPI:NG is configured for the template:
Provider Category – Key Storage Provider
Requests must use one of the following providers
Providers – Microsoft Software Key Storage Provider
How would I get a certificate with CryptoAPI:NG?
Answering this question is the all-important one and turns out to be relatively simple:
If you request certificates using the Lync Certificate Request Wizard or the Lync Management Shell, you won’t.
In all my testing I could never get a certificate using CryptoAPI:NG when using the wizard or shell, even if the CA template required CryptoAPI:NG. When using the wizard or shell, the certificate always came back with the Microsoft RSA SChannel Cryptographic Provider, which is legacy CryptoAPI. While it seems odd that the CA would issue a certificate with a provider it isn’t configured for, it does make sense that the certificate wizard and shell would not request it because it is up to the Application to opt-in for CryptoAPI:NG functionality. Since Lync doesn’t support it, the wizard and shell use the legacy CryptoAPI functionality and everything works. The only time I could successfully get a certificate using CryptoAPI:NG was by manually requesting the certificate through the Certificates MMC console on the computer. In that scenario there are no restrictions by an application on what should be used, so the MMC console adheres to what is specified in the certificate template.
Note: I have seen some reports that public CA’s have issued CryptoAPI:NG certificates, but I cannot verify whether those certificates were requested using the Lync tools. I also did not test that scenario for this article.
I’ve got a CryptoAPI:NG certificate…now what?
Assume you have a CryptoAPI:NG certificate and you simply cannot request a new one. It turns out it is possible to use that certificate with a little workaround:
Export the CryptoAPI:NG certificate (with private key) from the Lync Server machine and import it onto a Windows XP machine. Then export the certificate (with private key) from the XP machine and import it onto your Lync Server machine. This export process on the XP machine will convert the certificate into using the legacy CryptoAPI provider and will result in the certificate being able to be used on the Lync Server machine. This MSDN article describes why this conversion occurs.
Again, assume you cannot use the Lync certificate wizard to request certificates and you don’t have an XP machine available to convert the certificate – maybe the organization requires a dedicated team to issue the requests for you and they always use the Certificates MMC. Getting things working in that case requires the certificate template used to be configured to not require CryptoAPI:NG. This could be accomplished in two ways:
Option 1
Use the default Web Server template
Option 2
Change the custom CA template so that CryptoAPI:NG is not required
Provider Category – Legacy Cryptographic Service Provider
Requests must use one of the following providers
Microsoft RSA SChannel Cryptographic Provider
Microsoft DH SChannel Cryptographic Provider
Summary
Again, to sum it all up: Lync does not currently support CryptoAPI:NG certificates. It is entirely possible that a Cumulative Update or the next version of Lync will include support, but for now make sure your certificates are usable by not requiring CryptoAPI:NG!
Great post, but one point of clarification. Not all legacy CSPs are supported. For example: Microsoft Strong Cryptographic provider will NOT work. When you assign a cert using the Lync cert wizard when the Microsoft Strong Cryptographic provider is used, you will receive warnings indicating the SAN entries do not match even though they do. Only one I have seen in many deployments and I can say absolutely works is the Microsoft RSA SChannel Cryptographic Provider. Best to stick to that specific CSP.