Take the 2-minute tour ×

We have an HTML form which is submitted via HTTPS. We've noticed that when the form is submitted on a home network, it seems to go through just fine. However, when the form is submitted on certain corporate networks, the data seems to disappear (the browser doesn't yield an error message but the POST data never hits our server).

We checked our SSL certificate installation at http://www.digicert.com/help/ and everything checked out okay. The intermediate certificate is also installed correctly.

Since our SSL certificate was issued by Starfield Secure Certification Authority (a subsidiary of GoDaddy), which is a newer player on the SSL market, we're beginning to wonder if some older corporate firewalls are blocking these HTTP requests because they don't recognize the issuer. Is this possible? If so, is there any solution besides purchasing a certificate from a more recognized issuer (e.g. Verisign)?

GoDaddy offers the option to choose between GoDaddy and Starfield as the issuer. We chose Starfield to avoid the name 'GoDaddy' on our certificate, but would it help to switch the issuer to GoDaddy?

share|improve this question
Is the form also served via HTTPS? In order to prevent use or abuse of the HTTP CONNECT method corporate firewalls or proxies most commonly implement permit/deny by site or category for HTTPS, not this type of chain verification. –  mr.spuratic Jan 25 '13 at 9:19
@mr.spuratic: Yes, the form is served via HTTPS as well. –  David Jan 26 '13 at 21:01
It may be a case of an intercepting proxy then, and your form may fail due to content inspection at upload, either by misclassification (e.g. webmail or social media), or by overly strict enforcement of the form (field names/number of fields/content length). This may point you in the right direction: security.stackexchange.com/questions/5815/… –  mr.spuratic Jan 28 '13 at 18:09

1 Answer 1

up vote 1 down vote accepted

Data doesn't really get lost but error messages in communication protocols might not be passed to the user by web applications or browsers.

You need to debug the problem on a lower layer. To see the actual communication between browser and web-server you can use an interception proxy such as Burp or Paros Proxy. These proxies will show even encrypted HTTP communication. You can see where the data is being sent and what is the response of the server. If no data is being communicated then the problem is on a lower layer.

Using Wireshark, you can debug TCP and SSL communication issues. This is the layer where most firewalls operate. Even firewalls that block traffic may send some data to show why a packet was blocked.

Using a less known CA should not be a problem except for very paranoid firewalls. There are many less known CAs as you can see from this map and Starfield is also issuing Extended Validation Certificates.

share|improve this answer

Your Answer


