ssl

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:

http://certificates.godaddy.com/repository

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:

This should then trust the ssl cert.

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:

Configure for tls/ssl connection:

chroot and bindsocket to listen to single IP:

Setup passive ftp ports:

Create the certs:

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

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

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.

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

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:

Use the below command to list:

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.

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:

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 cacert.org, add the below option in sendmail.mc and rebuild the sendmail conf file as below.

Download revoke.crl:

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

Rebuild sendmail conf by running make:

Check sendmail.cf with the revoke.crl listed as below:

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