Trellis Let’s Encrypt Expired SSL / TLS certificate – Cause and Solution

Though Trellis VPS setups should auto renew the Let’s Encrypt certificate automatically I had a certificate expire for one of my Trellis sites the other day. Here is how I found out about the Trellis Let’s Encrypt Expired SSL / TLS certificate and how I worked out solving it.

Google Search Console Warning

The reason I found out about it was on time and not by visiting the site itself. I got a warning from the Google Search Console:

Expired SSL/TLS certificate on

To: Webmaster of

Google has noticed that the SSL/TLS certificate for has expired. This means that your website is not perceived as secure by some browsers. As a result, many web browsers will block users by displaying a security warning message when your site is accessed. This is done to protect users’ browsing behavior from being intercepted by a third party, which can happen on sites that are not secure.

Recommended Action:

Get a new certificate
To correct this problem, renew or get a new SSL/TLS certificate. This should be from a Certificate Authority (CA) that is trusted by web browsers.

And because Trellis uses HSTS I could not even continue to the site despite the warning I should not normally having an option to continue anyways..

Renew Certificate Manually

I checked Roots Discourse and found out I could use the following command to renew the certificate manually:

ansible-playbook server.yml -e env=production -K --tags letsencrypt

That was not enough though. I had to restart NGINX as well. And when I logged in I was told a reboot was needed as well:$ sudo service nginx restart$ sudo reboot

Cause Failed Auto Renew

Perhaps the during an auto renew request the server was not accessible. Did not see errors it was down though. I could also not find errors like:

2016/07/08 02:41:31 [error] 7259#7259: could not be resolved (110: Operation timed out) while requesting certificate status, responder:

as mentioned in a thread at Roots Discourse here. So I did not have issues accessing Let’s Encrypt for the renewal either.

Trellis Cron jobs

I checked for cron jobs next using:

for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done

as root, but no cron jobs were shown for any users . And we do need one to run the Let’s Encrypt auto renew of course. Then I mentioned this on Roots Discourse and got this comment by  CFX:

Please ensure your cron job (normally at /etc/cron.d/letsencrypt-certificate-renewal) has the full path to service in its reload command (original PR2). That was apparently my issue too—renewal was just fine but nginx never reloaded after renewal.

This way I learned the location of the cronjobs. And also that the path to reload NGINX could sometimes be the issue and a full path is needed in those cases. So I adjusted the path. And it was confirmed a little later that this was the main cause.


So through the comment by CFX I found out the cron jobs for Trellis are stored at:


and the Let’s Encrypt one is therefore at:


And this is the location for cron jobs I did not check. Now that file contains:

30 4 1,11,21 * * root cd /var/lib/letsencrypt && ./ && /usr/sbin/service nginx reload

This is a perfectly normal cron job. Now it also has the full path to reload NGINX properly. This being the issue I will now have the auto renewal work again like it should be.

NB Reading up on cron jobs here at Ubuntu Wiki it is mentioned too so I found out. It is a place where often one liners for particular users are stored instead of using a crontab.

Child Theme Trouble: This theme is broken

Sometimes you bump into errors while working with child themes. I bumped into a “This theme is broken” error the other day. I wanted to modify an existing child theme. When checking the child theme from the Dashboard I saw this warning in the header:

This theme is broken. Template is missing. Standalone themes need to have a index.php template file. Child themes need to have a Template header in the style.css stylesheet.

This was the first time in all these years I saw this error myself. Normally I create child themes well and then you won’t see warnings like these.

Missing Stylesheet Header

This “This theme is broken” error showed up because the stylesheet of the child theme was missing the necessary header. All child themes need one for proper display. Once I added:

 Theme Name: Divi Child Theme
 Theme URI:
 Description: Divi Child Theme for LawOkk
 Author: Jasper Frumau
 Author URI:
 Template: Divi
 Version: 1.0.1
 License: GNU General Public License v2 or later
 License URI:
 Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
 Text Domain: divi-child

all was wel again. No errors were mentioned. More details on the header and how to work with it can be found in the WordPress Codex. But basically you can you use my example or the example in the codex. It is just basically a way of indicating:

  • we are dealing with a child theme,
  • what the parent theme is and
  • some details on the design and author behind it
  • text domain being used

Index Missing

I did however not add the index.php yet. That was also mentioned in the error message. This is also needed when using standalone themes. And this is a child theme so one is not needed really. Files you do need are:

  • style.css
  • functions.php

Those contain information to show we are dealing with a child theme and the proper way of loading or enqueuing the child theme CSS.

Bonus I: Enqueuing Styles Properly

Functions.php should normally contains something like this to enqueue styles properly:

function my_theme_enqueue_styles() {

    $parent_style = 'parent-style'; // This is 'twentyfifteen-style' for the Twenty Fifteen theme.

    wp_enqueue_style( $parent_style, get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( $parent_style ),
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_styles' );

This way you will load the parent theme CSS as well as the child theme’s CSS well.  For a more detailed discussion on why it should be set up this way see this SO thread here. But this quote should tell you why you should use it instead of @import:

The statement @import url('../twentythirteen/style.css'); is completely independent of the underlying parent theme’s version. In fact, the parent theme can be updated without updating the child theme but browsers will still use cached versions of the old ../twentythirteen/style.css.

Bonus II: Extra Functionality

On top of that you can add extra functionality when need be of course. The functions.php in the child theme ads functionality to the parent. It does not override like the style.css in the child theme.


Adding a Favicon in WordPress

To add a favicon in WordPress these days is way easier than it used to be. You used to have to upload the file to the webroot of your website’s server and then added the necessary code to load the favicon in your header. For that your theme needed to have a specific line of code to load the icon like:

<rel="shortcut icon" type="image/png" href="/favicon.png"/>

Adding Favicon in WordPress  Customizer

This tedious way of adding favicons is a thing of the past. It is no longer necessary. Since WordPress 4.3 you can upload the favicon under appearance > customize > site identity. The only thing you have to keep in mind is to use an image of a minimum size of 512px x 512px:

Site Identity

Browser Display

After you added it you may have to empty your browser cache to see it properly. So do this if you do not see it yet in your browser. Once you have done that you should see the icon. Here is how the favicon for our Ianua theme in progress looks like once we added a new favicon icon:

Favicon Display in Browser