WebDav Client Certificate Challenge
If you have Office/Word 2010 and open a document via Internet Explorer a WebDav interrogation of the Web site will be performed. This is to determine whether Office can write back the document to the site (e.g. as you would use on Sharepoint).
We encountered a hard to trace issue with this interrogation. Opening a document from IE would result in a challenge to pick a client certificate. Clicking cancel past these dialogues would allow the document to still open. Tracing that this was something to do with WebDav was easy enough as we could see the WebDav requests coming into the server - indicated by an OPTIONS request at the folder level with subsequent PROPFINDs. These are issued by the user agents:
Microsoft Office Protocol Discovery
Microsoft Office Existence Discovery
Microsoft-WebDAV-MiniRedir/
DavClnt
What was confounding us was that the issue did not occur on our test system. After a comprehensive inspection of the IIS (7.5) server no differences between the production and test systems could be identified.
The issue was eventually uncovered by inspecting the SSL connection coming from both sites. On production "openssl" indicated a different hostname in the certificate to the site being requested. This is because our production system has multiple host aliases, with appropriate redirects in place. The test system has a single host.
The production aliases are served using Server Name Indication (SNI). This works fine in all modern browsers, including the version of IE being used. Where it doesn't work is in Microsoft's WebDav implementation. When the WebDav client interrogated the server it was getting a certificate name mismatch. Rather than indicating a server certificate error it instead requested a client certificate!
The solution for this site was to change the default certificate to the official Web site name. I don't know if there's a solution for multiple sites sharing the same https connection with SNI.
We encountered a hard to trace issue with this interrogation. Opening a document from IE would result in a challenge to pick a client certificate. Clicking cancel past these dialogues would allow the document to still open. Tracing that this was something to do with WebDav was easy enough as we could see the WebDav requests coming into the server - indicated by an OPTIONS request at the folder level with subsequent PROPFINDs. These are issued by the user agents:
Microsoft Office Protocol Discovery
Microsoft Office Existence Discovery
Microsoft-WebDAV-MiniRedir/
DavClnt
What was confounding us was that the issue did not occur on our test system. After a comprehensive inspection of the IIS (7.5) server no differences between the production and test systems could be identified.
The issue was eventually uncovered by inspecting the SSL connection coming from both sites. On production "openssl" indicated a different hostname in the certificate to the site being requested. This is because our production system has multiple host aliases, with appropriate redirects in place. The test system has a single host.
The production aliases are served using Server Name Indication (SNI). This works fine in all modern browsers, including the version of IE being used. Where it doesn't work is in Microsoft's WebDav implementation. When the WebDav client interrogated the server it was getting a certificate name mismatch. Rather than indicating a server certificate error it instead requested a client certificate!
The solution for this site was to change the default certificate to the official Web site name. I don't know if there's a solution for multiple sites sharing the same https connection with SNI.
posted by Tim at
2:50 pm
0 Comments:
Post a Comment
<< Home