Tag Archives: apache

Automatically Renew SSL Cert with LetsEncrypt and getssl

Let's Encrypt Logo

With the recent federal government shutdown, it’s quite apparent their IT administrators still renew SSL certificates manually since many government websites went offline after the certs expired. Politics aside, since having secured connection and valid certificates are important these days, it should be a point for administrators to start automating the process. At the very least, have a project or plan in place to anticipate the shutdown and go through all of the important websites for possible cert renewals, 1-2 months in advance. As an Enterprise administrator, it’s also essential to have alerts or calendar reminders to renew an expiring cert. However, the best solution is to setup an automated job.

This is where tools out there like getssl and certbot can help. For this website, getssl is used to automate the SSL renewal process. The key processes are as follows:

Ensure Apache web server is setup. Since getssl relies on obtaining the proper “ACME” code from the target website to confirm the correct URL host, a regular port 80 HTTP connection must be made available first.

Per getssl documentation, run the inital setup to create the proper folders and files in $HOME/.getssl

getssl -c yourdomain.com

Edit the getssl.cfg in $HOME/.getssl/yourdomain.com folder with the correct directory for Apache web server’s doc-root and configuration files. Note, package installed Apache HTTPD uses /etc/apache2 as the default config directory.

When getssl is all setup, create a crontab to run getssl twice every month, for timely renewal (within 30 days). Be sure to restart Apache HTTPD to make sure the web server reloads the latest cert files.

0 9 1,15 * * $HOME/getssl/getssl -u -a > $HOME/getssl/getssl.out.txt 2>&1

Installing Elasticsearch Client on PHP

For a simple demonstration of using Elasticsearch programmatically as a web app, it’s a little more practical to use PHP as a starting point to learn how to connect and display search results. As a guideline, the quick-start instruction from Elastic site is a starting point. To expand (possibly complete) the out of the box setup, below are the steps to setup PHP to enable Elasticsearch support.

First, install the PHP Curl support for Apache on Linux:

apt-get -y install php-curl

Setup the PHP Composer in the doc-root folder, as outlined from elasticsearch-php github. Setup the php libraries via Composer:

php composer.phar init
curl -s http://getcomposer.org/installer | php
php composer.phar install --no-dev

Be sure to get the dependency package “elasticsearch/elasticsearch” and use the latest version as default. Note, skip the development package as it’s not really necessary.

Then, edit the composer.json file to include the directive:

   "require": {
            "elasticsearch/elasticsearch": "~6.0"

Finally, create a test page to see if it can connect to the Elasticsearch server:


require 'vendor/autoload.php';

use Elasticsearch\ClientBuilder;

$hosts = [

$client = ClientBuilder::create()

$params = [
    'index' => 'myindexname',
    'body' => [
        'query' => [
            'match' => [
                'post_title' => 'elasticsearch'

$response = $client->search($params);

$totalhits = $response['hits']['total'];
echo "We have $totalhits total hits\n";

echo "<P>The hits are the following:</P>";
$result = null;
while ($i <= $totalhits)
        $result[$i] = $response['hits']['hits'][$i]['_source'];

foreach ($result as $key => $value)
        echo $value['post_title'], "<br>";


Output will look something like this:

We have 2 total hits

The hits are the following:

Using Elasticsearch for JBOSS Logs
Deleting Entries in Elasticsearch Based On Timestamp

Update Nov/2019: Since Elasticsearch updated their basic license to include basic username/password security, it’s advisable to set them up. It’s a straight-forward addition:

$hosts = [
      'host' => 'myelasticsearchhost',
      'port' => '9200',
      'scheme' => 'http',
      'user' => 'myElasticUser',
      'pass' => 'myPassword'

Edit November 6, 2020: If there’s an upgrade or re-install of the OS into the latest version (such as from Ubuntu 16.x to 18.x), it is possible the version of cURL installed for PHP is a different one. For example, running php -m reveals:

PHP 7.2.34-8+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Oct 31 2020 16:57:15) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.2.34-8+ubuntu18.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies

Since it is version 7.2 of PHP, install the cURL PHP library: apt-get install php7.2-curl

Heartbleed: A Scrambled Egg with Lots of Ham

CVE-2014-0160The sensational headline news this week was “Heartbleed” security flaw, which was covered by most mainstream and tech sites.  It was an old bug that was accidentally introduced, and just discovered recently1. The report got IT professionals scrambling to fix their systems.

At first glance, the bug is benign enough, with chances of hacking the passwords or SSL keys rather slim. However, like any other hacking issues, if someone is determined (and clever) enough to exploit this bug, they may just get a bunch of useful data. Whether or not they can use the hacked data to steal client information, or use it for a phishing site, it’s unclear. Just the thought of the potential leak scares the daylights out of everyone! It’s also proof that the marketing behind this bug was very effective.

Regardless, the actions need to be taken are as follows:

  1. Check with Qualys SSL Analyzer to determine if your site is vulnerable.
  2. If vulnerable, upgrade OpenSSL to version 1.0.1g, or alternatively recompile OpenSSL without the “heartbeat” option (-DOPENSSL_NO_HEARTBEATS).
  3. Recompile or restart the web server to reload the latest OpenSSL libraries.
  4. Test the site(s) with the Qualys SSL Analyzer again.  Also check if site is functional.
  5. With the new OpenSSL, generate a new SSL key, and re-key a new certificate.  Install the new key/certificate in the web server(s).
  6. Urge the users to change their passwords – which they occasionally have to do, anyway.  This step is tricky considering the PR scare that it’s going to generate when admitting the site is vulnerable.  However, the notification is the responsible thing to do.

When the dust settles, we can look back and use this as an important reminder how fragile the Internet is.  Customers are expected to be cautious of their data being transmitted over the Internet, no matter how secure a company claim they’re being kept.

  1. Introduced in 2011 and found out in February 2014 []