Domains - DNS - Apache - Certificate SSL

There seems to be quite some mysteries about SSL Certificates, for instance people asking from their software vendor for a SSL certificate, others who are using the SSL certificate provided with a software and ment for testing to go into production. Solely based upon the idea that "if they use SSL, they're very secure". Yet, that is not exactly how it works.
If one considers that when using a SSL certificate provided with a software is secure, then think for instance also about the fact that the identity is wrong and more important, everyone else using the same software also has the private key that goes with it..
A private key is at all times to be kept secret and if half the world has the private key, it isn't that secret anymore.

SSL (Secure Sockets Layer) is based upon 3 axis;

  • Authenticity
  • Integrity
  • Confidentiality

Authenticity :

Most used in server-only-authentification, a statement of truthfulness that the server is indeed the identity it claims to be. The identity may be verified against the Authority that issued the certificate. If an exchanging partner trusts the Authority that issued the certificate, or even an intermediate Root certificate, the partner will recognise the identity. The authenticity of an SSL Certificate is often compared to a person who carries a passport which has been issued by a gouvernemental body and which is used within the validity dates the document is valid for. If a server wants to obtain the identity of the connecting client, it may challenge the client with a certificate_request during the initial handshake for its certificate in which case we're talking about mutual-authentification.

Integrity :

The integrity is a means of making sure that no data could have been altered while being exchanged between two parties (usually between a client and a server) without it going unnoticed. Often obtained with hashing methods.

Confidentiality :

This is the part that keeps most people busy; it prevents others from seeing what exactly is being exchanged. This can be obtained by encryption methods using the key-pair or a one-time session key (= a secret) generated between the client and server. This is why it is very important that the private key of a SSL certificate remains secret and well stored at all times. You never give your private key to anyone. The public key however can be provided along with the certificate during the initial handshake to anyone that wants it.

SSL can only be considered to be secure when all three assets are used together. Though the implementation may allow you to only use the certificate exchange part (Authentification) without any encryption, ciphering nor hashing, it is obvious that it will not be secure though one can say to "use SSL".

How to obtain a certificate and from who ?

It completely depends; to use SSL, one can perfectly create his own certificates with for instance openssl. Such certificates will be refered to as self signed certificates, as there is no Authority that has signed them. If you only worry about your data being encrypted, your own certificates are as good as any other. An Authority is nothing more nor nothing less than an organisation which two exchanging partners both trust. Though not likely to happen, but lets imagine for instance that one day people start to "trust" Alterlinks, Alterlinks could become an Authority. It is all a matter of who you trust. More commenly, known Authorities are for instance VeriSign and Thawte.

Though it sounds obvious, as indicated above, a certificate doesn't have to be obtained from anyone. As it is very important that the private key remains secret and safe, best thing to do is create your own certificate which will then be a CSR (Certificate Sign Request) with the options you need.

Create your own SSL certificate with openssl :

openssl req -new -nodes -keyout -out -newkey rsa:2048

The above example will create a RSA 2048 bits key-pair and when answerring the questions that will appear on the screen, the Certificate will be created. The CN, or Common Name, you usually want it to be the FQDN (full name) of the server/website that is going to use the SSL certificate, for instance If we were to use the resulting certificate "as is" on the Internet, alarm bells will start ringing and red lights flashing, as it is an unsigned certificate. Never the less, if the exchanging party would choose to ignore the warnings and accepts it, the certificate and key-pair will work just fine. After all, the Integrity and Confidentiality part will still work, but the Authentication part will fail of course.
If you don't want red flashing lights and Warning messages popping up everywhere stating that the identity can not be trusted (or rather, can't be validated), you may want to have it signed by an Authority.
For instance, GoDaddy as an Authority can accept your CSR. When a signing request is made, the Authority will first launch a thourough investigation. Based upon the information presented on the certificate of the CSR, an Authority is first going to validate that you are authorized to make such request, that you (or your company) exist, you are the owner of the domain name and perhaps some other verifications. Also note that it is very important that your DNS zone is set up correctly in regards to the MX entry; an email may be sent to the destination postmaster of the domain, which is a mandatory email account on the SMTP server that is indicated in the MX record. Or an email may be sent to the domain owner. Such email needs to be answerred with an approval notification by the requester of the certificate sign request. If you and your request check out fine and all seems in order, the Authority will sign your CSR and return it back to you, usually by offering a download link. You now have a valid, signed certificate for the validity period requested and when presented to an exchanging partner, if they also trust the Authority that signed your certificate, there will be no red flashing lights and alarm bells.

If you've choosen for instance GoDaddy as Authority, then choose "download for Apache" when you pick up the certificate which should give you something like this :

[root@shop]# cat

Note : during the CSR, your private key never moved! It remained safe on your machine at all times.

Then all what is left to do is to import the certificate into the software that is going to use it, for instance into an Apache webserver, along with the Root certificate(s). You can obtain the Root (and/or intermediare) certificates from the Authority that signed your certificate.

When a webbrowser connects using SSL (https://) to this webserver, the connection will be secured. If the client wants to, they can display the certificate the server presented :

signed SSL Certificate

At the same time, if such certificate is desired for HTTPS SSL Authentification over the Internet, its extended key usage (which can also have other purposes) should have "server authentification" and/or "client authentification" :

certificate extended key usage