Microsoft Office Revocation information not available

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?”

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:

image

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.
clip_image001

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!

Leave a Comment Yourself

Your email address will not be published. Required fields are marked *