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?

  • 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. Commented Jan 25, 2013 at 9:19
  • @mr.spuratic: Yes, the form is served via HTTPS as well.
    – David
    Commented Jan 26, 2013 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/… Commented Jan 28, 2013 at 18:09

1 Answer 1


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .