SSL – Secure Socket Layer


This article is a gentle introduction to problematics of secure electronic communication. Whoever wants to communicate on the Internet in a secure manner can generally choose one of two technologies. One of them is PGP respectively the free implementation GPG. The characteristic feature of this is that the trustworthiness and security of communication are based solely on the relationship between the sending and the receiving party. However in some situations, this is not satisfactory. If you want to communicate with government entities, servers that are not under your control, people you never met in person, there is an opportunity to use security certificates. Communication protocols based on security certificates are is as SSL – Secure Socket Layer. While the name talks about sockets (software communication objects) the concepts go far beyond that. The name SSL often refers to a suite of communication protocols based on digital certificates that are described in standard X.509. If you want to use it, then the cheapest way is to use OpenSSL.

With SSL systems, it is not necessary that the sender and recipient know each other personally. Verifying the identity of the communicating parties is facilitated by Certification Authority – CA. That is an organization that is issuing security certificate – a data structures containing cryptographic information that can be used to create a digital signature. If I get a message from user Bob and the message is accompanied by a signature created using a certificate issued by a CA, then CA warrants that the certificate was issued only to the user Bob and nobody else is able to create the signature but the user Bob. The certificates also contain cryptographic data that can be used for encrypting data in digital communication.

There is a multitude of certificate authorities in the world. That are organizations that you can ask to issue a security certificate and you can then use this certificate for secure communication. The well known CA’s are RSA Security Inc.Symantec Corp., or VeriSign Inc. Certificates issued by these companies are often used by banks and Internet shopping sites. Certification authority has to follow stringent security rules – starting with physically securing the CA premises, off-site backups, disaster recovery plans and including background checks and security clearance of the employees. Of course, there are some costs associated with the operation of a CA and the CA can offsets the costs by charging for issuing the certificate. There are CA’s that are issuing low-cost certificates or even for free, but usually with limited use.

Certification authority

In some situations, it is enough if we run our own CA. The only trouble with that is that we have to convince everyone, who will use security certificates issued by our CA to trust our CA. Certification authorities such as VeriSign, Symantec, Thawte etc. gained the trust of the market by providing the service for many years. Fortunately to create our own CA is not so technically challenging. We will use software with name OpenSSL. If you are running Linux, then very likely this is already installed on your machine (or can be installed easily). If you are using MS Windows head over to After installing the OpenSSL software you can create the CA from command line like this:

The first step is creating private

openssl genrsa -out CArsaprivtekey.pem 2048

Generating RSA private key, 2048 bit long modulus
e is 65537 (0x10001)

The parameters specify that we are creating the file CArsaprivtekey.pem to which we want to write 2048-bit key. Keeping this file secure from adversaries is a basic cornerstone of security of the whole Certification Authority. The 2048 bits specifies the strength of the private key. Technically you can choose also a different number, but 1024-bit is nowadays considered not strong enough to protect against well-funded adversaries or governments. It is not exceptional for commercial CAs to go as far as 4096-bits. You can read more on key strength here. The file extension .pem indicates that the file will contain the private key in PEM format.

The next step is creating a certificate request for CA certificate.

openssl req -new -x509 -key CArsaprivtekey.pem -out CAcertificate.pem -days 3560 -sha256

You are about to be asked to enter information that will be embedded
into your certificate request.
There are quite a few fields but you can leave some blank
For some fields, there will be a default value,
Country Name (2 letter code) [AU]:SK
State or Province Name (full name) [Some-State]:Slovakia
Locality Name (eg, city) []:Trencin
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Rastos Certificate Authority
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:rastos CA
Email Address []:

On this command line, we see that we are creating a request for creating a new certificate of type X509 based on the RSA key from file CArsaprivtekey.pem. The resulting certificate will be stored in the file CAcertificate.pem. We will use this certificate for creating certificates of the individual clients. The parameter -days 3650 says that the certificate will be valid for 3560 days (10 years) and -sha256 says that when using this certificate the software will use hashing function SHA-256. SHA-256 belongs to a family of cryptographic functions SHA2. Note that research papers published in 2009 proved to that SHA1 is not secure enough.

The file with certificate is encoded using base-64 encoding and looks like this:


If you want to see content of this file in human readable form then the following command can you help with that:

openssl x509 -text -in CAcertificate.pem -noout

        Version: 3 (0x2)
        Serial Number:

To get a working CA using OpenSSL we need one more step – create a file in which the OpenSSL keeps track of currently issued and valid as well as invalid certificates:

mkdir demoCA
touch demoCA/index.txt
echo 01 > demoCA/serial

Location of these files defines configuration file:

[ CA_default ]
dir             = ./demoCA              # Where everything is kept
database        = $dir/index.txt        # database index file.
serial          = $dir/serial           # The current serial number


When the user wants a certificate issued by our CA, he first has to send us a certificate request:

openssl req -new -out RScertrequest.pem -keyout RSprivatekey.pem -days 3650 -sha256

Generating a 1024 bit RSA private key
writing new private key to 'RSprivatekey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
into your certificate request.

Notice that the software asked from “PEM pass phrase” – this is the password that we will use when creating the digital signature. The security of this password is an important factor of security of the whole system. Parameters -days 3650 -sha256 have the same meaning as described above.

Certification authority should now verify that the request really belongs to the person, that delivered the certificate request and then it can create the certificate itself:

openssl ca -in RScertrequest.pem -out RScertificate.pem -policy
policy_anything -outdir . -cert CAcertificate.pem -keyfile CArsaprivtekey.pem
-verbose -days 3650 -md sha256

Using configuration from /etc/ssl/openssl.cnf
0 entries loaded from the database
Certificate is to be certified until Feb 11 21:22:57 2007 GMT (365 days)
Sign the certificate? [y/n]:y

Write out database with 1 new entries
writing new certificates
writing ./01.pem
Data Base Updated

In this command, we used parameters that specify that CA will use certificate request stored in RScertrequest.pem to create a certificate signed by our certificate authority. This certificate will be usable for all purposes (encryption/signing/…) and will be created using the certificate CAcertificate.pem and the private key CArsaprivtekey.pem and this certificate will be valid for 3650 days. The file RScertificate.pem now the CA returns to the client and he can now use it for secure communication using SSL. The certification authority keeps one copy of the signed certificate
in file 01.pem. From the signed certificate we can extract the public key, that we will need when verifying the digital signature.

openssl x509 -noout -pubkey -in RScertificate.pem > RSpublickey.pem

Digital signature

The digital signature is created from the input document by computing a “checksum”. The checksum is computed using a special mathematical algorithm. The core property of this7 algorithm is that when for any input it computes an output from which you cannot infer the input and at the same time even a tiny change in the input causes a change in the output. In past, such properties were obtained using a simple algorithm called

CRC. It was designed to capture random unintentional errors, but it was not cryptographically secure These days we use algorithms such as MD5, but this is being superseded by SHA1 rest. SHA2.
The output of the algorithm is called a “digest”. This digest is then encrypted using the private key:

openssl dgst -sign RSprivatekey.pem input_file > signature_file

Enter pass phrase for RSprivatekey:

The software is now asking for the password to RSprivatekey.pem and using that certificate it creates a digital signature. The signature is unique for this private key and the input file. Nobody can create such signature but the person possessing the private key. The person that wants to verify that the document is genuine (not altered since the time when the signature was created) computes the digest and compares it to the digest obtained by decrypting the digital signature:

openssl dgst -verify RSpublickey -signature signature_file < input_file

Verified OK

If someone changed the content of the file, the signature would not match:

openssl dgst -verify RSpublickey -signature signature_file < modified_input_file

Verification Failure

From CUI to GUI

In the previous text, we handled the certificates using command line tools from OpenSSL suite. Let’s now have a look at using SSL from mailing program or in a browser. In order for these programs to use encryption or digital signing of messages we first have to teach the programs about our certification authority, that is issuing these certificates.

If we plan to digitally sign messages that we send out we will need to import our own certificate. Mailing programs usually require the certificate in a format that differs from the format that we used until now – PKCS#12. Fortunately, OpenSSL provides a way how to convert the certificates to the right format:

openssl pkcs12 -in RScertificate.pem -inkey RSprivatekey.pem -export
-out RScertificate.p12

Enter pass phrase for RSprivatekey.pem:
Enter Export Password:
Verifying - Enter Export Password:

In the same way, we will need to import certificates of people to which we will send encrypted messages.

When the import is done, then while composing the message we can choose whether the message will be encrypted, signed or both:

With these settings the body of the e-mail will be encrypted. Note however that the header of the e-mail containing information about the sender, recipient, subject, date, etc are not encrypted.

Secure web

The next area, where we can encounter SSL certificates, are web servers. A typical example is web certificates for Internet-banking. The point is that the user can verify that he is really connected to the web server of the bank and not web server of an impostor, that is trying to steal some valuable information, credit card number etc. Apart from the verifying authenticity of the server SSL takes care also about encrypting the traffic flowing between the web server and the browser. It is relatively easy to learn how that works. We need for that a web server apache that was compiled with SSL support (i.e. when compiling from source code the switch --with-openssl was used).

The SSL functionality is available in a form of a module named mod_ssl. In order to enable this functionality, the configuration of the apache web server needs to contain directive:

LoadModule ssl_module libexec/apache/

On my own system, this is achieved by removing a comment in the configuration file /etc/apache/httpd.conf that includes the configuration of SSL:

# ==> mod_ssl configuration settings <==
Include /etc/apache/mod_ssl.conf

If the mod_ssl module was loaded correctly, then it shows up the log (the location of the log is specified by directive ErrorLog and the message is influenced also by directive LogLevel in httpd.conf):

tail /var/log/apache/error_log
[Wed Feb  8 21:25:24 2006] [notice] Apache/1.3.33 (Unix) mod_ssl/2.8.22
OpenSSL/0.9.7d configured -- resuming normal operations

Apart from correct loading of mod_ssl we need at least the certificate and the corresponding private key. The location of these files is specified by directives in configuration file:

SSLCertificateFile /etc/apache/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache/ssl.key/server.key

Important is also setting up the port. The web connections protected using SSL are traditionally using on port https (with number 443):

<IfDefine SSL>
Listen 80
Listen 443

All we have to dow now is to cross the fingers and start it up:

httpd -DSSL
Apache/1.3.33 mod_ssl/2.8.22 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them, you have to provide us with the pass phrases.

Server ras:443 (RSA)
Enter pass phrase:
Ok: Pass Phrase Dialog successful.

In this example, the server name is “ras”. We can verify that the web server is listening on port https. For example using netstat:

netstat -ltp |grep http
tcp  0  0  *:http  *:*  LISTEN  3616/httpd
tcp  0  0  *:https *:*  LISTEN  3616/httpd

If everything is fine, then we can try to connect using the browser. Because I’m using a certificate created by me, then the browser will display a warning that he does not recognize the certificate nor the CA that issued it and allows me to add them to the browser’s certificate store. This can be avoided if you add the certificate of the CA to the list of trusted CA’s beforehand:

SSL modules of the apache web server can do much more. For example, it can allow access to some URLs only to a browser that can present the right certificate etc. The detailed description of that is out of scope for this article, but feel free to read more about that in documentation.


If you followed the steps described above, you surely noticed that the private key is protected by a password. What happens when the password is compromised? In such case, someone can steal our identity and pretend to be us. Assuming of course that he obtains also the private key. The adversary can also decrypt messages that should be readable only by us. This problem is solved by revocation certificates. The certification authority, apart from issuing certificates also keeps track and publishes CRL – list of certificates that are not valid anymore.

openssl ca -revoke RScertificate.pem -keyfile CArsaprivtekey.pem -cert CAcertificate.pem

In the parameters, we can see that we are revoking the certificate RScertificate.pem and we need for that the private key of the CA as well as CA’s certificate. The revocation certificates are not so widely known. In case that you are for example creating a connection to bank’s web server then you should not only verify that you are connecting to the right server, but also whether the certificate wasn’t in the meantime revoked. Some browser can do that for you – assuming that they are configured correctly:

Final words

The program “openssl” from package OpenSSL that we used in the examples is not intended fro the end user and is also not the most important part of this package. The most important part are libraries implementing the individual encryption and hashing algorithms and the program OpenSSL is only providing access to this functionality. Apart from OpenSSL, the package contains also other things such as etc. The libraries from OpenSSL package are used in many software projects, where they handle the security of transmitted and stored data. Keeping this package up to date is an important part of the security of the whole system.

Leave a Reply