Apache and HTTPS

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

Ad 1,

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…

Ad 2,

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! 😉

Ad 3,

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

SSLCertificateKeyFile /path/to/your/server.key

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

SSLCaCertificateFile /path/to/intermediate/certificate.pem

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

Fixing security

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

(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.

Über Alariel

Seit diversen Jahren Systemadministrator im Bereich Linux, noch länger passionierter Rollenspieler, Reenactor und überzeugter "Heide". Nebenbei noch Tätig im Bereich der Webseitengestaltung, ob nun einzelne Seiten oder auch mehr.
Dieser Beitrag wurde unter Admin-Stuff veröffentlicht. Setze ein Lesezeichen auf den Permalink.

1 Response to Apache and HTTPS

  1. Pingback: HTTPS and Websites | Alariels unmaßgebliche Meinungen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.