Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Sunday, December 4, 2016

Here come the Bash clients for Let's Encrypt - Acme.sh, Dehydrated and creating SSL Certificates

I was recently working on a server with a pretty old OS. In the past I've configured SSL using EFF's Certbot, a Python based client for managing Let's Encrypt's certificates, but Certbot requires Python 2.7 or better and the server only shipped with Python 2.4. I initially started on the journey of "jumping through hoops" getting Python 2.7 installed on the old system but then I discovered bash based clients for Let's Encrypt. So here are some short notes for my future self which might save some time.

In terms of shell scripts that re-implement the Certbot client there are two shell scripts that I currently know of, one called dehydrated and the other, which I discovered a day or two later, is called acme.sh.  I ended up using acme.sh, I found the acme.sh implementation to be a bit simpler than the dehydrated implementation. If you're interested in using dehydrated, there's reasonable documentation on how to install and use it at https://www.aaflalo.me/2016/09/dehydrated-bash-client-lets-encrypt/.

Acme.sh

Acme.sh promotes itself as follows:

  • An ACME protocol client written purely in Shell (Unix shell) language.
  • Full ACME protocol implementation.
  • Simple, powerful and very easy to use. You only need 3 minutes to learn it.
  • Bash, dash and sh compatible.
  • Simplest shell script for Let's Encrypt free certificate client.
  • Purely written in Shell with no dependencies on python or the official Let's Encrypt client.
  • Just one script to issue, renew and install your certificates automatically.
  • DOES NOT require root/sudoer access.
It basically installs itself in the home folder of the active user and also adds itself to the PATH.
Installation is as easy as:

curl https://get.acme.sh | sh
Or:
wget -O -  https://get.acme.sh | sh

After that you can create an SSL certificate for the domain with the following command:
acme.sh --issue -w /home/mysite/public_html/example.com -d example.com -d www.example.com
Unfortunately, while the certificate was created without a problem, the server was so old that the version of OpenSSL didn't support multiple domains on the same IP address according to this article I needed at least OpenSSL v0.9.8j. 

Truth be told the best course of action will be to upgrade the server since it is otherwise vulnerable. The knowledge won't be lost as I can use it on other projects on newer servers.

Saturday, August 27, 2016

Letsencrypt SSL certificates with nginx's proxypass

I was not able to directly use the instructions from the certbot site to successfully request an SSL certificate, instead I had to use their webroot plugin plus a few tweaks to my nginx configuration.

Background

For this project we were deploying a Pyramid based system which uses nginx's reverse proxy (proxypass). This approach will be useful in any scenario where nginx is using proxypass. The OS used is Ubuntu Trusty 14.04 but should work on Debian as well (some things are more straight forward on Ubuntu 16.04).

Here are all the key concerns:
  • Certbot/Letencrypt expects to find your certificate challenge data served under a folder called '.well-known'
  • By default all requests for my project are passed via a reverse proxy to our application.
This means that, in the context of my project, when a request is passed to /.well-known  instead of serving my certbot challenge information from a folder on the filesystem the request is handled by the proxy and passes it as a request to my application. 

The Procedure

The steps below assume that nginx is configured as follows:
A special configuration file located at /etc/nginx/sites-enabled/myproject.example.com which looks like this (be sure to change the server name to match the server you're working with):

Step 1 - Make nginx serve static files when requests are sent to /.well-known

To achieve this I created a folder /var/www/letsencrypt and made sure that it was owned by the webserver user.
sudo mkdir -p /var/www/letsencrypt
chown www-data:www-data  /var/www/letsencrypt

Then in my nginx configuration for my project I added the configuration below to ensure that requests made to myproject.example.com/.well-known would skip the proxy and be read from our /var/www/letsencrypt folder.

server {
       listen         80;
       server_name myproject.example.com;
       location /.well-known {
          alias /var/www/letsencrypt/.well-known;
       } 

Once that was in place I restarted nginx.

service nginx reload

Step 2 - Install Certbot


The part of the documentation that I read was silent about where to put the certbot-auto script. I decided to install certbot-auto in /usr/local/sbin, this means that it is in the system path and can be run as a command by itself (which feels nicer than needing to be in the folder when running the script).
cd /usr/local/sbin/
sudo wget https://dl.eff.org/certbot-auto
sudo chmod a+x certbot-auto

Step 3 - Request a certificate against the /var/www/letsencrypt 

Now you can easily request a certificate.

Note the use of --webroot in the command below, this ensures that the challenge information is added to the /var/www/letsencrypt folder. Also, I precede the command with sudo because installation of the actual certificates requires admin privileges. 
sudo certbot-auto certonly --webroot -w /var/www/letsencrypt -d myproject.example.com

Expected response

If everything was done properly you'll get a message like this:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/myproject.example.com/fullchain.pem.
   Your cert will expire on 2016-11-25. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"

Step 4 - Configuring Auto-renewal of certificates

Once setup properly the auto renewal steps that I took were near identical to the documentation.
I first tested to see that an auto renewal would work without issue:

certbot-auto renew --dry-run

Once the dry run was succesfull I added a renewal command as a cronjob using the crontab -e command:

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
@monthly certbot-auto renew --quiet --no-self-upgrade

Additional Notes

I ran across a few issues, mostly because I had a previous manual setup. As a result when I ran certbot-auto I ended up with multiple configuration files and certificates in the /etc/letsencrypt/renewal/ and /etc/letsencrypt/live/ folders.
I assume you have a basic understanding of Unix system administration, nowadays this is becoming more of a bad assumption but I mention it here for what it's worth.


Thursday, April 4, 2013

Security Matters

Every now and then, I take a peek at the landscape of the blogging world. In case I decide to change my platform. I run this blog on Blogger to save me the headache of worrying about updates and security for my blogging platform.

One of my explorations has me looking at "static" blogging platforms which "bake" your entries into static HTML files. This led me to a static blogging system called "Jeykll" and an article describing a way to run a Jekyll blog on Google AppEngine using DryDrop. That's not the point of this post, I ended up on a tangent due to the fact that the author of the article, though a Wordpress lover, had choosen to leave Wordpress due to security issues.

In his own words:
"I hosted about 25 wordpress blogs on my mosso account for various friends. I kept most of them up to date, but a lot of them were for friends and were not under my control. 100% of them got owned. hah. It was just something they did. no matter how fast or often i updated the wordpress software - it would be owned at least one time. My personal blog was safe for some reason. Maybe it was because I always ran the bleeding edge version from SVN. I will not miss the constant updates and the attacks. The wordpress community does a good job of handling this issue. I, however, was tired of it."
Apart from the Plone sites that I manage, I am responsible for two Wordpress sites (I'm aware of all the cautionary tales so I'm keeping those WP sites up to date, backed up, plus my fingers crossed).

Bottom-line, security matters!

update:
If you're seriously looking into static blogging you may want to check out Ruhoh.

Sign up for my upcoming Plone 5 Book & Video tutorials

plone 5 for newbies book and videos