Apache server – basics 03

Theory of how certificates work

We will see how all this works, I will try to go in detail but quietly! I think it’s important to understand that. Understanding the operation of certificates helps to better diagnose problems as an administrator but also as a user.

These certificates allow you to perform cryptographic operations, such as encryption and digital signing that offer the following guarantees for electronic transactions:

 

  • Confidentiality: it guarantees that only the legitimate recipient (or owner) of a data block or message can have an intelligible view of it;

  • authentication: it guarantees to any recipient of a data block or message or to any system to which a user is trying to connect the identity of the sender or user in question;

  • integrity: it ensures that a block of data or message has not been tampered with, accidentally or intentionally;

  • non-repudiation: it guarantees to anyone that the author of a block of data or a message can not deny his work, that is to say, pretending not to be the author.

What is a Certificate?

When setting up an https website, we declare a key pair, the certificate and the private key, this follows the principle of asymmetric cryptography. Asymmetric cryptography is used in many cases (ssh key, …), the HTTPS system is based on this principle, we will see the details.

The principle of the asymmetric encryption system is based on a key pair:

 

  • A public key that is distributed to all

  • A private key, all the security lies in this key it is essential to keep it in a safe place. Not readable by all

WARNING: when generating keys their association is unique, in other words if you lose one of the two keys it is impossible to regenerate one of them!

The key pairing system (asymmetric cryptography) contrasts with the one-key encryption system (skew cryptography) where all users know the key. Here is a representation of the encryption mechanisms:

 

 

  • Symmetric encryption:

s we can see, Anne and Bob (aka Robert) both have encryption keys so they can encrypt and decrypt messages.

 

  • Asymmetric Encryption:

In the image above we find that Anne is the only one to have the key Private, the other intervener have in their possession only the public key of Anne. Two operations are performed in the diagram the first the message signature, Anne sends a signed message with that private key, thanks to the public key Bob and Dylan can guarantee that the message comes from Anne. The decryption of the signature is only possible with the pair associated with the public key, therefore the private key of which Anne is the sole owner. The other operation is the information encryption that Bob sends to Anne, the latter encrypts the information with Anne’s public key. The only result is that Anne’s private key is able to decrypt the content.

 

ATTENTION: take note that when encrypting a message with the private key everyone can decrypt with the public key distributed on the net! So if Anne wants to send an encrypted message to Bob, she must have the public key of Bob.

If we come back to our subject, the certificate system for the website, we find this key pair:

  • Public Key == Certificate

  • Private key == Private key installed on the server

The key is only part of the Certificate, the latter is composed of several parts, there are several types of certificates for different purposes (Certificate of email, machine authentication, …). As part of the configuration of a web server we use X.509 certificates.

Here is the content of the structure of a certificate:

  • Version

  • Serial number

  • Certificate signing algorithm

  • DN (Distinguished Name) of the issuer (certification authority)

  • Validity (deadlines)

  • Not before

  • Not after

  • DN of the subject of the certificate

  • Public key information:

  • Algorithm of the public key

  • Public key proper

  • Unique identifier of the signatory (optional, X.509v2)

  • Unique identifier of the certificate holder (optional, X.509v2)

  • Extensions (optional, from X.509v3)

  • List of extensions

  • Signature of the above information by the certifying authority

At this stage of the explanation I will not mention the CA (the certification authority) keep our environment autonomous, but no panic we will talk about it: D.

In order to have a bit of concrete I propose to make the creation of an autonomous certificate, so a certificate (public key) and a private key.

$ openssl req -x509 -newkey rsa:2048 -nodes -keyout server.key -out server.crt -days 365 Generating a 2048 bit RSA private key ................+++ ....................................................................................+++ writing new private key to 'server.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:CA State or Province Name (full name) [Some-State]:Quebec Locality Name (eg, city) []:Montreal Organization Name (eg, company) [Internet Widgits Pty Ltd]:bob Organizational Unit Name (eg, section) []:Formation Common Name (e.g. server FQDN or YOUR name) []:www.bob.com Email Address []: $ ls server.crt server.key $ head -5 server.key server.crt ==> server.key <== -----BEGIN PRIVATE KEY----- MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDJsYXLGDBE8Zlh 4++b6bI0zDxonvPvuS/BI9M1wF7G2JPAhXHmBT7TpVfp3ekR7SuFIJVKEOn7xQiV 4kJwtnLexZDx3MaEJnBVsOcmz8dvyJ2eYif3p2WkGxbcyRRAV+KTXHSZgHdY6LfB H08nBasY5nqJ5v27W2O/gC1RavsjAuHIPW7khcP2ksJEdbTsW1ihxp03NkA8xRX/ ==> server.crt <== -----BEGIN CERTIFICATE----- MIIDrTCCApWgAwIBAgIJAIM6pAb71wACMA0GCSqGSIb3DQEBCwUAMG0xCzAJBgNV BAYTAkNBMQ8wDQYDVQQIDAZRdWViZWMxETAPBgNVBAcMCE1vbnRyZWFsMQ4wDAYD VQQKDAVYM3J1czESMBAGA1UECwwJRm9ybWF0aW9uMRYwFAYDVQQDDA13d3cueDNy dXMuY29tMB4XDTE2MDQwNTEyNDgyM1oXDTE3MDQwNTEyNDgyM1owbTELMAkGA1UE

So a little explanation to understand we used the command openssl to make the generation of a new certificate / private key type rsa with a size of 2048 bits the file of the private key is stored in the server.key file while the certificate is contained in the server.crt file. As mentioned in the certificate structure it must have a validity date, here I indicate a validity of 365 days from today -days 365.

When we view the server.crt file it is not very readable, we can use the openssl command too to display the contents of the certificate:

$ openssl x509 -in server.crt -text Certificate: Data: Version: 3 (0x2) Serial Number: 83:3a:a4:06:fb:d7:00:02 Signature Algorithm: sha256WithRSAEncryption Issuer: C=CA, ST=Quebec, L=Montreal, O=bob, OU=Formation, CN=www.bob.com Validity Not Before: Apr 5 12:48:23 2016 GMT Not After : Apr 5 12:48:23 2017 GMT Subject: C=CA, ST=Quebec, L=Montreal, O=bob, OU=Formation, CN=www.bob.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c9:b1:85:cb:18:30:44:f1:99:61:e3:ef:9b:e9: b2:34:cc:3c:68:9e:f3:ef:b9:2f:c1:23:d3:35:c0: 5e:c6:d8:93:c0:85:71:e6:05:3e:d3:a5:57:e9:dd: e9:11:ed:2b:85:20:95:4a:10:e9:fb:c5:08:95:e2: 42:70:b6:72:de:c5:90:f1:dc:c6:84:26:70:55:b0: [ ... OUTPUT COUPÉ ... ] X509v3 extensions: X509v3 Subject Key Identifier: 0A:F2:CE:D0:5B:C1:84:F1:8F:AC:3B:73:FC:37:56:54:31:1F:C5:8F X509v3 Authority Key Identifier: keyid:0A:F2:CE:D0:5B:C1:84:F1:8F:AC:3B:73:FC:37:56:54:31:1F:C5:8F X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha256WithRSAEncryption c5:08:1c:e0:d5:99:a4:44:e2:f0:41:ab:40:38:6b:fa:b9:00: f9:6f:74:be:14:bc:4f:7f:c9:27:88:76:31:00:28:57:be:17: [ ... OUTPUT COUPÉ ... ]

As you can see from reading above we have the information on the website, domain name, organization, … This is the Subject line, plus we have the validity period of the certificate available Validity: .

A certificate is only valid for a Fully Qualified domain name (FQDN) in other words than for a fully qualified domain name. The certificate here is valid for the www.bob.com domain but is not valid for the domain. domain bob.com. It is possible to buy a wildcard certificate that covers all the subdomains of a domain (* .bob.com) however the price is significantly higher.

If we set up this certificate, your browser will give you an error when accessing the website mentioning that it is self signed. Which means that the communications will be encrypted, because there is a public key (certificate) and a private key that is available however the authenticity of the website can not be validated.

The httpS system also offers a guarantee of authenticity of the website with which we communicate. To enable this validation we need a third party who will perform this validation, this is when the Certificate Authority (CA) arrives. It is for this service that you need to buy a certificate from a supplier, it is only for your site to be certified as being the one for which it is presented.

You wonder then, but then that is the difference between the self signed certificate and the one provided by a CA. There is only a slight difference, the public key system and private key does not change, because the service provider must NEVER have your private key, it will only affix that signature on your certificate. Here is a representation of the certificate:

 
The first part is the certificate request that is forwarded to the Certificate Authority (CA), this includes the public key in relation to the private key as well as information about the organization. This is not a complete certificate because it does not contain an expiry date or issuer. When transmitting the certificate request the latter add the missing parts, and sign it all to authenticate it.

 

To create the query you can use the command:

 

$ openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr Generating a 2048 bit RSA private key .......................+++ ......................................................+++ writing new private key to 'server.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:CA State or Province Name (full name) [Some-State]:Quebec Locality Name (eg, city) []:Montreal Organization Name (eg, company) [Internet Widgits Pty Ltd]:bob Organizational Unit Name (eg, section) []:formation Common Name (e.g. server FQDN or YOUR name) []:www.bob.com Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

As you can see when we created a self signed certificate and for the query we provided the same information. Once the query typically creates the CA for a form to transmit the query then you receive the full certificate. The certificate request that does not contain a date can be reused at each renewal, HOWEVER it is important to understand that the certificate request is also the public key so you must keep the same private key.

  • Reference:

    • https://fr.wikipedia.org/wiki/Certificat_%C3%A9lectronique

    • https://fr.wikipedia.org/wiki/Infrastructure%C3%A0cl%C3%A9s_publiques

Detail of the httpS communication

Now that we have a better understanding of the certificate we will see the communication process when the browser establishes the connection. This will also allow us to understand how the certificate is validated with the CA.

A picture is worth a thousand words, so here are 2 graphics representing the communication of the SSL communication process.

 
 
If we take the first picture.

 

  1. TCP / IP: The arrows in blue represent the TCP / IP connection the handshake (3 hand shake) this represented by the packets (SYN, SYN / ACK, ACK).

Protocols negotiation process supported

  1. Client hello: The client transmits to the server the SSL / TLS protocols that it supports and wants to use for the communication, moreover it provides a list of cipher suites (cipher suites) for the symmetric key that will be used thereafter we will come back . There is also a session ID, this is a random number that will be used for key generation. There may be other information transmitted.

  2. Server hello: The server receives the response from the client and analyzes if there is a match between the SSL / TLS protocols supported by the client and those that it supports and chooses one. It performs the same operation for cipher suites. When responding, the server transmits its SSL certificates. There is also a session ID, this is a random number that will be used for key generation. There may be other information transmitted.

Certificate validation process

Upon receipt of the certificate, the client validates the certificate:

  1. Validation of the validity date, is the certificate still valid? This is done retrieving the information: Validity Not Before and Validity Not After

  2. Subsequently, the system validates that the certificate was issued for the indicated website, that the URL matches the CN entry of the certificate (Subject: C = CA, ST = Quebec, L = Montreal, O = bob, OR = Training, CN = www.bob.com)

  3. The client validates that the certificate was signed / validated by a certificate authority (verysign, godaddy, digicert, …) To do this it uses the certificates (public key) present on the system or in the browser to decipher the signature made by the private key of the certificate of authority (CA). When describing the certificate I mentioned the signing process with a certificate I invite you to reread this section. You can see in your browser the list of CA certificates available:

 

 

  1. Once the certificate has been confirmed as valid and issued by a certification provider, the system validates with that authority if the certificate present was not revoked. It communicates with the Certification Revocation List CRL, the latter is available as information in the CA certificate

 
There is also another OCSP protocol that allows you to have the certificates revoked. The purpose of this mechanism is that if for some reason X your system is compromised and someone steals the private key, you are able to invalidate the certificate so that nobody can use it. This operation must be performed near your Certificate Authority.

 

Exchange of a symmetric key

As mentioned earlier the asymmetric key system only allows encryption with the key pair system, we have the SSL certificate of the server (public key) so the client can encrypt the data which will only be decrypted by the server . The “problem” is that by default the client does NOT have a certificate (it is possible also some organization uses certificates to identify the clients, however I keep the classic case such as communications with a public banking institute). Moreover, if the customer has a certificate to ensure the identity of the latter we would be obliged to renew regularly to a CA. Another negative aspect of using an asymmetric key encryption system such as SSL certificates is the CPU / memory cost required to encrypt and decrypt communications. This system is much more resource hungry.

So to work around the problem of no client certificate and to improve SSL communication performance a symmetric key exchange is performed between the client and the server. The client generates a random number called PRE-master key secret which is transmitted to the server. To ensure the confidentiality of this key, it is encrypted with the certificate (public key) of the server, this ensures that only the server will be able to read it.

This is called pre-master key because the client AND the server performs an algorithmic calculation to generate the final encryption key. This compute generates the symmetric encryption key that will be used during communications between the client and the server. The final key is NEVER transmitted over the network.

The client and the server transmits a message of end of the negotiation, thus validating the encryption, thereafter all the communications are encrypted with the symmetric key.

 

Detailed graphic representation of the SSL protocol

A more detailed representation of SSL with all keys and random number generated.

Simple configuration of a website with mod_ssl

We will precede the setting up of a very simplistic configuration, this will allow us with the set of options to cover the theory around.

To start we will activate the ssl module in apache:

 

$ cd /etc/apache2/mods-enabled $ sudo ln -s ../mods-available/ssl.load . $ sudo ln -s ../mods-available/socache_shmcb.load . $ sudo ln -s ../mods-available/ssl.conf . $ cat ssl.load # Depends: setenvif mime socache_shmcb LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so

The ssl.conf file contains default configurations, I leave you the pleasure of watching the content, we will see some instructions later.

We will take the time to carry out the validation of the configuration following the addition of the modules:

 

$ sudo apachectl configtest Syntax OK

If you have the following error:

AH00526: Syntax error on line 43 of /etc/apache2/mods-enabled/ssl.conf: SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).

This indicates that you did not create the symbolic links for socache_shmcb.load this module is required by mod_ssl if you read the ssl.load file it is clearly indicated: P.

We will now create the website for www.linux202-siteA.com aka siteA. But before I would like to take a second to see the ports.conf file

 

$ cat /etc/apache2/ports.conf Listen 80 Listen 443 Listen 443

As you may know and otherwise I’ll tell you, http communications are done on port 80 while encrypted communications are done on port 443. If you look at the ports.conf file we can see that the port 443 will be open if the module ssl_module is loaded otherwise it does not open the port.

This being clarified, no mystery we can proceed to the establishment of the configuration for siteA in ssl.

 

$ sudo vim /etc/apache2/sites-available/siteA-ssl.conf $ cat /etc/apache2/sites-available/siteA-ssl.conf ServerAdmin webmaster@localhost ServerName www.linux202-siteA.com ServerAlias linux202-siteA.com ServerAlias toto.linux202-siteA.com DocumentRoot /data/vhosts/siteA/docroot/ Alias "/cm-images" "/data/vhosts/common/images" Options none AllowOverride ALL Require all granted Options none AllowOverride None Require all granted # Configuration des logs ErrorLog /data/vhosts/siteA/logs/ssl_error.log CustomLog /data/vhosts/siteA/logs/ssl_access.log combined ## SSL section SSLEngine on SSLCertificateFile "/etc/apache2/ssl/www_linux202-siteA_com.crt" SSLCertificateKeyFile "/etc/apache2/ssl/www_linux202-siteA_com.key"

Generation of the self-signed SSL certificate, I have no money to buy a certificate for the training ;-), but even though the certificate is NOT valid the SSL protocol is all the same. The client will use the certificate to transmit the encrypted data to the server for the negotiation of the symmetric key.

$ cd ~ $ mkdir ssl && cd ssl $ openssl req -x509 -newkey rsa:2048 -nodes -keyout www_linux202-siteA_com.key -out www_linux202-siteA_com.crt -days 365 Generating a 2048 bit RSA private key ..............................................................................................................+++ .................+++ writing new private key to 'www_linux202-siteA_com.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:CA State or Province Name (full name) [Some-State]:Quebec Locality Name (eg, city) []:Montreal Organization Name (eg, company) [Internet Widgits Pty Ltd]:bob Organizational Unit Name (eg, section) []:training Common Name (e.g. server FQDN or YOUR name) []: www.linux202-sitea.com Email Address []: $ sudo mkdir /etc/apache2/ssl $ sudo cp * /etc/apache2/ssl

As mentioned earlier your private encryption key AND very very important because all the security resides on this file. It is very important to make sure to secure it.

$ ls -l /etc/apache2/ssl total 8 -rw-r--r-- 1 root root 1334 Apr 20 08:36 www_linux202-siteA_com.crt -rw-r--r-- 1 root root 1704 Apr 20 08:36 www_linux202-siteA_com.key $ sudo chmod o-r /etc/apache2/ssl/www_linux202-siteA_com.key

Activation of the virtual server, validation of the configuration and restart of the service.

$ cd /etc/apache/sites-enabled $ sudo ln -s ../sites-available/siteA-ssl.conf $ sudo apachectl configtest && sudo /etc/init.d/apache2 restart Syntax OK * Restarting web server apache2 ...done.

We can now access the SSL website with our browser: https://www.linux202-sitea.com

 
Of course, since we do not have a certificate signed by a certificate authority, we have this message. ATTENTION It is important to take into consideration the message and not to accept the certificate without revalidating the URL. This message should never appear if you communicate with an “official” site.

Once the certificate is accepted, the site is presented to us:

 

 

Link: * https://en.wikipedia.org/wiki/ElectronicCertificate * https://en.wikipedia.org/wiki/Publickey_infrastructure + EN

  • Reference : https://httpd.apache.org/docs/2.4/fr/ssl/ssl_howto.html