[BlueOnyx:18720] Re: SSL Certificates (via Let's Encrypt) - available for 5209R

[Michael Stauber]

Hi all,

> https://letsencrypt.org/

The BlueOnyx 5209R version of base-ssl now supports generation and
auto-renewal of the free "Let's Encrypt!" SSL certificates through the GUI.

In order to get a free "Let's Encrypt!" SSL certificate for a Vsite (or
AdmServ) go to the "SSL" menu entry of a Vsite (or of the GUI itself
under "Security" / "SSL") and click on the button labled 'Let's Encrypt!'.

Caveats:
========

- Certificate expiry:

Certificates are only valid for 90 days. But can be auto-renewed by a
cronjob. The GUI is currently offering to do auto-renewal after 60 days,
but you can choose to untick that box or to change the frequency.

- Rate Limits:

'Let's Encrypt!' is still in Beta and is enforcing rate limits that
affect how often you can request certs (10 times in 3 hours). And it
also affects how many certs you can get for the same domain. This sadly
*includes* subdomains. So if you get a certificate for www.site.com and
then another for sub.domain.com, this counts as three certs (at least)
for the same domain. Because the cert for www.domain.com already
included one for "domain.com", too. You can only request 5 certiciates
for the same domain in seven days.

- Online verification:

During the certificate request a temporary file is placed in the web
directory of a Vsite (or the GUI) and 'Let's Encrypt!' checks every
iteration of the domain (FQDN and all web server aliases) if that file
is reachable. So you need working DNS and the Vsite needs to be rechable
from the outside world. Or the request will fail (detailed error message
will be shown in the GUI).

- PHP-FPM:

The online verification (and the renewal!) *will* fail if PHP-FPM is
enabled for that Vsite. I'm currently looking into this. It's the same
issue as with .htaccess files, which also currently don't work with our
PHP-FPM implementation on 5209R.

Earlier I said:
> My impression about their SSL certificate generation mechanism?
> 
> What a bloody *hipster* bullshit! <sigh>

If I could I would take it back and add more profanity and more emphasis
to it. The amount of public ridicule for this hipster bullshit bingo of
a fucked up failboat implementation via an overhyped Python client
simply can't be high enough. YGBSM!!!

Like said: Nothing against Python in general. But these hipsters were so
hip that their hippy-code won't run on anything older than EL7. Because
it doesn't support Python-2.6 anymore. Which EL6 uses. So right now a
5207R or 5208R version is out of the question.

The more I played around with the 5209R version of the "native" and
official 'Let's Encrypt!'-client, the more I doubted their sanity. This
self-updating piece of garbage actually creates and maintains a virtual
environment. Why the heck should *that* be necessary? For a bloody API!
There simply is no good reason for that. There are switches that don't
work. You can't suppress the YUM check and it does that on *every*
bloody start of the client. Even if you just want to look at the darn
help output of said client. Yikes! If they're *that* bad at general
coding concepts, then I have my doubts about their ability to maintain a
trusted Certificate Authority. Seriously. :-(

FWIW: They tried to get their Python client into EPEL. An EPEL
maintainer jumped in and offered to build the RPMs for them. The
Bugzilla discussion about this (and it's progress) is actually both
hilarious and tragic. TL;DR: EPEL threw the towel. It ain't happening
and they're not going to pack that shit up until these guys learn how to
conform to coding standards and find some common sense. :p

Long story short:
-----------------

The base-ssl*.mod for 5209R currently brings the official 'Let's
Encrypt!' Python client aboard (that RPM is named "blueonyx-letsencrypt").

This *will* change in the closer future. I'm currently examining the
alternative clients that are listed here ...

https://community.letsencrypt.org/t/list-of-client-implementations/2103

... and am reading up on the 'Let's Encrypt!' API protocol.

Within the next couple of weeks (time and other projects permitting)
I'll hack together a native Perl client that can directly be integrated
into the BlueOnyx backend. But I might already get beaten to it and
wouldn't be surprised if an unofficial 'Let's Encrypt!' Perl module
shows up on CPAN shortly. Because this is the kind of coding challenge
that any half-way decent Perl-coder loves. And we can do it in a
fraction of code that their bloody Python client needed. \o/

Even then: We need only 15% of the functionality that the official
'Let's Encrypt!' Python client provides, so this should be fairly easy
to code in Perl.

-- 
With best regards

Michael Stauber