Wednesday, July 27, 2011

You can't access pages via TMG as proxy with https inspection enabled on port different than 443

So, if you try to access pages via https on port different than 443 via TMG with https inspection enabled and you check logs on TMG you can see the following error "12204 The specified Secure Sockets Layer (SSL) port is not allowed. Forefront TMG is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests".
As a solution to this error I have bumped on the following article . There are three scripts for managing tunnel port ranges (view,add,delete). In my case I should access 8443 for ssl. So, I have added new tunnel port range with single port 8443. Started the script like : "cscript addrange.vbs ssl8443 8443" . And, TMG started proxyng ssl requests to requested destination on 8443.

Blank page when accessing streamed pdf file over https

If you receive a blank page on your Internet Explorer when you try to open streamed pdf document, and you have tried almost anything including resetting the browser, re-installing Adobe Reader (pre-registering active-x plug-in), installing the latest version of Adobe Reader ...and still you're receiving white blank page, try opening the same streamed pdf document via http (if you're hosting the web server, or someone can provide that for you). In my case I could successfully open streamed pdf document when the document was provided via http. So, I started digging deeper and bumped on the following article "Internet Explorer file downloads over SSL do not work with the cache control headers". In my scenario the client is running on XP with IE 8 and Adobe reader 8, and the web server IIS 7.5. In Microsoft's KB there is a solution for IE 8, where I have added the following key "BypassSSLNoCacheCheck"=Dword:00000001 and the IE has finally showed the streamed pdf file ! But you must be aware that the server is using "cache-control:no-store", check with your developers !
In order not to change (add registry settings) on all workstations, I have pushed developers to change their code to response.setHeader("Cache-Control","private") , and the case was successfully closed.