The complaint about the version number was apparently coming from the letsencrypt software. It certainly wasn’t anything that Gentoo does. Gentoo would never suggest that you upgrade, and it certainly would not do it without an express command by the sysadmin.
By “behavior cannot change” I meant that if the behavior changes, it will break previously working implementations.
Yes, I have installed the latest git version now, and it is called certbot. Yet another change that would break a working implementation.
If I understand correctly (sorry, not a Gentoo user), you’re saying that Gentoo is shipping the letsencrypt-auto version of the client?
The intention behind letsencrypt-auto was to provide a script that users who don’t have access to a native package through their distribution can use to install all dependencies and run the client. That’s why it does things like version checks and auto-updates (which you can disable using --no-self-upgrade) - a job that’s normally covered by your package manager. It’s essentially a stop-gap until all current versions of major distributions include the package natively.
Packaged versions of the client (as shipped by Debian, Ubuntu or Fedora) do not use or ship letsencrypt-auto and won’t auto-update. It sounds like the Gentoo package should probably do this as well.
On another note, I’m not entirely sure what you’re referring to with the regression you’ve experienced from 0.4.2 to 0.5.0. Are we talking about the fact that multiple <VirtualHost>s aren’t supported in the same file? Because that’s been the case from the get-go. I’m not sure about the <IfDefine> thing.
From what another user (@bret.miller) mentioned in another thread, earlier versions of the client did actually work with multiple vhosts but more recent versions stopped working. I kinda believe him, since there are threads where people were able to create certificates but "renew" is now failing due to multiple vhosts in a single file.
(I never let letsencrypt change my configurations, I only ever used "certonly", so I have no personal experience with this.)
Well, onward and upward. Now I have changed the name of the ebuild to certbot and certbot-apache respectively, and added a check to make sure that apache was built with the ssl flag, as the developers were so worried about here
So just to be clear, if someone wants to use the apache plugin, they will have to explicitly emerge certbot-apache, at which time Gentoo will force a rebuild of apache if it is not built with ssl. This still won’t fix the fact that certbot is parsing httpd.conf, which could vary by OS. I am not sure what you all want me to do about that for Gentoo’s ebuild.
Finally, when I tried to renew on 0.6.0, the renewal succeeds and produces the correct certificates in the correct place, but along the way gives this message:
------------------------------------------------------------------------------- Processing /etc/letsencrypt/renewal/example.com.conf ------------------------------------------------------------------------------- 2016-05-14 20:23:32,228:ERROR:certbot_apache.configurator:No vhost exists with servername or alias of: example.com. No vhost was selected. Please specify servernames in the Apache config
------------------------------------------------------------------------------- new certificate deployed with reload of apache server; fullchain is /etc/letsencrypt/live/example.com/fullchain.pem -------------------------------------------------------------------------------
You gave up easily! Did you really not upgrade your client since August? The latest client is still in beta now (0.6), were you still using an alpha from the closed trial? And you're surprised it stopped working?
But... but... but... it was an easy configuration and use - you said yourself "Worked great. Renew'd certs every three months. Worked great."
It's kinda disingenuous to install alpha software for a closed trial and then claim it was no good because you never updated even though the service had left beta.
If you're waiting for a client that's >=1.0 then there are plenty of other clients you can use, you don't have to wait for the official one. For example, NeilPang's acme.sh will run just about anywhere, doesn't require root, supports authentication methods the official client doesn't (i.e. DNS), and has already past version 2.0.
I'm eternally surprised there are people who are willing to go to the effort of running their own servers (or at least their own web sites) but can't be bothered to maintain them! LE offers you this stuff on a silver platter but it's still too much effort!
The thing is. Why does it break on its own? If I need to fiddle then might as well figure the certificate stuff by myself. At least there is one component less that could break.
Anyways. Don’t want to inflame things but it would have been great if things would just continue to work. :).
Backwards compatibility often only reaches so far.. E.g., 0.3 is compatible with 0.1 and 0.2, but 0.4 is only compatible with 0.2 and 0.3, not 0.1.. Cóuld be this was the case in your situation.. But I'm not familiar enough with letsencrypts development, nor did you provide much information about what went wrong.. Perhaps it was very easy to fix, perhaps not, we shall never know now..
I spent to much time on the same issue last night!
this didn’t happen with all my vhost.
The error message was not explicit but while i was searching in the doc i found that files with multiple vhost are not supported.
one file for example.com, another for www.example.com in /ets/apache2/sites-avalable
Also it should be noted that it may not be in the sites-enabled folder because sudo a2ensite example.com.conf might not have been ran that enables a site. and will usually place the .conf file in that folder. Thank you for bringing this to our attention
But I'm not familiar enough with