Site now SSL by default

Powered by Drupal
Submitted by Sam Hobbs on

encrypt-all-the-things.png Google recently announced that it is going to start prioritising websites that offer HTTPS by default in its search engine results. At first, the positive effect will be small to give webmasters time to switch to HTTPS, but it will gradually become more of a significant signal. This is a good thing for the internet: SSL doesn't cost much for webhosts, and it makes it more difficult to spy on everyone all the time! The Electronic Frontier Foundation praised the decision calling it a "bold and welcome move to protect users". I wanted to start offering some of the services I run on my server to other friends and family, and I couldn't easily install the CAcert root on all of their devices, so this seemed like a good time to purchase a cert. The following describes how I configured the various services (Apache, Postfix, Dovecot) to use the new certificate from COMODO.

Differences to CAcert certificate

Until now, I have used a certificate signed by CAcert for the site and used Apache's mod_rewrite to redirect unauthenticated users (everyone except me) back to http. I chose to do this because unless the CAcert root was installed on the client machine, the users would get a browser error; I also didn't want Google crawling the HTTPS site and penalising me for having duplicate content (http and https). Configuring Apache and the other services to use the cert signed by CAcert was easy because it was signed directly by the CAcert root: I just had to give Apache a path to the new certificate file, it sent the cert to clients when they made a connection, and it was accepted because it was signed by a trusted root certificate. However, commercial certificate authorities generally don't use their root certificates to validate domains because having the root key in constant use increases the likelihood that the key could be compromised. Instead, they use the root key to sign an intermediate certificate, and then use the intermediate key to validate domains. If they didn't do this and the root key was compromised, every operating system would have to push an update to remove the compromised root certificate from the trusted certificate store on users' machines; this way, if the intermediate key is compromised the certificate authority can revoke the intermediate cert and generate a new one without the root certificate being affected. The small downside of this is that Apache now needs to send a string of certs to each client containing every certificate between yours and the root cert, or the client will just check to see if your cert was signed directly by a root CA in its trusted certificate store, and reject it if it wasn't. The string of certs forms a chain of trust, i.e. "the was signed by intermediate_cert which was signed by root_ca". So, the first thing I had to do was concatenate the certificate files to make one jumbo certificate file.

Creating a certificate bundle

Comodo sent me a .zip archive containing the following files:

  • AddTrustExternalCARoot.crt
  • COMODORSAAddTrustCA.crt
  • COMODORSADomainValidationSecureServerCA.crt
  • samhobbs_co_uk.crt

To unzip the archive use the unzip command:

mkdir ~/certs
mv ~/certs/
cd ~/certs

The order of the certs in the concatenated file is important: you want your certificate at the top of the file, the one that signed your cert (intermediate1) below that, and the one that signed that one (intermediate2) below that. The root certificate should be left off the file: each client will already have a copy of this file in its trusted certificate store... and if they don't then sending them it won't help, the cert will still be rejected! Actually, the RFC for TLS says that you MAY include the anchor (root cert), which means it will work either way... but the QUALYS SSL Labs test, which we will be using later, will flag it up as an anomaly if you do. So... which file is which? You can get information about certs in a human readable format by using this command:

openssl x509 -text -in /path/to/your/cert.crt

example output:

        Version: 3 (0x2)                                                                     
        Serial Number:                                                                       
    Signature Algorithm: sha256WithRSAEncryption                                             
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA                                                             
            Not Before: Aug 15 00:00:00 2014 GMT
            Not After : Aug 14 23:59:59 2019 GMT
        Subject: OU=Domain Control Validated, OU=PositiveSSL,
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 

            X509v3 Subject Key Identifier: 
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies: 

            X509v3 CRL Distribution Points: 

                Full Name:

            Authority Information Access: 
                CA Issuers - URI:
                OCSP - URI:

            X509v3 Subject Alternative Name: 
    Signature Algorithm: sha256WithRSAEncryption

And if you just want to know who issued the cert (who signed it) then use this command:

openssl x509 -noout -in samhobbs_co_uk.crt -issuer

Example output:

issuer= /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA

So we can see that my cert was signed by COMODORSADomainValidationSecureServerCA.crt. Using the same command on the other certs reveals that the order, from root to my cert, is:

  1. AddTrustExternalCARoot.crt (ROOT)
  2. COMODORSAAddTrustCA.crt
  3. COMODORSADomainValidationSecureServerCA.crt
  4. samhobbs_co_uk.crt

So, to combine all of these files into one we can use the cat command, listing them in reverse order and omitting the root cert:

cat samhobbs_co_uk.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt >

Configuring Services

So, now that we have a combined certificate file, let's configure Apache2, Dovecot and Postfix to use it: In the following examples, I'm using these paths as an example:

  • The certificate (on its own) is located at /etc/ssl/certs/
  • The certificate bundle is located at /etc/ssl/certs/
  • The key file is located at /etc/ssl/private/


In your postfix configuration file /etc/postfix/, find these two parameters and edit them to match these lines:


As you can see, Postfix only needs the certificate bundle and the key file; the certificate file on its own is not used.


The SSL configuration for Dovecot is found at /etc/dovecot/conf.d/10-ssl.conf, and needs the key file and the certificate bundle, similar to Postfix:

ssl_cert = </etc/ssl/certs/
ssl_key = </etc/ssl/private/

NB: the < isn't a mistake, don't leave it out!


Apache2 is the odd one out here, because it requires three parameters in versions before 2.4.8, like so:

SSLCertificateFile      /etc/ssl/certs/
SSLCertificateChainFile      /etc/ssl/certs/
SSLCertificateKeyFile      /etc/ssl/private/

I.e. the cert on its own, the certificate bundle and the key file. In new versions (greater than 2.4.8) things have improved: SSLCertificateChainFile is depreciated; SSLCertificateFile was extended so that you can pass it a certificate bundle... so now Apache just needs two parameters:

SSLCertificateFile      /etc/ssl/certs/
SSLCertificateKeyFile      /etc/ssl/private/

If you're not sure which version of Apache you're running, you can check with this command:

apache2 -v

At the time of writing (01 Sep 2014), the version of Apache2 in the Ubuntu 14.04 repositories is 2.4.7 and the version in the Raspbian/Debian stable repos is 2.2.22; both of these packages use the "old way" but Ubuntu will soon get the new version.

HTTP Strict Transport Security (HSTS)

If your site is HTTPS only, you can make use of a technology called HTTP Strict Transport Security (HSTS), where Apache sends a header to the client's browser that tells it to always connect with HTTPS. This site is using HSTS now: if you have visited before and you type in your browser it will rewrite to before it sends a request to my server. This is different to rewriting HTTP to HTTPS on the server because the rewrite is done client side, and can help prevent certain kinds of Man In The Middle (MITM) attacks. Note that you still need to have a HTTP virtualhost that rewrites to HTTPS because this only works when someone has visited to the site before: new users will need a server-side rewrite before their browser has stored the header. Setting up HSTS is really simple: all you need to do is add this to your HTTPS virtualhost:

Header add Strict-Transport-Security "max-age=15768000"

And then reload Apache:

sudo service apache2 reload

Obviously, don't do this for sites where you actually want to have separate HTTP and HTTPS sites on the same domain name, or you won't be able to access the HTTP site without clearing your cache to remove the header.

Perfect Forward Secrecy

While we are talking about SSL, I thought I'd mention Perfect Forward Secrecy (PFS). This is technology that helps protect users by ensuring that if a SSL key is decrypted in the future it couldn't be used to decrypt past sessions that were captured (by security services or your ISP, for example). Or in other words (from the EFF article below):

When an encrypted connection uses perfect forward secrecy, that means that the session keys the server generates are truly ephemeral, and even somebody with access to the secret key can't later derive the relevant session key that would allow her to decrypt any particular HTTPS session. So intercepted encrypted data is protected from prying eyes long into the future, even if the website's secret key is later compromised.

You can read more about PFS on the EFF's website. So, how do we configure PFS on Apache? Luckily, there are already some useful guides at and, and the Mozilla wiki is useful too. I don't have any special knowledge of the various ciphers used in SSL/TLS, so the configuration below was taken from the Mozilla wiki, using the backward compatible ciphersuite. The order of the list prioritises strong ciphers that support forward secrecy. First, you need Apache 2.3.3 or higher (see earlier in this article for how to check your version). Next, put this inside your SSL virtualhost:

SSLProtocol             all -SSLv2
SSLHonorCipherOrder     on
SSLCompression          off

Now test your configuration with the Qualys SSL Labs test! You can read some more about VirtualHost files on Apache2 in this tutorial of mine.


I followed the instructions listed here with a comodo SSL certificate and have succeeded in setting up Apache without any issues but dovecot keeps giving me an issue when I attempt to log into the mail server: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert.

I have verified that the key and crt file match through and verified the path to the files in the configuration file. Any ideas what may be causing the issue?


First check to make sure you don't have more than one set of ssl cert/key parameters in your file (in case you forgot to comment one, for example). Then check to make sure you didn't cat your certs in the ca-bundle in the wrong order (dovecot may only check the first one or something like that, it may think you're trying to use the CA root cert with your own key!). Sam


Just a couple of questions, if I may:

- while generating the certificate at Comodo, it asks "Select the server software used to generate the CSR". One who followed the steps in your "SSL Certificate Signing with CAcert for Raspberry Pi, Ubuntu & Debian" should select which option?

- I was recently advised to stop using SSLv3 (use TLS only) due to a vulnerability called POODLE ( - have you heard about this before?



Sam Hobbs

Wed, 03/18/2015 - 06:38

In reply to by Joao

I can't remember what the options were, but the answer is openssl. Yep, i have that protocol disabled but this tutorial was written before the vulnerability was discovered and i forgot to update it! To disable SSLv3, change the line at the top of the perfect forward secrecy section to:
SSLProtocol all -SSLv2 -SSLv3


Sorry to come back to this but the reason I asked in the first place is because openssl is not listed as an option... :-) I'll try some options until it works.

Regarding SSLv3, I had to also disable it for Postfix ( and Dovecot (10-ssl).



Sam Hobbs

Wed, 03/18/2015 - 14:00

In reply to by Joao

What are the options? I can't see the page - if you give me a list I can probably tell you which one it is. Sam

Your link is broken, maybe it requires you to be logged in or have a particular cookie? Take a screenshot and upload it to imgur or something, or copy and paste the list? Sam

Not sure what is wrong with the link but I guess that is not important: for the record, I tried the "OTHER" option and everything is working just fine.

Thanks for looking into this anyway.



Hi Sam,

I've gone down the Comodo SSL route also for my site and all has gone well aside from the Dovecot aspect!
The site now defaults to the https:// version when visited but when you go to the squirrelmail (on Chrome) it red crosses through the https and states that the page it connects with has insecure connections. It wont take too much imagination to see the page yourself as i've not change from the default url on squirrelmail yet.

I can only assume that is the Dovecot aspect its complaining about!

The mail logs show no errors and the same certificate / key works fine for postfix and the main site.

Any thoughts?? I've gone round in circles most of the evening trying to get to the bottom of this one?!


I reckon it's because you specified a non-https URL for your arkadiem image. Firefox's "inspect element" reveals:
<img src="" alt="aRKaDieM Web Mail Logo" height="85" width="266">
Nice site by the way, I really like the design. Sam

Thanks Sam that does indeed appear to be the issue. I've moved the image to the secure image store and go the padlock back!
When logged in - however there is a warning triangle but it still appears sucure, do you have that too? Is it due to the plugins / addons in SquirrelMail do you think?

On another note - I had this in my inbox this morning:

Transcript of session follows.

Out: 220 ESMTP Postfix (Debian/GNU)
Out: 250-SIZE 10240000
Out: 250-VRFY
Out: 250-ETRN
Out: 250-8BITMIME
Out: 250 DSN
Out: 454 4.7.0 TLS not available due to local problem

Session aborted, reason: lost connection

Looking into it my logs show the following:

Apr 12 08:21:10 arkadiem postfix/smtpd[20052]: initializing the server-side TLS engine
Apr 12 08:21:10 arkadiem postfix/smtpd[20052]: warning: cannot get RSA private key from file /etc/ssl/private/www_arkadiem_co_uk.key: disabling TLS support
Apr 12 08:21:10 arkadiem postfix/smtpd[20052]: warning: TLS library problem: 20052:error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch:x509_cmp.c:330:

I have checked both the certificate and key and both are valid and working through the commands:

openssl rsa -in /etc/ssl/private/www_arkadiem_co_uk.key -text -noout
openssl x509 -in /etc/ssl/certs/ -text -noout

I've checked a few other forums etc but nothing seems to work to get postfix to use TLS with the new certs.
I'm happy to e-mail logs / config files directly if your willing to look?

p.s. Thanks for the love on the site :) I've worked hard on simplicity and functionality!!

I don't actually use squirrelmail any more since I upgraded my server to an Intel NUC (it has more oomph so I chose to run roundcube instead). Have another look with inspect element and see if there are any other bits and pieces being served over http once you log in; the connection from squirrelmail to dovecot shouldn't affect the padlock because the browser is unaware of it. It looks a bit like the cert and key don't match, are they the same files you're using for Apache? What are the permissions on the key file? Sam

I'll take look at roundcube...i'm unning all this on a my rpi2 which is barely breaking a sweat so it'll be interesting to see if how it runs on it!
I've gone through the inspect and cant see anything - frankly im not that worried as it gives a green tick when logged in - just a few warnings which migrating to roundcube may fix!?

With the certs..exactly the same file location (/etc/ssl/certs|private/) as apache2, dovecot and postfix which is what is confsuing me as its working on apache2.

I looked at the permissions and even went as far as copying the cert and key to a new location specific to postfix with chmod 640 and chown to postfix:postfix. Still got the same error.

Currently they are owned by root with -rw-r--r-- for both the key and ca-bundle.

If I change the owner I would be better copying the certificates into sperate areas for each service so they have the correct ownership if thats required.

Confused as everything seems to be working fine - just not encrypting the TLS which amazon wanted to use (hence the webmaster error email).


Hmm, are you sure your key has 644 permissions? It should be 640 or 600 (only root should be able to read it). When postfix is started with sudo it reads the key with root privileges and then drops them to run as the postfix user. Sam

Hey Sam,

I changed the certs and key to 640 but still get the same key errors.
Changing to the snake-oil default SSL makes it work and when I send myself a secure mail from a gmail account you can see in the logs it working as intended!

Can you think of a reason not to keep the configuration in this way? My take is that its only a local server SSL authentication that should never be seen from outside my network so it shouldn't matter that its a self signed internal SSL.

Good tip on roundcube btw! It looks great and very straight forward - just got some sending issues but i'm running multiple apache2 over two rpi's to keep my weather data flowing so I wont bore you with that one :)


It's just the key that should be private, you send the cert to people when they connect to you anyway, so it doesn't matter which users and processes can read it. I don't know what to suggest really, have a look at your key file (make sure it really is a key file!) and your certificate bundle and make sure they match. Check the certs in the bundle are in the correct order (or postfix may be trying to match your key to the root cert). You want a proper cert for postfix because it is used by email clients when submitting mail, and also when sending server to server messages. Sam

Thanks for your input Sam, much appriciated! Got it all sorted now.
The .key file was absolutly fine, the .ca-bundle was absolutly fine, the .crt was absolutly fine - but when I ran the following:

openssl x509 -noout -modulus -in | openssl md5
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in cert.key | openssl md5

It showed a miss-match between the ca-bundle and the key, however it did match on the .crt!
So confused as to why thats the case as all were in the .zip from Comodo but hey thats life!

Despite checking this earlier today it all comes clear after wasting a day going around in circles!

Long story short - thank you, my Comodo SSL is now covering apache2, dovecot and postfix without error :)
Oh and I found out about roundcube!

Thanks again mate!

Hi Sam,

Which Comodo SSL cert would you advise? My site is only for owncloud, squirrelmail and a basic website one day. I see thee are various types of SSL certs from Comodo. I think I'm going to give up on the CAcert, because I can't seem to get it working properly...I'll just pay Comodo and hope I can have SSL by default too.



Hi Sam,

I purchased the Comodo Positive SSL and changed the certs paths for the vhosts in dovecot, postfix and apache and squirrelmail. Like before with CAcert my site is unavailble...

I'm at my wits end and am confident that the issue must be my vhosts. I've read the vhosts tutorial a few times after printing it out to see what I've done wrong but can't put my finger on it. I've commented out all my vhosts apache.conf, default-ssl.conf,, 10-ssl.conf with the hope that I can focus on one vhost at a time and bring apache back to life...

Is there any way that you could possibly help, please?



Hi Sam,

Still working to make sense of it all...Apache2 error.log shows a mismatch between my and domain.key

[Sun Mar 06 20:10:28.748533 2016] [ssl:emerg] [pid 7063] AH02565: Certificate and private key from /etc/ssl/certs/ and /etc/ssl/private/ do not match

Following your guide, but I didn't receive seperate files from Comodo...they already had a ca-bundle and the crt file...

Any idea how to fix it?



Well, two things to check: 1) is the key definitely the one you generated the cert from? 2) which version of apache are you using, and which of the two methods I described are you using (cert and bundle or just bundle?). Does the bundle you are using definitely contain your cert? If it doesn't you'd get that warning because the cert you are sending is the comodo intermediate cert, not your cert, so it doesn't match the key file. Sam

Hi Sam,

1) The key is the correct one - [the ca-bundle was created using the file names matter? Should it be identical?]

2) Apache2 version 2.4.10 and I don't know if the ca-bundle contains the cert...I checked the ca-bundle...has 3 files (encryptions) in it. I used the 2nd of the two methods.

Do I need to combine the ca-bundle and the crt? Like you did here:

So, to combine all of these files into one we can use the cat command, listing them in reverse order and omitting the root cert:

cat samhobbs_co_uk.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt >

But like so:

cat pi-box_co_uk.crt >

...and try it again?



File names don't matter. The tutorial says the ca-bundle has to contain the cert, so make sure it does, our it won't work. You can use the commands in the tutorial to get information about the certs in the bundle. If your cert isn't in there you can cat it in like you said. Sam

Hi Sam,

Glad to announce that my Comodo SSl certs are now finally working. The cat command gave me a permissions error, even if I used I used sudo nano to copy and paste the crt into the ca-bundle, putting the crt at the top...and then it worked.

Squirrelmail is now using the ssl cert. No to get owncloud on ssl!

Many many thanks for all your support!



Hi Sam,

Thanks for that...I also have a p7b file that came from Comodo...I don't know what it does...



Hi Sam,

My works perfectly on ssl...but when I tried it gives an error on port 443. I played around a bit with default-ssl.conf but can't get owncloud to work via or When I comment out the vhost for apache.conf https force part port 80 and leave the rest I get both squirrelmail and owncloud via http and obviously not via https.

I therfore assume that owncloud will need it's own vhost or default-ssl need to be configured 'better'. The other thing I also noticed is that when I only go to or they default to squirrelmail...



Hi Sam,

Owncloud still doesn't work for me regarding SSL. I've tried everything my knowledge and understanding allows up to now. Squirrelmail works fine via SSL, but not Owncloud...I know it has to be a vhost somewhere and I've tinkered with it loads the last few days, but to no avail. I can get to in a round about way by adding some settings in default-ssl, but when I change it to try and get to it from outside the LAN, it doesn't work.

Any ideas?



Hi Sam,

I glad to announce my site is now SSL by default! Woop woop! It was a struggle for me to sort the vhosts out especially with Owncloud...I eventually found a post on a forum where someone called Feathers McGraw used you site as an example and suggested that the owncloud vhost for port 443 is placed above the squirrelmail port 443 vhost because apache.conf runs before default-ssl.conf on the apache server...

It didn't make a lot of sense to me but I tried it and it worked! I also deleted all the lines of code that wasn't needed for my owncloud vhosts in my attempt to get owncloud to work outside my LAN.

I learned a lot in this process and kudos once again to you for your tutorials.



Add new comment

The content of this field is kept private and will not be shown publicly.

Filtered HTML

  • Web page addresses and email addresses turn into links automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.