Problems posting via HTTPS from an IIS process (WCF & WF)

I have some code that wraps the PayflowPro .NET API. It essentially posts to a HTTPS address (a payment gateway) from C#. I can run this code locally and it works nicely. I can run it in my MSUnit tests and it works, and I can run it from a console application on my test environment and it also works.

I have a workflow hosted in IIS 6.1, which instantiates a class which in turn calls this code. When this workflow is started the code fails everytime; I get an error like System.Exception: Failed to connect to host Input Server Uri = https://pilot-payflowpro.paypal.com/ from the API object.

This exception is coming from the API, b开发者_如何学运维ut I am completely lost as to how I can succesfully post from a console application but not from an IIS process.

• The class is exactly the same, word for word.
• I log in as administrator, so the console app is running as administrator. Therefore I have tried using the administrator account for the application pool for the website (for this testing only, obviously)
• The console app can post so therefore the firewall / proxy aren't interfering... right?

Is there anything I need to adjust in IIS to allow an application to communicate outside? Are there any obvious security settings that I'm overlooking? Any suggestions for test cases to run to find out what might be going on?

edit: Turns out that this problem is somehow related to the VM environment in which the server is running. This problem doesn't occur on my development box, the test server or the production server - it's only occurring on the integration server. The cause is still unknown but I am no longer working on it.

---

This might be caused by an ASP.NET trust configuration issue. To check the trust level open the following file in an editor:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config (if ASP.NET 2.0)

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\CONFIG\web.config (if ASP.NET 4.0)

You may also need to edit the C:\WINDOWS\Microsoft.NET\Framework64 versions of these if you're running on 64 bit Windows.

Scroll down to the <securityPolicy> configuration section which looks like:

<location allowOverride="false">
    <system.web>
        <securityPolicy>
            <trustLevel name="Full" policyFile="internal"/>
            <trustLevel name="High" policyFile="web_hightrust.config"/>
            <trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
            <trustLevel name="Low" policyFile="web_lowtrust.config"/>
            <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
        </securityPolicy>
        <trust level="Medium" originUrl=""/>
    </system.web>
</location>

If you see anything other than <trust level="Full" originUrl=""/> it means the server is running under Partial Trust.

Open the .config file specified by the relevant policyFile attribute, for example web_mediumtrust.config if level="Medium".

It's highly unlikely that the server will be running under anything less than Low Trust.

Locate the <NamedPermissionSets> section, under this there is a <PermissionSet> that looks like:

<PermissionSet
    class="NamedPermissionSet"
    version="1"
    Name="ASP.Net">

This contains a number of <IPermission> nodes. Look for one that called WebPermission, it looks like this:

<IPermission
    class="WebPermission"
    version="1">

If it's missing or looks like:

<IPermission
    class="WebPermission"
    version="1">
    <ConnectAccess>
        <URI uri="$OriginHost$"/>
    </ConnectAccess>
 </IPermission>

You need to add or modify so it looks like:

<IPermission 
    class="WebPermission" 
    version="1" 
    Unrestricted="true"/>

This setting controls outbound and inbound access from your application to or from a URI.

It may also be necessary to ensure that the SocketPermission configuration is similarly configured:

<IPermission 
    class="SocketPermission" 
    version="1" 
    Unrestricted="true"/>

---

Turns out that this problem is somehow related to the VM environment in which the server is running. This problem doesn't occur on my development box, the test server or the production server - it's only occurring on the integration server. The cause is still unknown but I am no longer working on it.