This guide is for Symetricore products available in the Amazon Web Services (AWS) marketplace that come preconfigured with self-signed SSL certificates.
This should be in the documentation for the product. A simple test of whether this is the type of product can be made by the way you access the product. If you are using web access that is something like http://a.b.c.d then you are not using SSL. The you access the product using the URL https://a.b.c.d then you are using SSL. The self-signed certificates causes the warning with web browsers about trust issues etc. We are going to replace these certificates with ones you have obtained from a certificate authority (CA). Interestingly the level of security as far as the way your data is encrypted over the internet is the same. The difference is getting rid of the browser warning and the display of the padlock symbol on your webpage.
You will also need to have a domain name to use with your certificate. You’ll also need to use an elastic IP address or DDNS to point your DNS to.
You may or may not decide this is worth the extra cost.
Step 1: Obtain your own SSL certificates for your domain
A quick internet search for SSL certificates should reveal many folks offering SSL certificates. You can use certificates from companies like Comodo, Symantec, Verisign or anywhere else you might want to shop. These instructions should be used in conjunction with any information from your certificate issuer.
Some certificate vendors might supply certificates that might need to be concatenated into one certificate file, this is the case with Comodo who we use for our certificate for example.
You should end up with three files called something like the following. Obviously substituting the name of your domain certificate.
yourdomain.com.crt yourdomain.com.key yourdomain.com.cer
Step 2: Copy the certificates to your AMI
You need to copy over your certificates to the AMI you want to install them on. You can use sftp to copy the files over. This command looks very similar to the ssh command that you might already use to connect to your box. If you are using Windows you can use a product like WinSCP to copy the files over.
sftp -i mycert.pem ubuntu@a.b.c.d
Use the sftp command ‘put’ to copy the file over from your local machine.
put yourdomain.com.crt put yourdomain.com.key put yourdomain.com.cer
Next you will need to connect to your box to copy over the certificates to the right location for apache to use them. Connect to your instance.
ssh -i mycert.pem ubuntu@a.b.c.d
Copy over the files to the apache ssl directory.
sudo mkdir /etc/httpd/ssl sudo cp yourdomain.com.crt yourdomain.com.key yourdomain.com.cer /etc/httpd/ssl
Step 4: Configure Apache
Edit the ssl configuration file by doing.
sudo nano /etc/httpd/conf.d/ssl.conf
if you scroll down a few lines in the file you should see something like this.
# Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. A new # certificate can be generated using the genkey(1) command. SSLCertificateFile /etc/pki/tls/certs/localhost.crt # Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if # you've both a RSA and a DSA private key you can configure # both in parallel (to also allow the use of DSA ciphers, etc.) SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
We are interested in the lines hi-lighted above. They configure apache to point to the default self signed certificates that we provide with our products. These are the ones we are going to replace.
Comment out the default certificates and underneath enter the following. Obviously substituting the name of your domain certificate.
# Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. A new # certificate can be generated using the genkey(1) command. #SSLCertificateFile /etc/pki/tls/certs/localhost.crt # Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if # you've both a RSA and a DSA private key you can configure # both in parallel (to also allow the use of DSA ciphers, etc.) #SSLCertificateKeyFile /etc/pki/tls/private/localhost.key # Updated for real certificates SSLCertificateFile /etc/apache2/ssl/yourdomain.com.crt SSLCertificateKeyFile /etc/apache2/ssl/yourdomain.com.key SSLCACertificateFile /etc/apache2/ssl/yourdomain.com.cer
Lastly we need to restart apache for it to recognize the new configuration.
sudo service httpd restart
Step 4: Test it out
Now when you go to your product via your web browser you no longer see the warning about the certificate being invalid. You should also see the padlock symbol in the browser. Depending on the browser you can click on it and examine the certificate.
Note that you’ll need to access your product using the domain name you have in the certificate. That is using https://www.yourdomain.com rather than using the IP address of the server. This means you will also need configure the DNS for your domain name to go to the correct public IP address.
You can still access your instance via the public IP address but you’ll most likely encounter certificate issues.