The Problem

As recently encountered, if your PKI setup is less than optimal you may experience one or more of the following when opening Office documents stored in SharePoint 2010/2013 over SSL:

1. When you open the document you get a Security Alert:

“Revocation information for the security certificate for this site is not available. Do you want to proceed?”

2. In the CAPI2* logs you see:

“A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider”

or

“The revocation function was unable to check revocation because the revocation server was offline”

*for CAPI2 logs – switch on logging by right-clicking on the Operational log (in Event Viewer/Event Logs) below & clicking on Enable:

The Cause

It turns out that Office is particular about the Certificate Revocation List (CRL) and how to access it… if your Certificate Server is not AD-integrated, then the default CRL paths are likely to be UNC (file://) and/or LDAP paths… which Office isn’t capable of accessing in that context.

More about Office cryptography & encryption here if you’re interested (useful info on algorithms).

The Solution

To resolve this, follow these steps, also taking into consideration any previously-issued certs and the applications which may rely on the existing config, and the fact that you are now tampering with “security” and should probably consult a PKI expert </disclaimer>.

1. Alter the default CDP in the cert server as follows (or similar, ensuring http:// or https://). It’s my understanding that if http:// preceded file:// (if file:// is even needed anymore) that should still work, but according to this MSDN Forum evidence UNC paths aren’t well supported.. not official though.

2. Add IIS Role to the cert server & add Virtual Directory “CertEnroll” on the default website mapping to c:\windows\system32\CertSrv\CertEnroll

3. Revoke certs (supersede)

4. Re-issue cert requests & re-apply certs in IIS

So it’s not even a SharePoint issue, more an issue with Office 2010/2013 (maybe others..) however it’s easy for the client to try and blame SharePoint in this instance.. not really fair!

Hope that helps – couldn’t find much info out there!