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
[email protected] --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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
>
>
