[OPEN-ILS-DEV] Let's Encrypt on Evergreen server
Blake Henderson
blake at mobiusconsortium.org
Fri Jun 17 20:00:41 EDT 2016
Kesley,
We just got Let's Encrypt setup on production. We use a load balancer,
which made the setup a little more complex. We created a perl script to
generate each of the sub domain certificates and rsync them to each brick.
The certificate's only work if you have a folder in the web root
(/openils/var/web) that can be accessed by all bricks. We use a central
NFS server for this purpose. A symlink to a common folder. The
letsencrypt software spontaneously creates a random file in the root of
the webserver, in a folder called ".well-known" and expects to get
served that over the internet.
We symlinked like this:
ln -sf /mnt/centralnfs/letsencrypt_shared_web_directory/.well-known
/openils/var/web/.well-known
This is how we make the certificate request authentication work.
This is the magic command that makes the certificate requests possible
/root/.local/share/letsencrypt/bin/letsencrypt certonly --webroot
--webroot-path /path/to/shared --renew-by-default --email
emailaddress at example.com --text --agree-tos -d domainname.com
You can take a look at the code and feel free to use it:
https://github.com/mcoia/mobius_evergreen/tree/master/letsencryptpush
-Blake-
Conducting Magic
MOBIUS
573-234-4513
877-312-3517
On 3/9/2016 6:58 PM, Kelsey Lied wrote:
> Thanks, Ben!
>
> I readded the regular vhost in eg.conf, which got rid of my fmall.js
> errors as expected. Didn't upset my SSL setup (also expected), so the
> server's got valid SSL and Evergreen working now.
>
> I tried to run a cert renewal through Let's Encrypt to see if having 2
> vhosts now would upset it again, and I'm getting an error that seems
> to be pretty commonly reported for Let's Encrypt
> (https://github.com/letsencrypt/letsencrypt/issues/1294#issuecomment-153581276,
> for starters) -- so I'll duck over there now. Pretty sure whatever's
> going on is entirely on the Let's Encrypt side now.
>
> Thanks again!
>
> On Mon, Mar 7, 2016 at 11:00 PM, Ben Shum <ben at evergreener.net
> <mailto:ben at evergreener.net>> wrote:
>
> Hi Kelsey,
>
> This is a paste copy of the vhost definitions in my eg.conf for my
> test server: http://pastie.org/private/3mhgp90ba4a0xrwz48v16q
>
> As indicated in the paste, I have a servername and then also
> serveralias because I used two hostnames for this machine.
>
> Everything else in eg.conf matches the stock setup file as far as I
> can tell. I did not encounter any error for my http vhost.
>
> The error I'd focus on from your sample is this part: "fmall.js:
> Error: File not found:
> http://evergreentest.stkate.edu/opac/common/js/fmall.js"
>
> That file not found is cause it's trying to use the regular HTTP way
> of finding the file instead of the forced secure HTTPS in your system.
> If I change that URL to https:// in my browser, and look for the file
> path, I can find the file. So this is a case where if you comment out
> the regular http vhost, bad stuff happens.
>
> Normally, trying to force to HTTPS everywhere would be done via the
> eg_vhost.conf configuration, at the end of that file. However, there
> is a known bug open where developers are trying to figure out some
> remaining issues with forcing HTTPS everywhere:
> https://bugs.launchpad.net/evergreen/+bug/1507013
>
> Hope that helps a little.
>
> -- Ben
>
> On Mon, Mar 7, 2016 at 8:28 PM, Kelsey Lied <kalied at stkate.edu
> <mailto:kalied at stkate.edu>> wrote:
> > Hi Ben,
> >
> > Awesome! I'm excited about your response -- I've got a similar
> setup with
> > Ubuntu 14.04/Apache 2.4.
> >
> > Here's what I've got today --
> >
> > - I commented out the HTTP vhost in
> /etc/apache2/sites-available/eg.conf,
> > leaving only the HTTPS vhost, since Let's Encrypt was giving an
> error about
> > only working with one vhost. Also verified ServerName of that
> vhost is my
> > fqdn.
> > - Redid the whole auto-letsencrypt apache thing, got through
> without errors
> > this time. Server passed ssllabs.com <http://ssllabs.com> test,
> too. (Hooray!)
> > - Stopped and started opensrf, ran autogen.sh, and restarted apache.
> > - Verified no certificate errors when hitting https://fqdn (Hooray!)
> > - Attempted to start Evergreen client. Got following errors:
> > fmall.js: TypeError: document.getElementsById("offlineStrings")
> is null (OK
> > button)
> > fmall.js: Error: File not found:
> > http://evergreentest.stkate.edu/opac/common/js/fmall.js
> > - Found a 2013 IRC log about these errors
> > (http://irc.evergreen-ils.org/evergreen/2013-08-27). Reran
> autogen.sh, no
> > luck. Have noted: if I hit the given URL in a browser, I also
> get a File
> > Not Found. HOWEVER, if I hit the same over HTTPS, I get data back.
> >
> > Wondering if commenting out the HTTP vhost is causing the
> fmall.js errors.
> > It's also possible that I've got localhost hanging out somewhere
> in my
> > Evergreen setup that needs to be swapped out for the domain name
> -- I
> > originally started without and may have missed a spot when I
> tried to swap
> > in the domain name later. Thoughts?
> >
> > Side note: I am somewhat baffled about how the server and
> hitting the
> > browser client is validating over HTTPS, given my eg.conf file
> still says
> > the cert/key are in the apache ssl directory the Evergreen
> instructions have
> > you create, while Let's Encrypt puts the goods elsewhere
> >
> (https://letsencrypt.readthedocs.org/en/latest/using.html#where-certs
> ).
> > I'd be interested in knowing some more about what you changed within
> > eg.conf, Ben.
> >
> > Thanks,
> > Kelsey
> >
> > On Sun, Mar 6, 2016 at 7:58 PM, Ben Shum <ben at evergreener.net
> <mailto:ben at evergreener.net>> wrote:
> >>
> >> Hi Kelsey,
> >>
> >> I've been using Let's Encrypt on my personal Evergreen test server
> >> (https://demo.evergreener.net) for this past month or so. Prior to
> >> that, I used Let's Encrypt for some other test systems at my
> previous
> >> place of work.
> >>
> >> The biggest issue I encountered initially was that my system wasn't
> >> resolving the reverse DNS properly for my site (it took a
> little time
> >> for all the DNS to populate properly). This caused the
> >> letsencrypt-auto to fail for me. I think I ended up installing an
> >> additional python package to get that working in addition to giving
> >> enough time for DNS to propagate.
> >>
> >> The test system I used was installed with Ubuntu 14.04 server and
> >> apache 2.4, which letsencrypt seemed to have better luck in
> handling
> >> automatically the apache replaces with apache 2.4 vs. 2.2 (which
> >> shipped on older Ubuntu distros). Alternatively, I think I also
> just
> >> eventually figured out how to setup my eg.conf config file with the
> >> necessary paths for the SSL cert and chain files.
> >>
> >> Feel free to ask further questions about your issues. I think
> using
> >> Let's Encrypt is an awesome solution for SSL certificates.
> >>
> >> -- Ben
> >>
> >> On Sun, Mar 6, 2016 at 8:50 PM, Kelsey Lied <kalied at stkate.edu
> <mailto:kalied at stkate.edu>> wrote:
> >> > Hi,
> >> >
> >> > I am wondering if anybody is using Let's Encrypt
> (letsencrypt.org <http://letsencrypt.org>) for
> >> > their
> >> > Evergreen install.
> >> >
> >> > We're spinning up a new install and would like to use it, but
> so far I
> >> > have
> >> > had no luck on our test server. I have tried a number of things,
> >> > getting
> >> > various errors. The Let's Encrypt community has generally
> had an answer
> >> > for
> >> > each error, but every answer I've tried messes with config
> settings that
> >> > ultimately prevent Evergreen from running properly. (Happy
> to provide
> >> > errors if folks are interested, but they're errors in another
> tool, so
> >> > don't
> >> > want to bog down the initial query.)
> >> >
> >> > Is anybody using Let's Encrypt successfully?
> >> >
> >> > Thanks,
> >> > Kelsey
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20160617/492f0c24/attachment.html>
More information about the Open-ils-dev
mailing list