Site now SSL by default

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 samhobbs.co.uk_cert 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 samhobbs_co_uk.zip 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 samhobbs_co_uk.zip ~/certs/samhobbs_co_uk.zip
cd ~/certs
unzip samhobbs_co_uk.zip

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:

Certificate:                                                                                 
    Data:                                                                                    
        Version: 3 (0x2)                                                                     
        Serial Number:                                                                       
            96:3b:4e:d8:b9:2c:7a:6c:1d:08:4f:fd:e1:c0:3f:3a                                  
    Signature Algorithm: sha256WithRSAEncryption                                             
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA                                                             
        Validity
            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, CN=samhobbs.co.uk
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d3:a3:1a:49:1f:02:6e:a5:38:75:0f:32:2f:89:
                    fc:a0:b3:e5:51:0f:25:c4:17:5c:3c:82:1a:ea:df:
                    a5:ad:03:f0:e3:76:8d:b7:7a:80:8c:41:88:8f:34:
                    26:01:a3:b2:49:60:d1:7c:39:ac:ed:31:5f:30:6a:
                    b7:54:2a:f4:ee:a3:a7:c2:1b:5b:14:17:94:b2:9a:
                    16:87:04:43:d7:12:25:8e:ef:2a:ac:5e:24:3f:73:
                    12:c0:27:ff:26:f5:3a:8b:64:89:01:32:d8:db:f6:
                    f6:19:7b:b4:4e:82:14:6a:a2:de:db:dc:c3:b6:76:
                    08:47:48:a0:30:7a:31:b2:7c:38:b1:c1:2f:b4:bc:
                    7c:61:3e:76:ea:c1:97:47:29:d7:5c:cb:77:4d:a6:
                    68:5f:34:57:dc:36:ec:27:c3:b8:98:9a:8c:d3:15:
                    c4:7d:bd:5c:f0:9d:49:27:d2:6e:a9:f7:51:b3:16:
                    58:4f:b0:36:45:33:93:81:7c:8d:93:16:ca:dd:20:
                    21:84:c6:e1:a4:ce:72:b3:1f:6f:84:f2:89:65:4e:
                    ce:1e:b8:ef:f3:06:4a:4a:44:a7:99:20:06:72:c8:
                    50:9f:37:e2:39:be:ea:1f:75:5c:0a:69:6f:e2:4e:
                    99:88:89:18:8e:16:51:b3:35:1b:52:29:1a:77:9b:
                    82:79
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:90:AF:6A:3A:94:5A:0B:D8:90:EA:12:56:73:DF:43:B4:3A:28:DA:E7

            X509v3 Subject Key Identifier: 
                81:6A:52:BA:72:60:2F:A3:F1:9F:00:20:36:0A:E9:14:BC:37:BC:C3
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.6449.1.2.1.3.4
                  CPS: https://secure.comodo.net/CPS
                Policy: 2.23.140.1.2.1

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl

            Authority Information Access: 
                CA Issuers - URI:http://crt.comodoca.com/COMODORSADomainValidationSecureServerCA.crt
                OCSP - URI:http://ocsp.comodoca.com

            X509v3 Subject Alternative Name: 
                DNS:samhobbs.co.uk, DNS:www.samhobbs.co.uk
    Signature Algorithm: sha256WithRSAEncryption
         0c:29:6b:2a:18:d4:25:54:9c:88:6a:3d:1c:8b:2f:99:0f:88:
         10:4f:11:56:cd:28:cc:67:6f:d3:de:c6:f1:54:f8:b5:1a:b7:
         6b:94:9c:74:7c:e2:41:49:46:ed:a7:c2:49:c6:5b:c2:02:c9:
         08:c8:26:fd:f2:15:1d:28:c8:24:ca:aa:6a:e2:1e:74:96:9c:
         d1:f9:78:58:3a:f2:8c:bf:e7:f9:37:3b:eb:ac:c5:09:3f:23:
         fc:63:4a:aa:d9:64:38:78:5b:83:69:81:b2:a6:3e:83:a6:bd:
         9a:2a:82:4e:3d:ee:ec:15:2f:53:a7:b2:00:89:e2:97:d2:ee:
         6a:75:38:9a:7c:8b:c6:67:fe:be:7f:0f:ee:24:8c:11:fa:b3:
         54:1d:e0:09:32:ae:c6:eb:66:b8:94:a4:82:db:6b:0f:9d:9d:
         c2:88:5d:80:7e:28:8d:ff:b9:c2:69:2c:29:0d:ea:e1:77:96:
         47:48:2e:37:fb:eb:fd:74:e6:27:6f:2d:37:b4:1a:29:2a:11:
         1f:39:34:45:a2:bf:d2:71:13:b1:dc:1b:5d:27:6d:78:2a:80:
         32:76:c1:1e:b9:c2:f1:ed:d7:ed:e3:16:63:43:6e:78:8c:9b:
         49:af:a6:15:dd:6e:2a:fa:e4:55:b5:b0:7b:81:51:9e:b3:cb:
         52:39:f0:cb
-----BEGIN CERTIFICATE-----
MIIFUDCCBDigAwIBAgIRAJY7Tti5LHpsHQhP/eHAPzowDQYJKoZIhvcNAQELBQAw
gZAxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTYwNAYD
VQQDEy1DT01PRE8gUlNBIERvbWFpbiBWYWxpZGF0aW9uIFNlY3VyZSBTZXJ2ZXIg
Q0EwHhcNMTQwODE1MDAwMDAwWhcNMTkwODE0MjM1OTU5WjBSMSEwHwYDVQQLExhE
b21haW4gQ29udHJvbCBWYWxpZGF0ZWQxFDASBgNVBAsTC1Bvc2l0aXZlU1NMMRcw
FQYDVQQDEw5zYW1ob2Jicy5jby51azCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBANOjGkkfAm6lOHUPMi+J/KCz5VEPJcQXXDyCGurfpa0D8ON2jbd6gIxB
iI80JgGjsklg0Xw5rO0xXzBqt1Qq9O6jp8IbWxQXlLKaFocEQ9cSJY7vKqxeJD9z
EsAn/yb1OotkiQEy2Nv29hl7tE6CFGqi3tvcw7Z2CEdIoDB6MbJ8OLHBL7S8fGE+
durBl0cp11zLd02maF80V9w27CfDuJiajNMVxH29XPCdSSfSbqn3UbMWWE+wNkUz
k4F8jZMWyt0gIYTG4aTOcrMfb4TyiWVOzh647/MGSkpEp5kgBnLIUJ834jm+6h91
XAppb+JOmYiJGI4WUbM1G1IpGnebgnkCAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaA
FJCvajqUWgvYkOoSVnPfQ7Q6KNrnMB0GA1UdDgQWBBSBalK6cmAvo/GfACA2CukU
vDe8wzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggr
BgEFBQcDAQYIKwYBBQUHAwIwUAYDVR0gBEkwRzA7BgwrBgEEAbIxAQIBAwQwKzAp
BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwCAYGZ4EM
AQIBMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NP
TU9ET1JTQURvbWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5jcmwwgYUGCCsG
AQUFBwEBBHkwdzBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5jb21vZG9jYS5jb20v
Q09NT0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMC0GA1UdEQQmMCSCDnNh
bWhvYmJzLmNvLnVrghJ3d3cuc2FtaG9iYnMuY28udWswDQYJKoZIhvcNAQELBQAD
ggEBAAwpayoY1CVUnIhqPRyLL5kPiBBPEVbNKMxnb9PexvFU+LUat2uUnHR84kFJ
Ru2nwknGW8ICyQjIJv3yFR0oyCTKqmriHnSWnNH5eFg68oy/5/k3O+usxQk/I/xj
SqrZZDh4W4NpgbKmPoOmvZoqgk497uwVL1OnsgCJ4pfS7mp1OJp8i8Zn/r5/D+4k
jBH6s1Qd4AkyrsbrZriUpILbaw+dncKIXYB+KI3/ucJpLCkN6uF3lkdILjf76/10
5idvLTe0GikqER85NEWiv9JxE7HcG10nbXgqgDJ2wR65wvHt1+3jFmNDbniMm0mv
phXdbir65FW1sHuBUZ6zy1I58Ms=
-----END CERTIFICATE-----

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 > samhobbs.co.uk-new.ca-bundle

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/samhobbs.co.uk-new.crt
  • The certificate bundle is located at /etc/ssl/certs/samhobbs.co.uk-new.ca-bundle
  • The key file is located at /etc/ssl/private/samhobbs.co.uk-new.key

Postfix

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

smtpd_tls_cert_file=/etc/ssl/certs/samhobbs.co.uk-new.ca-bundle
smtpd_tls_key_file=/etc/ssl/private/samhobbs.co.uk-new.key

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

Dovecot

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/samhobbs.co.uk-new.ca-bundle
ssl_key = </etc/ssl/private/samhobbs.co.uk-new.key

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

Apache

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

SSLCertificateFile      /etc/ssl/certs/samhobbs.co.uk-new.crt
SSLCertificateChainFile      /etc/ssl/certs/samhobbs.co.uk-new.ca-bundle
SSLCertificateKeyFile      /etc/ssl/private/samhobbs.co.uk-new.key

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/samhobbs.co.uk-new.ca-bundle
SSLCertificateKeyFile      /etc/ssl/private/samhobbs.co.uk-new.key

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 http://samhobbs.co.uk in your browser it will rewrite to https://samhobbs.co.uk 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 scottlinux.com and ggramaize.wordpress.com, 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
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK
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.

Type: 

Comments

Was it this post? That's me! Lol.

Well done for figuring it out. I feel like I learn way more when I have had to troubleshoot problems than when everything goes well first time, hopefully the same is true for you!

Sam

Hi Sam,
I consider to add a commercial SSL such as yours. There are two things I want to your advices. One is the root.crt. What is the exact purpose on it? My friend told me a free SSL-Let's Encrypted. Actually, I refer some on-line tutorials and try to install on my apache but fail to complete installation. This SSL didn't support wildcard, but I primally thought I could apply each for each. (i.e. one for helloworld.org, two for www.helloworld.org, mail.helloworld.org and etc...) Yet I didn't install this SSL completely. Otherwise, there are some constrains on it such as a limit on clients connecting times. So, I decide to give up to research it currently. Here it's the web address(https://letsencrypt.org/certificates/). I saw the root.pem. It seems to purpose to prolong and to revoke SSL certificate. I am not sure that I am right or wrong on this idea? There aren't any steps to concatenate about root(AddTrustExternalCARoot.crt (ROOT)). Briefly, the CAcert is 2 layer hierarchy(SelfSigned) and the most commercial one is 3 layer hierarchy. Hope I didn't figure out wrongly. Haha!

The second question is about the commercial COMODO. Their production lists are quite long. However, I consider wildcard this feature. There are fairly economic price from resellers who I search on-line. May I know your details of your procurement, such as price or specific product name?

Really thanks your devotion and efforts on teaching us and making us successfully build sites.
Best regards,
Jeff

Jeff,

I haven't used Let's Encrypt, but I've heard good things.

When you ask about root.crt, do you mean the copy of the company's root certificate that should be pre-installed in your OS? It is the public part of their key, used to identify them when they sign a certificate. Your OS knows that certificates signed by the key that matches that root certificate have been validated by the company, so it trusts them. The intermediate certs do the same thing (root has validated this person is trustworthy to sign other certificates, and they have signed this certificate, therefore it is trusted).

Does that help?

As for your question, I used Comodo positive SSL, which was a reasonable price. The website in that link is a decent price comparison for certificates.

Sam

Hi Sam,
Thanks your answer and then I refer some articles about "public key" algorithm. I read a book that is using a toner method to illustrate the operation principle. (i.e. One uses "the public color" and "a private color" to mix a color for exchanging data and then get the other side's mixed color to difference(i.e. to subtract) "the public color" to get the other side's assigned color.) And Let's Encrypt is using "public key" twice for enhancing its reliability, isn't it? I share my installation experience.

Here I post my virtual host configuration. The # sign might not be necessary lines. What I got bothered with "/" on Redirect "/" "https://www.mydomain.com/" this line. This made me stocked while I didn't set up a "/" on the tail. Because the directory got wrong on "www.mydomain.com.well-known/acme-challenge/thecertificate". Behind your address, it must be a "/" to separate the /.well-known. My command is "sudo certbot-auto certonly webroot -w /var/www/mywebsite/ -d www.mydomain.com". If it is also valid to combine the domain together(i.e. It's without www on the DNS setting.), there is to add "-d mydomain" right after your previous domain. The command is "sudo certbot-auto certonly webroot -w /var/www/mywebsite/ -d www.mydomain.com -d mydomain.com". This case is specific on your virtual host owning "ServerAlias mydomain.com" this conf. file. Otherwise, I use drupal7 and there is a patch necessary for .well-known directory. Kindly refer this https://www.drupal.org/node/2408321#comment-11614247. Thanks again.

#============================ MYWEBSITE ============================

# DocumentRoot /var/www/mywebsite/
ServerName www.mydomain.com
# ServerAdmin wemaster@mydomain.com

#
# Options FollowSymLinks
# AllowOverride All
# Order allow,deny
# allow from all
#

# ErrorLog ${APACHE_LOG_DIR}/mywebsite/error.log
# LogLevel warn
# CustomLog ${APACHE_LOG_DIR}/mywebsite/ssl_access.log combined
Redirect "/" "https://www.mydomain.com/"

#============================ SSL_MYWEBSITE============================

DocumentRoot /var/www/mywebsite/
ServerName www.mydomain.com
ServerAlias mydomain.com
ServerAdmin webmaster@mydomain.com

Options FollowSymLinks
AllowOverride All
Order allow,deny
allow from all

ErrorLog ${APACHE_LOG_DIR}/mywebiste/error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/mywebsite/ssl_access.log combined

SSLEngine on
# SSLCertificateFile /etc/ssl/certs/mycacert.crt
# SSLCertificateKeyFile /etc/ssl/private/mycacert.key
SSLCertificateFile /etc/letsencrypt/live/www.mydomain.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.mydomain.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.mydomain.com/chain.pem
SSLCACertificateFile /etc/letsencrypt/live/www.mydomain.com/fullchain.pem

Hi Sam,

I purchased the Comodo Positive SSL and followed your tutorial on the Configuring Services part.

Apache [2.4.10 (Raspbian)], failed to load when i put the .ca-bundle in /etc/apache2/sites-available/default-ssl.conf due to a key - certificate mismatch (cat /var/log/apache2/error.log)

-BUT-

it loaded normally after i put the .crt instead of the .ca-bundle and rebooted.

So my apache configuration looks like this:

SSLCertificateFile /etc/ssl/certs/your_certificate.crt
SSLCertificateKeyFile /etc/ssl/private/your_key.key

Is putting the .crt alone in the configuration file a proper solution?

Both .crt and .ca-bundle are located in /etc/ssl/certs/ but the bundle file does not contain the crt itself as far as checked.
Also the private key and the .ca-bundle do not match in https://www.sslchecker.com/matcher but the .crt does..

I find it kind of strange but i thought i shoud share it here because it could save someone the time to figure it out (if that is a solution indeed).

Thank you for your useful and well written tutorials!

Unfortunately i have to confirm that the above solution is not 100% correct.

https://www.ssllabs.com/ssltest/analyze.html gave the website a "B" rating due to the fact that the .ca-bundle is not present.

So, for anyone having the same key certificate mismatch problems the proper solution is:

1) Check your key/csr - certificate and key/csr - ca-bundle at https://www.sslchecker.com/matcher.
If you find that the ca-bundle does not match the key but the cert does you have the same problem as me.
If not something is wrong with your key / csr and you have to start over.

2) Either put both csr and ca-bundle in your apache configuration (use the old way) OR combine them in a new ca-bundle that contains everything. Use Sam's "Creating a certificate bundle" instructions above.

After these steps https://www.ssllabs.com/ssltest/analyze.html gave the website an A+ rating, so i think i can consider this solved.

Thanks for updating your comment. So do you think your issue was a key and cert that didn't match?

Whatever you do, don't paste your key into that website (or anywhere, actually - it's private for a reason!).

Sam

Hey Sam!

Yes, I think my problem was the fact that the crt file is not contained in the ca-bundle, resulting to a key - certificate mismatch.

Although they give you the option to paste your private key for checking I did not use that.
I used my csr instead.

Do you think that this is something to be avoided as well?

Chris,

That's good. The CSR only contains your public key, so that's absolutely fine to share.

Sam

Hi Sam,

I have been following the Q/A sessions concerning SSL. You mention that you use Positive SSL which will support site.com and www.site.com. Now I use squirrelmail with a Virtual host as mail.xxx.co.uk and currently use a wildcard cert from CaCert as *.xxx.co.uk.

It is not clear how a Positive SSL can cover my web-site at www.xxx.co.uk as well as mail.xxx.co.uk. A Positive SSL Wildcard is significantly more expensive. I think I am missing something since squirrelMail uses the same Apache infrastructure as the web page.

How does a Positive SSL cert cover a sub-domain?

Thanks ... John

Hi John,

Unfortunately you have to buy a separate cert for the subdomain, or change your DNS settings so that you only use www.yourdomain.com and yourdomain.com (e.g. website at www.yourdomain.com and email server at yourdomain.com if they are separate servers).

Sam

Hi Sam,

Thanks for the reply. I should have mentioned that the web-site and the mail server are on the same Raspberry Pi. So they are not separate servers. Will that make a difference? You have my email address so you can look at DNS and MX records if that would help.

If I have to buy two Positive SSL certificates, I suppose I would have to make separate certs directories: one for postfix/dovecot and a second for Apache/Squirrelmail? Is that correct?

Or continue to use CaCert certificates for the mail server; and Comodo for the Apache/Squirrelmail. Does that make sense?

John

Hi Sam,

Apologies if I am being slow. If I change the MX record as you suggest, presumably mail.xxx.co.uk will no longer be recognised?

John

What do you mean, is your email address foo@mail.yourdomain.com?

I was assuming you just created a mail. subdomain due to convention and pointed to that in the MX record for yourdomain.con (i.e. your email address is foo@yourdomain.com)

Sam

Hi Sam,

My mistake: I should have been clearer:

There are DNS A records for: xxx.co.uk and mail.xxx.co.uk and www.xxx.co.uk which all point to my static IP address
There is an MX record for xxx.co.uk

My formal mail address is foo@xxx.co.uk

But: for web-mail (via squirrel mail), the web-mail address is: https://mail.xxx.co.uk and in the Virtual Host for .443 there is this:

<VirtualHost *:443>
DocumentRoot /usr/share/squirrelmail
ServerName mail.xxx.co.uk

So, while there is a sub-domain, (mail.xxx.co.uk) it is only there for web-mail access.

The question then is: will a single Positive SSL certificate be sufficient for this infrastructure?

Thanks (again)

John

Hi Sam,

Before going to Comodo I tried this experiment.

1. I am currently using a *xxx.co.uk wildcard from CaCert.
2. I requested a new certificate for xxx.co.uk - ie. not a wildcard
3. I installed key and cert into /etc/ssl/private and /etc/ssl/certs respectively (obviously with different names from the wildcard key/crt)
4. Changed all .key/.crt references in postfix/dovecot/apache2 to the new names and
5. Restarted postfix/dovecot/apache2

As expected, normal mail service resumes and web-site comes alive - although Firefox objects to a non-trusted certificate. Easily fixed

But also https://mail.xxx.co.uk works with new certificates - after another Firefox fix.

So I can see what is needed - and I can get a second cert for mail.xxx.co.uk if it is needed. At least I know now that a Comodo wild SSL is not required.

As usual, thanks for help.

John

Hi Sam,

End of story...I visited namecheap; requested PositiveSSL; installation was simple; postfix/dovecot/apache2 updated. I can see now that a second SSL for squirrelmail would complete the job.

It was useful using CaCert as a dry run before making a commitment to Comodo.

Thanks again...John

Pages

Add new comment