Google is undoubtedly suffering from some adverse PR in respect of its new privacy policy.  While it may have considered itself on to a PR “winner” with its “privacy made simple” approach, there has been considerable backlash in opinion and re-consideration of the use of its services.

So, what could Google do to demonstrate that it still takes on-line security seriously?

How about setting up its own Certificate Authority, and issuing free SSL certificates?

Google has the infrastructure, manpower and, I’d argue, interest in doing such a thing.  In fact, in many ways, it already offers the flesh around this missing skeleton.

Perhaps it could support the CACert effort with funding and enough energy to get it through the audits required to have their root certificate included in Mozilla’s Firefox, as-shipped?  And, while Google are at it (restoring their image of benevolence, that is), they could include that root certificate in Chrome too.

Just saying…

I confess: this is a problem without an obvious solution.

As a server administrator managing tens, possibly hundreds, of domains via Parallels’ Plesk control panel system, you may be forgiven for getting frustrated, from time to time.  It happens.

While Plesk is a big time-saver for many tasks, there are occasional quirks which only help to irritate.  One of these being SSL certificates.

Security warning in Chromium

The Plesk control panel comes with a standard SSL certificate which is used to encrypt all HTTPS connections to/from the server by default.  Most server administrators will probably want to replace this with a certificate that correctly identifies their specific server.

The usual route, through Plesk 9.5.x would be to log in, click Settings, click SSL Certificates, and then create / delete certificates accordingly until you have a new default server certificate.  The final step would be to tick the checkbox next to the new default certificate and click “Secure Control Panel”.

This gives you the impression that the new certificate is now used by the control panel.  It isn’t.

So, the next morning, you’ll probably receive one of these by email:

################# SSL Certificate Warning ################

Certificate for hostname 'plesk', in file:
/etc/httpd/conf/httpd.pem

The certificate needs to be renewed; this can be done
using the 'genkey' program.

Browsers will not be able to correctly connect to this
web site using SSL until the certificate is renewed.

##########################################################
Generated by certwatch(1)
"Hmm", you think, "this should have been updated when I 'Secured the Control Panel'".  Yes, it should.  So, the next logical step would be to edit httpd.pem and replace the Key and Certificate values of this file with those displayed through Plesk's SSL Certificates section.  Then simply restart the web server.  Ha ha! Fail!  Browsing to the control panel still results in the security warning. What gives?!! 
 
After you have restarted the web server many times, both via the operating system's /etc/init.d method and via /usr/local/psa/admin/bin/websrvmng, you conclude that, actually, this is also not the certificate that requires updating.  So, which certificate file stored on the system is the one being served by Plesk?

Good question.  While you're searching for an answer, try checking/editing /usr/local/psa/admin/conf/httpsd.pem  and  /usr/local/psa/etc/httpsd.pem.  Nope?

Oh well, how about just resorting to a reboot and taking down everyone's services for a moment? ... Not ideal, but it works.  But this is not the right way!!!  🙁
 
********* UPDATE 23/11/2011 ***********
 
I have stumbled upon the right way to do this.  In a shell: 

cd /usr/local/psa/etc/
mv httpsd.pem httpsd.pem.old
cp /usr/local/psa/admin/conf/httpsd.pem .
service psa restart