That looks like a lot more work than the official client. I don&#x27;t get why so many people immediately on the first day of public beta turn to alternative clients. I used the official one, and by looking at the --help options I easily found how to automatically generate a certificate without taking down the server, and without using root privileges:<p><pre><code>    letsencrypt -t --work-dir &#x2F;tmp --logs-dir &#x2F;tmp \ 
    certonly --webroot &#x2F;var&#x2F;www&#x2F;example.com&#x2F;htdocs -d example.com
</code></pre>
With this in nginx.conf:<p><pre><code>    listen 443 ssl http2;
    ssl_certificate &#x2F;etc&#x2F;letsencrypt&#x2F;live&#x2F;example.com&#x2F;fullchain.pem
    ssl_certificate_key &#x2F;etc&#x2F;letsencrypt&#x2F;live&#x2F;example.com&#x2F;privkey.pem
</code></pre>
Those paths are examples obviously. But I did that, issued a &#x27;service nginx reload&#x27;, and it was done. I can reissue that command in a cron job to renew whenever I want.<p>There are some Python dependencies for the official client, but my package manager installed them for me, so I don&#x27;t get why people avoid it, especially when most of these alternative clients require more work.<p>The official client handles your registered account, and I don&#x27;t trust the alternatives not to mess with that or be incompatible in some way, so if you ever want to seamlessly use the official again you might end up with a different account identity or something. I don&#x27;t know, I didn&#x27;t look too deeply into it, other than the steps, and the official one was easiest for me.