There can be no webpage you test your app against. You need to test this direct on the proxy which causes the problem.
There you (or the webgateway administrator) have several debugging options to find out why your app does not pass the proxy. (look into Ruletrace)
I don't see why there couldn't be a webpage, you provide a similar service for checking certificates that someone uses on a given URL.
The way I would imagine it would work it is it could simply perform all the normal tests for an "out of the box" configuration
There is no proxy in the world configured like to other. The result depends on the policy the customer has configured.
I can configure a proxy without any policy and your app will work. But this won't help you.
There a several reason why your app will not work. There might be a catagorization filter blocking your request, an authentication issues, a web reputation problem and last but not least might the AV enginge block your APP.
And this are only a few reasons....
you have to propagate the MWG Cert into your clients system as well.
The question is which part of MWG is preventing your application from working.
Did the customer reveal any details? MWG is completely flexible to the customers needs and a block can have a lot of reasons, so a statement like "the application does not work" is not very helpful. We need to find out if it is a problem with the server certificate, maybe a URL that is incorrectly categorized may cause a problem, maybe there is an issue with authentication or one of the AV engines. Maybe it is a connectivity problem...
There are too many possibilities to make an assumption without some more details.
As Frank indicated a "test page" won't really work as MWG does not enforce a specific compliancy but MWG enforces whatever the customer configured. In the default configuration everything which is not using a blocked category or contains malware is passed, even SSL inspection is turned off, so this won't really help.
If you could provide some more details we are certainly happy to help when possible.
They provided a screenshot
The bottom right text says the rule it broke and that they are using IE11 on Windows 7 64-Bit
mozilla/5.0 (Windows NT 6.1; WOW64;Trident/7.0; rv:11.0) like Gecko
Rules.CurrentRule.Name: Valid Internet Traffic(Valid Internet Traffic)
The Header-bar says "Handshake failed" and the main text says "The SSL handshake could not be performed." and "Reason: error:00000000:lib(0):func(0):reason(0)
it is not a rule that broke the traffic but MWG cannot make an SSL connection to the destination. This is not a specific block the customer configured, but some issue before the connection is established.
You should try making an exception to SSL Scanner as I indicated in the other post you have made: The SSL handshake could not be performed
So just to check my understanding.
MWG by default wants to insert itself in the SSL stream to inspect the contents, to do that it needs the server to be complicit. If as the owner of a MWG you trust a vendor, you can whitelist the server so that a normal client-server tunnel is created.
If this is the case.
Is there a mechanism for us to flag our servers to be globally white-listed? Whilst we have a working relationship with our customers, we don't know their clients at all!
Can we certify ourselves somehow with McAfee ?
well MWG does not insert itself into SSL streams by default. The customer installs MWG into the network and points his browsers to MWG as a proxy server (or transparently redirect HTTP(s) traffic to MWG). By default MWG will pass HTTPS connections but when you enable the SSL Scanner MWG will act as a "man in the middle". It has a certificate authority installed which it uses to create a server certificate which is sent to the client. So client and MWG now have a HTTPS connection set up, signed with a server certificate created by MWG.
MWG on the other side will connect to the remote web site and act as the client, so it will read the certificate presented by the server, validate it and ensure it is correct. Once both connections are established data is transferred.
If you disable the SSL Scanner rule sets or avoid execution by placing a white list entry MWG will take the data coming from the client and pass it on to the server, so the connection is tunneled through MWG.
In terms of global white listing: There is no option to avoid SSL inspection "globally", e.g. controlled by McAfee. The customer needs to place the exceptions into his SSL Scanner rule set to avoid MWG from looking into the SSL communication. Of course the customers can add all of the servers you provide for their application, but they have to set up the rule on their own.
If you could name one of the servers the customer has problems to connect to I could try with a lab MWG if I see similar issues so we can find out if the problem is related to the customers MWG or if MWG generally has trouble talking to your servers and - if so - why and what we can do against it.