TLS
Transport Layer Security (TLS), and its now-deprecated predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP). Websites can use TLS to secure all communications between their servers and web browsers.
The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications.
Why TLS?
When data is send with the HTTP-protocol it is in clear text. Anyone can see it. Don't trust your ISP or any middleman in the line.
The website your are visiting can be run with HTTP but you cannot be shure the data is from my server. The content is public, so that no problem.
We need TLS when we allow web visitors to upload to the server by login, formmail or registering as a member or submitting comments to a blog.
Also search-engines give sites that use HTTPS higher rankings.
Which site use TLS
When we look at the URL we see a padlock symbol when there is TLS/SSL encrytion active. The pictures show the URL on Firefox. Other browsers show it different.
When the name of the firm is shown, the certificate is verified for ownership of the site. Higher level of trust.
  | This website don't use TLS/SSL encryption. Only allowed for sites without formmail, comments, login etc. |
 | This website use TLS/SSL encryption. Good for all sites excecpt commercial sites like e-commerce and banks. |
 | This website use TLS/SSL encryption and is who its claims to be. The best option for commercial use. |
The shield-symbol has nothing to do with TLS/SSL. Its part of Adblock plus.
Type of certificates
There a several type of certifcates that you can use.
- www only: www.example.com and example.com
- wildcard: *.example.com, every service can be encryted with it like FTP, SMTP or multiple sub-domains.
- commercial: Ownership will also be validated by owner of site.
Creating a certificate pair
# openssl req -new -newkey rsa:2048 -nodes -out example.com.csr -keyout example.com.key -sha256 Generating a 2048 bit RSA private key ............................................................+++ ............+++ writing new private key to 'example.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) [XX]:NL State or Province Name (full name) []:. Locality Name (eg, city) [Default City]:. Organization Name (eg, company) [Default Company Ltd]:. Organizational Unit Name (eg, section) []:. Common Name (eg, your name or your server's hostname) []:*.example.com pa3cjd@amsat.org []:webmaster@example.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: # ll totaal 8 -rw-r--r--. 1 root root 1037 okt 7 20:10 example.com.csr -rw-r--r--. 1 root root 1704 okt 7 20:10 example.com.key
A Certificate Signing Request is a block of encoded text that contains information about the company that an SSL certificate will be issued to and the SSL public key. Once a CSR is created it is difficult to verify what information is contained in it because it is encoded. Since certificate authorities use the information in CSRs to create the certificate, you need to decode CSRs to make sure the information is accurate. To check CSRs and view the information inside of them, enter:
# openssl req -in example.com.csr -noout -text
Check if everyting is correct. If not delete the set and create a new one.
Send example.com.csr to your CA for signing. Keep your .key file save.
When the .csr file is signed you receive a .crt file and the intermediate and root CA files.
To check the crt file enter:
# openssl x509 -in example.com.crt -text -noout
Your sertifcate is only a year valid, so you must replace it every year. Including the chains.
Installing the certifcate files
# chmod 0640 example.com.key # chcon system_u:object_r:cert_t:s0 *.key # cp example.com.key /etc/pki/tls/private # cp example.com.crt /etc/pki/tls/certs
If the intermediateCA and rootCA are separete, make a bundled one. Check with vi if the cursor start on a new line at the end in all .crt files. If not add one <CR> to do so. If you see ˆM at the end of each line remove them. Copy both to /etc/pki/tls/certs
# cd /etc/pki/tls/certs # chcon system_u:object_r:cert_t:s0 *.crt # cp intermediateCA.crt example.com_ca-bundle.pem # cat rootCA.crt >> example.com_ca-bundle.pem
If there is a bundled one rename it to example.com_ca-bundle.pem.
Create a fullchain file by:
# cp example.com.crt example.com_fc.pem # cat example.com_ca-bundle.pem >> example.com_fc.pem # chcon system_u:object_r:cert_t:s0 *.pem
Using TLS/SSL
After installing the certificates you can use secure connections. You have to add ssl support in the config files. See deamon installations (ftp, smtp, pop3/imap, sql and http) for how to. First check that de deamon works in insecure mode and than add tls/ssl.
Use only TLSv1.2 and higher. SSLv2 and SSLv3 are not secure and deprecated, TLSv1.0 and TLSv1.1 are to be deprecated in 2020.
Self signing the csr
A self-signed certificate is a certificate that is signed by the person creating it rather than a trusted certificate authority. Self-signed certificates can enable the same level of encryption as a $1500 certificate signed by a trusted authority, but there are two major drawbacks: a visitor's connection could be hijacked allowing an attacker view all the data sent (thus defeating the purpose of encrypting the connection) and the certificate cannot be revoked like a trusted certificate can.
Self-signed certificates or certificates issued by a private CAs are not appropriate for use with the general public.
However, self-signed certificates can have their place:
- An Intranet. When clients only have to go through a local Intranet to get to the server, there is virtually no chance of a man-in-the-middle attack.
- A development server. There is no need to spend extra cash buying a trusted certificate when you are just developing or testing an application.
- Personal sites with few visitors. If you have a small personal site that transfers non-critical information, there is very little incentive for someone to attack the connections.
If you are going to use a self-signed certificate for one of the situations where they are appropriate, it is much better to create your own private CA certificate. This is a more secure option that allows you to avoid warnings like the one displayed above for doing just a little bit more work.
Be your own Certificate Authority (CA)
First of all we will create a directory tree where all certificate stuff will be kept. CentOS default directory is /etc/pki/tls/. So, as root, we create our own directories:
# mkdir -m 0755 /etc/pki/myCA /etc/pki/myCA/private /etc/pki/myCA/certs /etc/pki/myCA/newcerts /etc/pki/myCA/crl
myCA is our Certificate Authority's directory.
myCA/certs directory is where our server certificates will be placed.
myCA/newcerts directory is where openssl puts the created certificates in PEM (unencrypted) format and in the form cert_serial_number.pem (eg 07.pem). Openssl needs this directory, so we create it.
myCA/crl is where our certificate revokation list is placed.
myCA/private is the directory where our private keys are placed. Be sure that you set restrictive permissions to all your private keys so that they can be read only by root, or the user with whose priviledges a server runs. If anyone steals your private keys, then things get really bad.
We are going to copy the default openssl configuration file (openssl.cnf) to our CA's directory. As root:
# cp /etc/pki/tls/openssl.cnf /etc/pki/myCA/openssl.my.cnf
This file does not need to be world readable, so we change its attributes:
# chmod 0600 /etc/pki/myCA/openssl.my.cnf
We also need to create two other files. This file serves as a database for openssl:
# touch /etc/pki/myCA/index.txt
The following file contains the next certificate's serial number. Since we have not created any certificates yet, we set it to "01":
# echo '01' > /etc/pki/myCA/serial
You should modify the following settings in order to comform to our custom directory and our custom CA key and certificate:
[ CA_default ] dir = . # <--CHANGE THIS certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt #unique_subject = no new_certs_dir = $dir/newcerts certificate = $dir/certs/myca.crt # <--CHANGE THIS serial = $dir/serial #crlnumber = $dir/crlnumber crl = $dir/crl.pem private_key = $dir/private/myca.key # <--CHANGE THIS RANDFILE = $dir/private/.rand x509_extensions = usr_cert
Create the CA certificate and key
Now, that all initial configuration is done, we may create a self-signed certificate, that will be used as our CA's certificate. In other words, we will use this to sign other certificate requests.
Change to our CA's directory. This is where we should issue all the openssl commands because here is our openssl's configuration file (openssl.my.cnf). As root:
# cd /etc/pki/myCA/
And then create your CA's Certificate and Private Key. As root:
[root@server1 myCA]# openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825 -sha256 [root@server1 myCA]# chmod 0400 /etc/pki/myCA/private/myca.key
This creates a self-signed certificate with the default CA extensions which is valid for 5 years. You will be prompted for a passphrase for your CA's private key. Be sure that you set a strong passphrase. Then you will need to provide some info about your CA. Fill in whatever you like.
Generate a Certificate Request
First, we change to our CA's directory:
# cd /etc/pki/myCA/
You can change server in example.com or so.
Then we create the certificate request:
[root@server1 myCA]# openssl req -config openssl.my.cnf -new -newkey rsa:2048 -nodes -keyout private/server.key -out server.csr -days 365 -sha256
The -nodes option is needed so that the private key is not protected with a passphrase. If you do not intend to use the certificate for server authentication, you should not include it in the above command.
You can customize the number of days you want this certificate to be valid for.
Sign the certificate request
Now we are going to sign the certificate request and generate the server's certificate.
First, we change to our CA's directory:
# cd /etc/pki/myCA/
Then we sign the certificate request:
[root@server1 myCA]# openssl ca -config openssl.my.cnf -policy policy_anything -out certs/server.crt -infiles server.csr
You will need to supply the CA's private key in order to sign the request. You can check the openssl.my.cnf file about what policy_anything means. In short, the fields about the Country, State or City is not required to match those of your CA's certificate.
After all this is done two new files are created:
certs/server.crt - this is the server's certificate, which can be made available publicly. newcerts/01.pem - This is exactly the same certificate, but with the certificate's serial number as a filename. It is not needed.You can now delete the certificate request (server.csr). It's no longer needed:
[root@server1 myCA]# rm server.csr
Verify the certificate
You can see the certificate's info with the following:
# openssl x509 -subject -issuer -enddate -noout -in /etc/pki/myCA/certs/server.crt
Or the following:
# openssl x509 -in /etc/pki/myCA/certs/server.crt -noout -text
And verify that the certificate is valid for server authentication with the following:
# openssl verify -purpose sslserver -CAfile /etc/pki/myCA/certs/myca.crt /etc/pki/myCA/certs/server.crt
Revoke a Server Certificate
If you do not want a certificate to be valid any more, you have to revoke it. This is done with the command:
# openssl ca -config openssl.my.cnf -revoke certs/server.crt
Then you should generate a new CRL (Certificate Revokation List):
# openssl ca -config openssl.my.cnf -gencrl -out crl/myca.crl
The CRL file is crl/myca.crl.