Posts Tagged ‘Certificate Authority’

OpenLiteSpeed OCSP stapling with Comodo PositiveSSL

Sunday, September 13th, 2015

OpenLiteSpeed supports OCSP stapling, which helps web browsers check the revocation status of an SSL certificate without having to connect to the Certificate Authority’s OCSP servers and so can speed up the SSL connection process.

In order to enable OCSP stapling, first we need to construct the intermediate certificate chain which OpenLiteSpeed will use to cryptographically verify the response from the CA’s OCSP server.

Take the COMODORSADomainValidationSecureServerCA.crt and COMODORSAAddTrustCA.crt files provided by Comodo when your certificate was issued and concatenate them into a single file

cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt > /etc/pki/tls/certs/PositiveSSL_chain.pem

Now log in to the OpenLiteSpeed WebAdmin console and perform the following steps:

  1. Click on “Configuration” on the navigation bar and then select “Listeners” from the drop down menu
  2. Click “View/Edit” on your HTTPS listener
  3. Click on the “SSL” tab
  4. Click “Edit” on the “OCSP Stapling” section
  5. Set “Enable OCSP Stapling” to “Yes”
  6. Set “OCSP Responder” to “”
  7. Set “OCSP CA Certificates” to the file containing the chained intermediate certificates created earlier (“/etc/pki/tls/certs/PositiveSSL_chain.pem” in my case).
  8. Click “Save”
  9. Perform a “Graceful Restart” of the OpenLiteSpeed server

If all has gone well, you now have OCSP stapling working. Click on “Actions” on the navigation bar and then select “Server Log Viewer” from the drop down menu or look in /usr/local/lsws/logs/error.log and check that you have a line saying “Enable OCSP Stapling successful!

You can also use the excellent SSL Server Test by Qualys’ SSL Labs at to check many attributes of your server’s SSL setup, including whether or not OCSP stapling is working.

Commercial SSL certificates with SolusVM

Monday, February 6th, 2012

When you install SolusVM it generates a self signed SSL certificate for use with the end user control panel and admin interface, however it would be wise to purchase a certificate from a commercial certificate authority to prevent man in the middle attacks (and get rid of annoying browser warning messages).

There are two different methods of installing SSL certificates in SoluSVM depending on if you are using the original Lighttpd web-server or the new Nginx option.

For Lighttpd, you need to place the Base64 encoded DER form of both the private key and the x509 certificate in /usr/local/solusvm/ssl/solusvm.pem and then restart the Lighttpd web-server.

You may need to edit /etc/lighttpd/lighttpd.conf and set “” to be the path to the Base64 encoded DER form of the x509 certificate intermediate certificate for your Certificate Authority.

For Nginx, you place the Base64 encoded DER form of both the private key in /usr/local/solusvm/ssl/nginxcert.key and the Base64 encoded DER form of x509 certificate in /usr/local/solusvm/ssl/nginxcert.pem then restart the Nginx web-server.

If you need to include an intermediate certificate for your Certificate Authority, then this also goes in the /usr/local/solusvm/ssl/nginxcert.pem file in Base64 encoded DER form.

R1Soft CDP 3.0 and commercial SSL certificates

Sunday, June 12th, 2011

Chances are that you will want to protect the web interface for your R1Soft CDP 3.0 server with a commercial SSL certificate issued by a known, trusted certificate authority. After all, you are sending some pretty sensitive data between your browser the and the R1Soft CDP 3.0 web interface and you want to know not only that it is encrypted but that you are able to ensure the identity of the R1Soft CDP 3.0 server so that you aren’t susceptible to man-in-the-middle attacks.

This post assumes that you have generated a CSR and sent it to your chosen certificate authority to be signed. We use /root/example.key as the private key and /root/example.crt as the PEM certificate that you received back from the certificate authority. The certificate authority’s intermediate certificate is in /root/example_intermediate.crt. Obviously substitute these file names for whatever you have actually used.

In order to use the ImportKey utility to import your private key and certificate into the Java keystore file you will need to convert both the private key and certificate from the PEM format into DER using the openssl tool.

openssl pkcs8 -topk8 -nocrypt -in /root/example.key -inform PEM -out /root/example.key.der -outform DER
openssl x509 -in /root/example.crt -inform PEM -out /root/example.crt.der -outform DER

For some reason the java and keytool binaries provided by R1Soft aren’t executable by default, so lets fix this and download the ImportKey utility

cd /usr/sbin/r1soft/jre/bin
chmod +x java
chmod +x keytool

Now lets use ImportKey to create a Java keystore with your private key and newly issued certificate.

./java ImportKey /root/example.key.der /root/example.crt.der

The ImportKey utility sets a password on both the keystore itself and the private key inside the keystore. For the R1Soft CDP 3.0 web server to be able to decrypt the keystore and private key it needs to know what the password is. Unfortunately there is no way to specify the password to use, the R1Soft CDP 3.0 embedded tomcat web server just assumes that both passwords are set to “password”, so we had better change the password from the default which is “importkey”.

./keytool -storepasswd -keystore /root/keystore.ImportKey
./keytool -keypasswd -alias importkey -keystore /root/keystore.ImportKey

Most SSL certificates aren’t signed directly from the root certificate authority these days, but instead are signed via an intermediate certificate. In order for the certificate to be useable, the entire certificate chain needs to be available in the keystore for the R1Soft CDP 3.0 web server, so we will import the intermediate certificate. Remember to use your newly set keystore password.

./keytool -import -alias intermed -file /root/example_intermediate.crt -keystore /root/keystore.ImportKey -trustcacerts

Now to start using your new keystore, just move the old one out of the way (better keep it around for now, just in case!) and replace it with your newly generated keystore then restart the service for the R1Soft CDP 3.0 server.

mv /usr/sbin/r1soft/conf/keystore /usr/sbin/r1soft/conf/keystore.old
mv /root/keystore.ImportKey /usr/sbin/r1soft/conf/keystore
/etc/init.d/cdp-server restart

Parallels Plesk 9 and SSL certificates signed by an intermediate Certificate Authority (CA)

Wednesday, February 9th, 2011

Parallels Plesk 9 doesn’t seem to like installing certificates signed by an intermediate Certificate Authority (which is becoming more and more common and will be all certificates in the next year or two) through the SSL certificates part of the Plesk interface available to both administrators and end users.

A work around to this seems to be to install the CA bundle (both the root CA and the intermediate CA certificates) together and then install your certificate separately, otherwise you will just receive an error saying that the certificate was not signed by the certificate authority.