LinkBack URL
About LinkBacksFirefox 3 are rejects a self-signed SSL certificates by default.
Users can't login into panel.
How to install permanent legal SSL certificate on WHM/cPanel?
Firefox 3 & self-signed SSL certificates
Firefox 3 are rejects a self-signed SSL certificates by default.
Users can't login into panel.
How to install permanent legal SSL certificate on WHM/cPanel?
If by "legal" you mean "signed" (rather than self-signed) then you will need to purchase a SSL certificate.Originally Posted by Nefedov
You can then install that signed certificate by going to WHM -> Service Configuration -> Manage Service SSL Certificates.
You may also wish to change the setting in WHM -> Server Configuration -> Tweak Settings -> Redirection for When visiting /cpanel or /whm or /webmail with SSL, you can choose to redirect to: to SSL Certificate Name if it is not already set to that.
I'll add another bit, use that same certificate in Manage Service SSL Certificates and apply it to all services, this will provide a signed SSL connection fro FTP/Mail - granted customers would need to use the hostname to get mail/ftp but it does provide customers secure communication without always needing to offer SSH.
I'll add one as well. Firefox 3 is not ready for primetime:
Mozilla Won’t Fix 80% of Firefox 3.0’s Bugs
If you must use it, click the add exception link you see when you try to login to http: //yourdomain.com/cpanel/
This will work, I just tried it and am logged in. Short of that what cPanelDavidG explained should help.
Agreed, please wait until the final release of Firefox 3 before submitting bug reports to cPanel about things that don't work properly in Firefox 3. Anything that is not at final release is by definition in a state of flux. No use compensating for something that may not affect the final version of that software.
I typically do not like to comment on third party applications (especially those not directly related to cPanel/WHM). However, this article (and the rebuttal from the Firefox developers) does shed some insight into some improper ways of interpreting results from Bugzilla. I figured I'd go into this since I've seen similar misinterpretations of the software provided by our Bugzilla system.
The NY Times article is likely the result of simply counting the number of open cases in the Bugzilla system for Mozilla. Keep in mind, a case in a Bugzilla system (such as the one we use at http://bugzilla.cpanel.net) is simply "the software does not do what I want it to do." This can be anything from a bug (e.g. Special Characters Not Saving in the HTML Editor) to a feature request (e.g. Support for LightHTTPd Server). While it would be a great idea to support LightHTTPd, one would hardly consider cPanel 11 broken because we didn't include such support. However, applying the same logic of that article to our Bugzilla system, that's exactly what you would think.
When the Bugzilla system begins to have more feature requests than bug reports, this can substantially skew the results you receive. Simply searching for all open cases does not accurately indicate how many bugs there actually are in a software application.
Another issue is duplicate reports. While our QA staff is very diligent about merging duplicate bug reports/feature requests, occasionally there will be 3 or 4 duplicates of the same issue in our system. I can't speak to how the Mozilla Foundation maintains their system, but we do actively maintain things to ensure we can accurately communicate information via the Bugzilla system as needed to all parties who have expressed an interest in a particular bug report/feature request.
I'm not defending Bugzilla or Mozilla nor do I wish to start a debate regarding classifications of "feature request" vs. "bug report" - just wished to share my thoughts some issues some may not have been considered before.
Reply With Quote