SSL and subversion client

Unlike web browsers, the CA root cert is not installed by default for svn clients. You would need to tell the client where to find it in order to trust the ssl cert.

Reference: svnbook

For GoDaddy signed certs, download their root certs available at:

You would need both the pem encoded gd-class2-root.crt and gd_intermediate.crt .

Then in subversion client global settings, tell it the path to the certs:

ssl-authority-files = /path/to/gd-class2-root.crt;/path/to/gd_intermediate.crt

This should then trust the ssl cert.

Setup secure ProFTPd

Ftp can be secured using ftps to connect. Below outlines a configuration to support such a setup using TLS/SSL.

I usually use the epel repository to install proftpd:

yum --enablerepo=epel install proftpd

Configure for tls/ssl connection:

<IfModule mod_tls.c>
TLSEngine                       on
TLSRequired                     off
TLSRSACertificateFile           /etc/pki/tls/proftpd/server.cert.pem
TLSRSACertificateKeyFile        /etc/pki/tls/proftpd/server.key.pem
TLSVerifyClient                 off
TLSRenegotiate                  required off
TLSLog                          /var/log/proftpd/tls.log

chroot and bindsocket to listen to single IP:

SocketBindTight                 on
DefaultRoot                     ~

Setup passive ftp ports:

PassivePorts 50000 51000

Create the certs:

mkdir -p /etc/pki/tls/proftpd
cd /etc/pki/tls/proftpd
openssl req -new -x509 -days 9999 -nodes -out server.cert.pem -keyout server.key.pem

Create /etc/pam.d/ftp so PAM can authenticate for proftpd:

auth    required     nullok
account required
session required

Add "/bin/false" to "/etc/shells" file and use it as the shell type when creating new users:

useradd -s /bin/false <ftp_user>

svn checkout via shell script

Very often development servers only have self-signed certificate for ssl connection. I've recently had to create a script that would checkout from a https svn repository that would fail with "Server certificate verification failed: issuer is not trusted..." . Below is a workaround used to temporarily trust the certificate.

svn --username $SVN_USER --password $SVN_PASS --no-auth-cache checkout ${REPO_URL}/${REPO_PATH} $REPO_PATH <<EOF 2>/dev/null

Importing existing SSL key and certificate for tomcat

  1. Convert key and cert to a single pkcs12 format.

    openssl pkcs12 -export -inkey <pathto>/key.txt -in <pathto>/cert.txt -out cert.pkcs12

  2. Remove existing tomcat aliased PrivateKeyEntry from cacerts.

    keytool -delete -alias tomcat -keystore <pathto>/cacerts

  3. Use java-1.6 keytools to import PKCS12 keystoretype into existing cacerts keystore file.

    keytool -importkeystore -destkeystore cacerts -srckeystore cert.pkcs12 -srcstoretype PKCS12

  4. Note the alias of the newly imported PrivateKeyEntry, which would normally be 1.

    keytool -list -keystore <pathto>/cacerts | grep PrivateKeyEntry

  5. Change the alias to tomcat.

    keytool -changealias -alias 1 -destalias tomcat -keystore <pathto>/cacerts

Trusting CAS Self-signed Certs

Yales' CAS client attempts to verify the service ticket it received from CAS, and when it tries to connect to the CAS server, it encounters SSL handshake error caused by using a self-signed SSL certificate on the CAS server. The Java process running tomcat does not trust the certificate presented by the CAS server. This is part of Java security.

A work around the issue would be to tell Java to trust the self-signed certificate as below:

# keytool -importcert -trustcacerts -alias {cert_alias_name} -file \
          /path/to/self-signed.cer -keypass changeit -keystore  \

Use the below command to list:

$ keytool -list -keystore /usr/local/java/jre/lib/security/cacerts | grep -A 1 {cert_alias_name}

Comodo / PositiveSSL / InstantSSL Multi-domain SSL certificate installation on Plesk

If you're short of IP addresses and hosting multiple domains on a single IP requiring SSL connection to all domains, then a good solution would be to get the Multi-Domain certificate from Comodo, which is a single certificate containing more than one domain name, and that certificate is for a single server installation.

However, the use of Host Headers (which is how you can use a single IP for more than one SSL enabled domain) is not recommended for E-Commerce sites.

The multi-domain certificate can only be purchased from one of the Comodo resellers, or can apply to become one yourself.

To order the certs, you will need to first generate a Certificate Signing Request Key. This is easily done via Plesk admin UI.

  1. Login to the Plesk Control Panel.
  2. From the left hand menu, select 'Server'.
  3. Click on 'Certificates'.
  4. Click on the 'Add New Certificate' item.
  5. Fill out the information on the page. All items noted by red asterisks must be filled in
  6. Press the 'Request' button.
  7. You will then be returned to the Certificates menu. From the list at the bottom of the page, click on the certificate name that you just created. Mid-way down the page, there is a box. Copy the content of this box labelled 'CSR'.
  8. Paste the CSR into the order screen when purchasing the SSL certificate.

Shortly after ordering, the SSL certificate is emailed to you zipped along with the below CA certs:

  1. AddTrustExternalCARoot.crt
  2. PositiveSSLCA.crt
  3. UTNAddTrustServerCA.crt

The CA certs need to be concatenated and uploaded to Plesk as one single certificate and should follow the same order.

$ cat PositiveSSLCA.crt > CA.crt
$ cat UTNAddTrustServerCA.crt >> CA.crt
$ cat AddTrustExternalCARoot.crt >> CA.crt

Those files are available for download from Comodo's support site as well.

The order you place the contents of those files into a new file is important, and should be followed as outlined above. No blank lines should be added between the certificate contents when you copy the contents of the existing CA certs into a new file. You then provide this new file to Plesk when it asks for the CA Certificate.

In order to install the certificate, go back to the Certificate area in Plesk and upload or copy/paste the certs into the relevant areas.

Return to the Server Page and go to the IP address section. Click on the relevant IP address and apply the newly installed certificate.


When starting sendmail, I would get the below messgage:

Oct 18 23:59:01 srv02 sendmail[20857]: alias database /etc/aliases rebuilt by root
Oct 18 23:59:01 srv02 sendmail[20857]: /etc/aliases: 79 aliases, longest 22 bytes, 860 bytes total
Oct 18 23:59:01 srv02 sendmail[20862]: starting daemon (8.13.1): SMTP+queueing@01:00:00
Oct 18 23:59:01 srv02 sendmail[20862]: STARTTLS: CRLFile missing
Oct 18 23:59:01 srv02 sendmail[20862]: STARTTLS=server, Diffie-Hellman init, key=512 bit (1)
Oct 18 23:59:01 srv02 sendmail[20862]: STARTTLS=server, init=1
Oct 18 23:59:01 srv02 sendmail[20862]: started as: /usr/sbin/sendmail -bd -q1h
Oct 18 23:59:01 srv02 sm-msp-queue[20872]: starting daemon (8.13.1): queueing@01:00:00

Although, sendmail would still run without the CRL File and just complain about it missing. A quick way to include it in the sendmail configuration is to download revoke.crl from, add the below option in and rebuild the sendmail conf file as below.

Download revoke.crl:

# cd /usr/share/ssl/certs
# wget

Add the below line to "/etc/mail/" just below the "confSERVER_KEY":

define(`confCRL', `/usr/share/ssl/certs/revoke.crl')

Rebuild sendmail conf by running make:

# cd /etc/mail
# make

Check with the revoke.crl listed as below:

O CRLFile=/usr/share/ssl/certs/revoke.crl

Now restarting sendmail should not complain about the missing Certificate Revocation List (CRL) File.

Syndicate content