Sign and verify a file using OpenSSL

If you need to sign and verify a file you can use the OpenSSL command line tool. OpenSSL is a common library used by many operating systems (I tested the code using Ubuntu Linux).

I was working on a prototype to sign the source code of open source projects in order to release it including the signature. More or less the same idea implemented in Git to sign tag or a commit. Git uses GnuPG, I wanted to do the same using OpenSSL to be more general.

Sign a file

To sign a file using OpenSSL you need to use a private key. If you don’t have an OpenSSL key pair you can create it using the following commands:

openssl genrsa -aes128 -passout pass:<phrase> -out private.pem 4096
openssl rsa -in private.pem -passin pass:<phrase> -pubout -out public.pem

where <phrase> is the passphrase used to encrypt the private key stored in private.pem file. The private key is stored in private.pem file and the public key in the public.pem file.

For security reason, I suggest to use 4096 bits for the keys, you can read the reason in this blog post.

When you have the private and public key you can use OpenSSL to sign the file. The default output format of the OpenSSL signature is binary. If you need to share the signature over internet you cannot use a binary format. You can use for instance Base64 format for file exchange.

You can use the following commands to generate the signature of a file and convert it in Base64 format:

openssl dgst -sha256 -sign <private-key> -out /tmp/sign.sha256 <file>
openssl base64 -in /tmp/sign.sha256 -out <signature>

where <private-key> is the file containing the private key, <file> is the file to sign and <signature> is the file name for the digital signature in Base64 format.
I used the temporary folder (/tmp) to store the binary format of the digital signature. Remember, when you sign a file using the private key, OpenSSL will ask for the passphrase.

The <signature> file can now be shared over internet without encoding issue.

Verify the signature

To verify the signature you need to convert the signature in binary and after apply the verification process of OpenSSL. You can achieve this using the following commands:

openssl base64 -d -in <signature> -out /tmp/sign.sha256
openssl dgst -sha256 -verify <pub-key> -signature /tmp/sign.sha256 <file>

where <signature> is the file containing the signature in Base64, <pub-key> is the file containing the public key, and <file> is the file to verify.

If the verification is successful, the OpenSSL command will print “Verified OK” message, otherwise it will print “Verification Failure”.

I created a gist containing two bash scripts to facilitate the signature and verification tasks.
The script is able to generate the signature of a file using the following command syntax: <file> <private_key>

where <file> is the file to sign and <private_key> is the file containing the private key to use for the signature. The signature will be stored in the signature.sha256 file using the Base64 format.

To verify a signature you can use the script with the following syntax: <file> <signature> <public_key>

where <file> is the file to verify, <signature> is the file containing the signature (in Base64), and <public_key> is the file containing the public key to be used to verify the digital signature.

Install PHP 7 on Ubuntu 14.04

Update: if you are using Ubuntu 15.04, you can have a look at this script by Maulik Mistry.

I just installed PHP 7.0.0-dev (based on PHPNG) on my GNU/Linux box (Ubuntu 14.04) and I found some errors during the procedure. I decided to write this note to help people using the same Ubuntu environment.

Before to start I would like to remind that PHP 7 is still in development and SHOULD NOT BE USED in production environments. I installed to try and experiment the new features of the language. The first stable release of PHP 7 is scheduled by the end of the year, with a projected release date of November 2015.

To install PHP 7 we need to clone the php-src repository, configure and compile. Let’s create a php7 folder in the home directory and clone the project:

mkdir $HOME/php7
cd $HOME/php7
git clone

After that, we need to prepare and configure the compiler. We need to execute the following commands:

cd php-src
./configure \
    --prefix=$HOME/php7/usr \
    --with-config-file-path=$HOME/php7/usr/etc \
    --enable-mbstring \
    --enable-zip \
    --enable-bcmath \
    --enable-pcntl \
    --enable-ftp \
    --enable-exif \
    --enable-calendar \
    --enable-sysvmsg \
    --enable-sysvsem \
    --enable-sysvshm \
    --enable-wddx \
    --with-curl \
    --with-mcrypt \
    --with-iconv \
    --with-gmp \
    --with-pspell \
    --with-gd \
    --with-jpeg-dir=/usr \
    --with-png-dir=/usr \
    --with-zlib-dir=/usr \
    --with-xpm-dir=/usr \
    --with-freetype-dir=/usr \
    --with-t1lib=/usr \
    --enable-gd-native-ttf \
    --enable-gd-jis-conv \
    --with-openssl \
    --with-mysql=/usr \
    --with-pdo-mysql=/usr \
    --with-gettext=/usr \
    --with-zlib=/usr \
    --with-bz2=/usr \
    --with-recode=/usr \

During the execution of configure command, I found a couple of errors.

Error: Your t1lib distribution is not installed correctly.

I fixed using:

sudo apt-get install libt1-dev

Error: Unable to locate gmp.h

I tried to install the libgmp-dev library:

sudo apt-get install libgmp-dev

but the library was already installed, so I search for it:

locate gm.h

and I found it on /usr/include/x86_64-linux-gnu/gmp.h (I’m using a 64bit version).

I tried to symlink it to /usr/include/gmp.h (the default location for include):

ln -s /usr/include/x86_64-linux-gnu/gmp.h /usr/include/gmp.h 

and finally the configure execution was successful. If you find other errors on your environment I suggest to read this post by Maciej Zgadzaj, where he reported a list of possible errors and solutions for Ubuntu systems.

Now it’s time to compile PHP 7 with the following commands:

make install

The first command compile the PHP. I took about 9 minutes to compile PHP 7 on my computer (Intel i5-2500 at 3.3Ghz). The second command install the PHP modules and configuration in $HOME/php7/usr folder.

We have almost done the installation, we just need to create the php.ini file in the $HOME/php7/usr/etc folder. We can easily create it using vi with the following commands:

mkdir $HOME/php7/usr/etc
vi $HOME/php7/usr/etc/php.ini

We can use the following content for the php.ini:


And finally we can test PHP using the command line interface (CLI):

$HOME/php7/php-src/sapi/cli/php -v

You will get a result like this:

PHP 7.0.0-dev (cli) (built: xxx) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies

If you want to learn about the new features of PHP 7 I suggest to read the following resources:

Documenting APIs using Apigility

One of the cool feature of Apigility is the ability to generate API documentation using a simple UI. The documentation is generated in HTML format, and optionally in Swagger format. The API documentation is reported in Apigility in the top bar, under the menu “API Docs” (Figure 1, using Apigility 1.0.0beta1).

API documentationFigure 1

In order to generate the API documentation you need to insert some desciptions before. All the information to edit are reported in the Documentation tab on each REST or RPC service (Figure 2).

REST API documentationFigure 2

For each service and for each HTTP method, you can specify a description of the action. In case of RESTful services you can also specify different information for an Entity and a Collection. An interesting feature of the API documentation is the ability to generate the Response Body specification from the configuration, using the “generate from configuration” button (Figure 3).

Generate from documentationFigure 3

This button read the configuration of the API and propose a JSON response based on the fields specified (the fields are documented under the Fields tab of each REST and RPC service). Of course, you can edit the response body changing the output, if you need.

Once you have added some API descriptions, you can go to the “API Docs” menu and show the API documentation (in our case version 1, Figure 4).

API documentation in HTML formatFigure 4

You will see all the API documentation in HTML format, using the Bootstrap 3 template.
You can expand and collapse the information on each HTTP method clicking on the name. All the API documentation are exposed in the /apigility/documentation base URL.

How to install the Swagger adapter

To activate the Swagger adapter for the API documentation, you need to add the following dependency in the composer.json file (in the require field):

"zfcampus/zf-apigility-documentation-swagger": "~1.0-dev"

and execute the composer update commmand.

After the installation of zf-apigility-documentation-swagger you need to enable this module in the config/application.config.php file. You have to edit this configuration file and add the following line after the ‘ZF\Apigility\Documentation’:


Now you can go to the Swagger documentation from the welcome screen, clicking on the Swagger API documentation button, or going directly to the /apigility/swagger URL.
To show the Swagger UI render you have to select the API service version and you will see a web page like the one reported in Figure 5 (using Swagger UI).

API documentation in Swagger formatFigure 5

Customizing the API documentation module

The API documentation feature is offered by Apigility using the zf-apigility-documentation module, written in Zend Framework 2. This module provide an object model of all captured documentation information, including:

  • All APIs available
  • All Services available in each API
  • All Operations available in each API
  • All required/expected Accept and Content-Type request headers, and expected Content-Type response header, for each available API Service Operation.
  • All configured fields for each service

Moreover, it provides a configurable MVC endpoint for returning documentation

  • documentation will be delivered in a serialized JSON structure by default
  • end-users may configure alternate/additional formats via content-negotiation

If you want to customize the format of your API documentation you can have a look at the source code of the zf-apigility-documentation-swagger module. Basically, you need to create a custom route for your format (see the Swagger module.config.php) and use the ZF\Apigility\Documentation\ApiFactory to access the data for the API documentation services. The view model to implement needs to manage a list view and a show view, that’s it.

All the API documentation formats are driven by content negotiation (using the zf-content-negotiation module). For instance, to get the API documentation data in Swagger format you can use the content negotiation “application/vnd.swagger+json”.

For example, if you want to retrieve the API documentation data in JSON format you can use the following request (using HTTPie):

http GET http://localhost:8888/apigility/documentation[/api]/[service] 'Accept:application/json'

where [api] is the name of the API and [service] is the name of the REST or RPC service. To get the same result in Swagger format you can use the following request:

http GET http://localhost:8888/apigility/documentation/[api]/[service] 'Accept:application/vnd.swagger+json'