Despite that selfmade certificates usually provide more information and a higher key size as well (well… mine do), don’t use them for the public. It’s sad, but true, that the vast majority of the users out there has no idea how certificates work – they WILL complain on first warning. And stick there, wether you try to explain or not.
Obviously, this leaves you with high security for your backend (at least you should trust yourself), but if you’ll up to provide your visitors with encryption, you have to spend money for „a third party checking“ (which, to be honest, is a joke, but well…)
Given the pricings and „for private“ – don’t even think about E(xtended)V(alidation)-Certificates. Even if you can get one, it’ll be really expensive.
So… how to „certificate“?
First of all, bookmark this URL: https://www.ssllabs.com/ssltest/. The tests done there will show you where you can improve… but now, the basics…
First of all you have to choose a certificate provider. I, for instance, stay with AlphaSSL – the pricing get’s me. But the it should be the same procedure for whatever CA you choose.
Getting your certificate
generate your servers key
$ openssl genrsa â€“out server.key 2048
Please note, the key will not be protected. This is for convenience, if you i.e. plan to automatically restart the server after a crash, power outage or the like. If you feel better, add the parameter
after genrsa. However, every time apache is to be restarted, you have to enter the password to do so…
Generate the CSR
Now that you’ve got your 2048 bit server key, the next step is to generate a certificate signing request, CSR, like follows:
openssl req â€“new â€“key server.key â€“out server.csr
Make sure(!) that the common name is exactly your fqdn (like www.server.com) – otherwise the certificate will not work with your domain name. In doubt, search the documentation of your CA for naming options or wildcard-certificates. Usually, these will cost more.
The resulting file „server.csr“ is what you have to send to your certificate provider – or, in case of AlphaSSL, paste the content into the formular at the website.
Depending on how your CA does the – very basic – validation, you’ll eventually end up with your new certificate (i’ll call it server.crt). Yay! 😉
Receive your certificate
Given that you have now your servers key (starting with —–BEGIN RSA PRIVATE KEY—–) and the certificate (starting —–BEGIN CERTIFICATE—–), you may copy them together, creating i.e. a server.pem, which now contains key and certificate. Feel free to leave them seperate if you wish. Could slightly raise security, if you care about file system permissions. But that’s for another day…
$ cat server.key > server.pem $ cat server.crt >> server.pem
Getting this certificate to work
Put it in the config!
I’ll describe this for a virtualhost, but it should be the same for single configurations. I’ll start right in the file…
<VirtualHost your.ip.comes.here:443> SSLEngine on SSLCertificateFile /path/to/your/server.pem
If you have left your keyfile seperate, you’ll have to add
At this point, usually any desktop client should work fine with your website (given you reloaded the apache config). However, there are a few traps hidden here…
First of all, if you check your site now, it will get a rating of „F“, for you are supporting even the oldest and the unsecurest encryptions you can buy 😉
And for second, if you try to get your site via https on an android device – i.e., with chrome – you’ll get an error. Or better, a certificate warning.
Now what? You bought a certificate and now it’s not working on mobile devices?
Well, Android i.e. takes some things more serious as the most desktop environments do, and so you (usually) have to
Fix the certificate chain
If you do the test at ssl labs you’ll eventually note, that there is one certificate missing. Most CAs use intermediate certificates for issuing the end user certificates, and you have to provide it to the client to complete the chain. This is done by adding
Your CA should have this certificates for you to download somewhere on their site.
Reload the config once again, et voilÃ¡ – site works on mobile devices. Which leaves us now to
Hands up, who wants his site visited with an REALLY outdated browser? Well, such users should have a lot of other problems by now than being concerned about the encryption of your website traffic.
So, what we’ll do is
a) kick out the unsecure ciphers and protocols, and
b) sort them so that the strongest come first.
Put the following in your apaches configuration, right after the stuff from above
SSLProtocol -ALL +SSLv3 +TLSv1 SSLHonorCipherOrder on SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
(i got this myself from Hynek Schlawack‘ Website – you may visit this site also, there’s a lot more of explanation. 😉
As one side effect, usually browsers should satify one of the first ciphers, which means, forward secrecy for everyone! Well, at least for those using actual browsers.
Again, relod the configs! Test your site again, and find an solid grade „A“ ranking.
Now you should decide if you stick with serving https. If so, add
Header add Strict-Transport-Security: "max-age=15768000"
to the config for the https virtualhost. For way more information about HSTS, begin at Wikipedia. In short, this instructs a capable browser (which is, all modern browsers) to ONLY get your site encrypted, once he knows about.
So that’s it – no magic behind securing websites, just getting the stuff done 🙂
Hopefully, this text may have helped.