Okay, I noticed that this post is viewed quite often recently and so it seems that a lot of people are facing the same issue that I did. If so then this might help you.
I have followed a simple step-by-step tutorial to create a SSL-certification for my webserver. Like so many tutorials out there the outcome of the tutorial I followed was a self-signed certificate using OpenSSL. Yep self-signed, that was the problem. The browser could not trust the server due to it's certificate which is signed by itself. Well I wouldn't do either...
A certificate has to be signed by an external trustworthy certificate authority (CA). So I stumbled upon Let's Encrypt which does all the work for you and is even easier to set up and the best is: it is absolutely free.
Installation
1) Delete your old ssl cert files which you have created by using OpenSSL
2) Open backports to get certbot client on Debian. You should know that this will open a hole for unfinished software! Install only the packages when you are aware about what you are doing.
echo 'deb http://ftp.debian.org/debian jessie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list
3) Update your linux system
sudo apt-get update
4) Install certbot
sudo apt-get install python-certbot-apache -t jessie-backports
5) Set up apache ServerName and ServerAlias
sudo nano /etc/apache2/sites-available/000-default.conf
6) Edit apache config file
<VirtualHost *:80>
. . .
ServerName example.com
ServerAlias www.example.com
. . .
</VirtualHost>
7) Check for a correct syntax
sudo apache2ctl configtest
8) If the config file looks fine, restart apache server
sudo systemctl restart apache2
9) Set up a certificate using certbot and follow the instruction on screen.
sudo certbot --apache
Renewal
All certificates by Let's Encrypt are valid through 3 months. To renew the you can manually run
sudo certbot renew
Or automate this service as a cron job
sudo crontab -e
and enter the following row to invoke a renewal every Monday at 2:30 am.
. . .
30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log
You can follow a more detailled tutorial here: https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-debian-8
Best Answer
Yes what you've described is technically correct but there's a little bit more going on. The browser is determining that the host's CN is correct based on a few indicators.
The primary indication is that the host serving the HTTPS traffic's SSL certificate is being served from the correct domain, and that the signing chain of the certificate is also correct based on the CA (Certificate Authority) that issued & chain signed the certificate.
You can use
openssl
'ss_client
to get a sense of the back and forth that your browser would also be performing.Example
If you use this command you'll notice the CN that was used when generating the SSL certs:
So the browser will confirm that the hostname that's serving this cert falls within the hierarchy of the
CN=...
that's included in the cert.SNI
It used to be the case that you had to have a specific IP address set aside for each SSL server's hostname that you wanted to make use of over HTTPS. However this is no longer the case thanks to SNI (Server Name Indication).
excerpt
Again using
openssl
you can simulate what your browser would be doing in this scenario:excerpt
References