LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Any recent "LetsEncrypt war-stories? Advice? Best practices?" (https://www.linuxquestions.org/questions/linux-security-4/any-recent-letsencrypt-war-stories-advice-best-practices-4175598846/)

sundialsvcs 02-02-2017 06:37 PM

Any recent "LetsEncrypt war-stories? Advice? Best practices?"
 
After receiving a "rude awakening" :eek: from the former SSL vendor that covers a combined site which has about 75 different URL store-fronts, I need to fairly-abruptly shift the whole thing over to LetsEncrypt.

The sites run from a single set of software running on a cloud server cluster, and I will need to reliably implement a process that can obtain and then renew the certificates for all of them automatically.

A slight twist is that the sites do not yet run on their "final" IP-address, although I do control both old and new.

Actively soliciting any input – especially, links to really good web sites / blogs – to make my hasty-path here as smooth and quick(!) as possible.

(I have already vacuumed previous posts here on LQ ... thankye ... and all of the links contained therein.)

TheLinuxJedi 02-03-2017 04:05 PM

I worked with the people behind Let's Encrypt a little bit whilst I was at NGINX. I use it on several websites I manage. It is very easy to use and manage, I highly recommend it. NGINX have a blog post on it:

https://www.nginx.com/blog/free-cert...ypt-and-nginx/

As for your cert distribution problem, there is no automated way of doing it I'm aware of, I recommend using cron or similar to rsync the certs when it renews. There are people that have done this as you can see here:

https://community.letsencrypt.org/t/...-servers/16449

This would be much easier to solve with a load balancer in front of the cluster rather than relying on the client to use DNS and having that do the SSL termination.

Hope this helps.

thirdbird 02-04-2017 06:08 AM

I just read their story about Comodo trying to register/patent their brand name. Makes me feel almost guilty for using Comodo myself, it was the best priced DV I found before I knew LE is now a CA. I hope it's no real threat to them, and was good to know they're able to lawyer up.

TheLinuxJedi 02-05-2017 04:16 AM

I think there are too big many companies (with really good lawyers) invested in it for Comodo to do any damage. Don't feel guilty about it, some of the best tech companies have done similar things in the past to try and stifle competition.

There is a quote that is often misattributed to Gandhi which applies a lot in the tech world (and probably other industries):

"First they ignore you, then they laugh at you, then they fight you, then you win"

thirdbird 02-05-2017 12:25 PM

Swapped out my existing Comodo with LE certificates today for 3 domains in a apache/vhost setup to try it out. Was very smooth. Used certonly with webroot parameters as I didn't want it messing around in my existing config blindly. Whole job took 5mins. Automatic renewal is basically just a 'certbot renew' put into a cron.monthly script which intervals it safely within the 90 day period. As long as the vhosts keep pointing to the same /etc/letsencrypt/live/* locations, it's all good.

For me the main gain is being able to sort more stuff into subdomains now. Wildcards (even DV) are annoyingly expensive.

gradinaruvasile 02-06-2017 03:41 AM

I had StartSSL certificates that upon renewal this January gave me certificates valid until 2020. Only problem was after a few days Chrome started complaining that the certificate cannot be validated...
So started to use LetsEncrypt - i use nginx BTW.
Now certbot is very easy to use, there are 2 scenarios:

NOTE that port 80/http is used, NOT 443 for verifications.

1. webroot module: - you make sure anyone from outside can access http://domain/.well-known/ directory and launch certbot with root rights - it will populate the directory with some token received from letsencrypt site and subsequently verify that independently from outside
2. standard mode - make sure port 80 is NOT used by your web server, launch certbot that will launch an internal web server on that port temporarily, verify from outside. This does not need to change anything on your web server's config (but if you have a production server using http this is not practical).

thirdbird 02-06-2017 04:10 AM

Quote:

Originally Posted by gradinaruvasile (Post 5665755)
NOTE that port 80/http is used, NOT 443 for verifications....

That must be incorrect for existing and functional SSL vhosts - it works fine with those, I had a SSL-only host running on comodo DV that was no problem. But For new vhosts that needs SSL for the first time, this is correct. After generating the first certificate and making sure it works, you can then forward http to https, or deactivate http vhost entirely and also certbot renew will work fine. I tested this explicitly yesterday. Albeit with certonly and webroot with apache2, have never used the apache module or nginx.

gradinaruvasile 02-06-2017 04:39 AM

For me only on port 80 worked. I had nginx running only on https and it could not get it to work, it was complaining that it could not connect until i enabled port 80 too. After that it worked.
I used the webroot plugin then. After that i stopped nginx on port 80 and tried the standalone which worked.

TenTenths 02-06-2017 05:37 AM

Using webroot and a script that runs weekly to check and update certs for a box that has multiple sites on it.

Code:

#!/bin/bash

while read DOMAINPAIR ; do
  DOMAIN=$(echo ${DOMAINPAIR} | awk {'print $1'})
  FOLDER=$(echo ${DOMAINPAIR} | awk {'print $2'})
  echo "$(date) Starting ${DOMAIN} ${FOLDER}"
  /bin/certbot certonly --webroot -w ${FOLDER} -d ${DOMAIN} -d www.${DOMAIN}
done << EOLIST
example.com /home/sites/example.com/public_html
domain2.com /home/sites/domain2.com/public_html
onemore.com /home/sites/onemore/public_html
EOLIST

/sbin/apachectl graceful


thirdbird 02-06-2017 06:27 AM

Is running custom certonly/webroot commands for renewal preferable over just monthly cron'ing certbot renew ?

Certbot user guide:
Quote:

This will attempt to renew any previously-obtained certificates that expire in less than 30 days. The same plugin and options that were used at the time the certificate was originally issued will be used for the renewal attempt, unless you specify other plugins or options.
Haven't had need for renewal yet, but my theory was that it won't mess with configuration, just update the certificates since they are already installed.

TenTenths 02-06-2017 06:32 AM

Quote:

Originally Posted by thirdbird (Post 5665818)
Is running custom certonly/webroot commands for renewal preferable over just monthly cron'ing certbot renew ?

My script has been working fine for me :)

hortageno 02-06-2017 08:39 AM

Quote:

Originally Posted by gradinaruvasile (Post 5665755)
NOTE that port 80/http is used, NOT 443 for verifications.

I cannot confirm that. I only have port 443 forwarded to my webserver and creating and renewing the certificate works.

sundialsvcs 02-07-2017 07:39 AM

Does their "bot" attempt to update Apache configuration files?

TenTenths 02-07-2017 07:47 AM

Quote:

Originally Posted by sundialsvcs (Post 5666470)
Does their "bot" attempt to update Apache configuration files?

From memory it certainly didn't on mine. I always used "certonly" and it downloads the certs, it was up to me to create the config files.

thirdbird 02-07-2017 07:50 AM

Quote:

Originally Posted by sundialsvcs (Post 5666470)
Does their "bot" attempt to update Apache configuration files?

The apache module does, if you use --apache. Even used together with certonly, it will make temporary changes and undo them at the end - including a temporary vhost for authentication. Use webroot to stay away from configuration files. Check out their documentation, it's pretty good.


All times are GMT -5. The time now is 07:19 AM.