I’m helping a security-severe customer, and they’re getting “can’t verify the certificate” every time they run a Java app in the browser (IE, if that matters). Apparently their firewall is not letting the app get out to Verisign to verify the certificate. My google-fu is weak and I can’t find what port should be opened in the firewall to let the verification happen. Can someone help?
A SSL certificate error has nothing to do with any TCP/UPD ports blocked at the firewall. The most likely error is that the cert is expired or the CA isn’t trusted by his system. This will happen a lot with self-signed certs or certs issued by a private CA and not a public CA.
SSL typically uses port 443, at least for a web page.
Did you try a different browser, and try the site on another machine?
Is that the exact error message?
Correct, but if port 443 was blocked at the firewall, the customer wouldn’t be able to use a pretty large number of sites on the Internet, especially banking, webmail, any sort of online store checkout, etc. If 443 was being blocked, the customer would be having trouble with a great deal more than just a single Java app.
No such port, no such connection .
The individual certificate is verified off trustcacerts ( files) on the client, AND on the server . Get the cert creation wrong and it won’t verify.
So here’s how to create the cert
No such number, no such zone? 
The actual error message (boy, my memory is getting worse):
Unable to ensure the certificate used to identify this application has not been revoked.
The application being used his hosted inside the firewall. It hasn’t given trouble at other sites.
Pardon my ignorance, but I don’t have clue how all this works. The user types
javaws http://machine:port/app
at the command line and gets the above warning. When he clicks the “I accept…” box and the “Run” button, the app comes up and is fine thereafter.
Sounds like your Java app is code-signed with an SSL certificate, and the CA that issued the code signing certificate is having issues with it’s CRL Distribution Point.
Contact the developer/vendor of your application; they should be able to help you out.
Make sure they’re running the latest version of Java, 1.7_45. They make some changes to applet handing that prevent signed applets working correctly.
The message “Unable to ensure the certificate used to identify this application has not been revoked.” means that the browser can’t check the certificate revocation list. The certificate that signed the applet will have a CRL distribution point attribute. These are usually normal http:// or https:// URLs that point to the CRL. Those ports are normally open on most firewalls. But if the user is deep within the corporate network they might not have access to the public internet.
I think you got it here. If the machine the user is running the internal app on doesn’t have access to the Internet, it won’t be able to check the CRL and thus throw that error. I’m guessing the user is using a machine that only has access to the corporate intranet and not to the Internet.
Or else the URL the CRL is hosted on is blocked at the firewall level by a web filter…
Yes, we have no internet access. 
So where do I find the certificate details that will tell me what http (or https) they need to allow to get the certificate validated?
So the port number is the standard 80, but they can’t get to the correct site, if I am understanding what is above. Either they will have to open a path to that site (still hoping someone will hemp me with where to get that detail) or they will have to live with the error message and the extra clicks.
Correct, they will have to live with the error message unless the network admin opens up access to the CRL distribution point from the internal network, or else they reconfigure their internal CA (if they have one) to handle the external signed certificate - which is beyond the scope of this discussion.
Maybe that’s the problem right there: Placing ** : ** immediately before ** p ** in a URL. 