Can't upgrade certbot on Mac OS 10.7

Server
1

I run a very light duty webserver - currently using Certbot - on an old Mac Mini which cannot run anything above Mac OS 10.7.5. When I started getting emails about the end of life for TLS-SNI-01, I looked here for instructions on how to ensure my certbot client was not depending on TLS-SNI-01, and the first thing it said was to update certbot.

Unfortunately, in the time between installing certbot and being prompted to upgrade it, Homebrew have started aggressively not-supporting older Mac OS versions, which means that the instructions to use Homebrew to update will no longer work. I tried manually installing a number of things along the way which Homebrew refused to manage, but even with (apparently) everything it needs, the homebrew upgrade process for certbot fails (with the error quoted at the end of this message if anyone is interested)

So what I’d really like is to know if there is a way to install a current version of certbot without needing to use Homebrew, since Homebrew have abandoned the version of Mac OS I need to run it on.

I really don’t need a newer machine for any other reason - the old Mini does just fine at handling the extremely light load - but if I can’t resolve this it looks like I’ll have to drop back to using unsecured HTTP, which rather defeats the purpose of the whole “Let’s Encrypt” project.

Thanks!
Robin

– homebrew error text:

==> python2.7 -c import setuptools... --no-user-cfg install --prefix=/private/tmp/certbot--homebrew-virtualenv-201901
Last 15 lines from /Users/robin/Library/Logs/Homebrew/certbot/01.python2.7:
--record=installed.txt

Traceback (most recent call last):
  File "<string>", line 4, in <module>
  File "setup.py", line 16, in <module>
    setup(version=get_version(), py_modules=["virtualenv"], setup_requires=["setuptools >= 40.6.3"])
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/core.py", line 112, in setup
    _setup_distribution = dist = klass(attrs)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/dist.py", line 260, in __init__
    self.fetch_build_eggs(attrs.pop('setup_requires'))
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/dist.py", line 284, in fetch_build_eggs
    parse_requirements(requires), installer=self.fetch_build_egg
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 569, in resolve
    raise VersionConflict(dist,req) # XXX put more info here
pkg_resources.VersionConflict: (setuptools 0.6c12dev-r85381 (/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python), Requirement.parse('setuptools>=40.6.3'))
2

I really don’t know much (anything) about MAC OS nor homebrew…
But my wild guess solution/workaround would be… using “Docker for Mac”.

3

Thanks rg - that looks like it adds a lot of layers of complexity, perhaps requiring that everything be set up all over again, and there I’m not even sure after the hours of effort I’d likely sink into setting it up that it will even work on an old system. I kinda understand why the certbot folks want to keep everything in packages with no install-from-source option (except for developers), but it puts all the eggs in the package system basket, sadly of a system that has decided to make the OS obsolete even when the packages within it could have run just fine.

4

OK so updating cerbot is NOT a viable option.
The next big question is:
Can your certbot installation handle HTTP-01 challenge requests?
[with any luck there may still be some life left in it]

That said, you can try:
certbot renew --dry-run
[and keep your fingers crossed]

[sorry - but I just don’t give up]

5

Heh - nor do I, generally: I already sank about 6 hours (possibly longer) into various attempts to get past all the places where Homebrew fell over. The error in my first post was the closest I could get, but beyond that I couldn’t track down how a fresh install of Python seemed not to satisfy the version requirements to build Certbot.

Anyway, in searching for a Certbot binary, it looks like MacPorts may have an up-to-date version, and MacPorts appears still to support Mac OS X Lion systems… so now I’m giving that a go. Will post updates here in case it’s helpful to anyone else.

6

Here’s the dry-run output. Looks like this version is just too old.

Cert not due for renewal, but simulating renewal for dry run
Renewing an existing certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Attempting to renew cert from /etc/letsencrypt/renewal/darro.ch.conf produced an unexpected error: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.. Skipping.
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/darro.ch/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
1 renew failure(s), 0 parse failure(s)
7

Did you ever try explicitly setting the preferred challenge? Your version of Certbot (whatever it is) could have support for it, but not use it by default:

--dry-run --preferred-challenges http

and there’s always the option to run Certbot in Docker.

8

If adding the --preferred-challenges http also fails, then I would suggest one more test:
[using --webroot]

This requires knowing a couple of things:

  1. The exact document root path for the virtual host.
    [find that in the <virtualhost *:80> section]
  2. The Cert name.
    [find that with: certbot certificates]
    So that would be something like:
    certbot renew --cert-name CERTNAME --webroot -w /PATH/TO/YOUR/SITE --dry-run
9

OK - we have progress, but new problems along with it. Still - it might be a way through.

MacPorts successfully installed certbot. Certbot --version now shows:

certbot 0.30.2

But attempting certbot renew --dry-run now does not appear to attempt any renewals:

MiniMe:~ robin$ sudo certbot renew --dry-run
Saving debug log to /opt/local/var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

No renewals were attempted.
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

As far as I can tell, it’s not finding any of the certificates (or perhaps the config?) installed with the old certbot. In an attempt to get it running again - from scratch if necessary - I’ve tried running the certbot --apache command… in response to which it tells me the apache plugin isn’t installed.

So I think we’re closer - at least I have a certbot that runs! - but I need to reconnect it to my apache installation.

10

Closer still - I’ve directed it to the --config-dir /etc/letsencrypt, and we have a new error: that the apache plugin isn’t installed. Now telling MacPorts to install that, then hopefully we’ll have it running!

11

EXCELLENT !!!

To be sure, show:
certbot certificates

and also if you still have any certs left:
ls -lR /etc/letsencrypt | grep fullchain*

12

There is always the --webroot option (no plugin)

13

Closer still… hopefully we’re not far off now!

Since it didn’t seem to be happy reconnecting to the previous config, after downloading the apache plugin, I ran the certbot --apache command to set it up afresh… and we’re ALMOST there. Here’s the relevant part of the output:

...
Deploying Certificate to VirtualHost /private/etc/apache2/extra/httpd-ssl.conf
Deploying Certificate to VirtualHost /private/etc/apache2/extra/httpd-ssl.conf
Error while running apachectl configtest.

WARNING: MaxClients of 150 exceeds ServerLimit value of 133 servers,
 lowering MaxClients to 133.  To increase, please see the ServerLimit
 directive.
Syntax error on line 13 of /opt/local/etc/letsencrypt/options-ssl-apache.conf:
This version of openssl does not support configuring compression within <VirtualHost> sections.

Rolling back to previous server configuration...
Error while running apachectl configtest.

WARNING: MaxClients of 150 exceeds ServerLimit value of 133 servers,
 lowering MaxClients to 133.  To increase, please see the ServerLimit
 directive.
Syntax error on line 13 of /opt/local/etc/letsencrypt/options-ssl-apache.conf:
This version of openssl does not support configuring compression within <VirtualHost> sections.


IMPORTANT NOTES:
 - We were unable to install your certificate, however, we
   successfully restored your server to its prior configuration.
 - Congratulations! Your certificate and chain have been saved at:
   /opt/local/etc/letsencrypt/live/darro.ch/fullchain.pem
   Your key file has been saved at:
   /opt/local/etc/letsencrypt/live/darro.ch/privkey.pem
   Your cert will expire on 2019-04-30. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /opt/local/etc/letsencrypt. You should
   make a secure backup of this folder now. This configuration
   directory will also contain certificates and private keys obtained
   by Certbot so making regular backups of this folder is ideal.

I don’t think the warning is a deal-breaker, but obviously the syntax error is. Can I just edit that file and tell it to try again, or will it auto-generate over the top of my edits?

14

You can just comment out this line and it won’t wipe it out in future:

SSLCompression          off
15

OK - it seems like it is so close… and yet, something’s still wrong with the configuration. I ran certbot --apache after commenting that line out, it seems to have run perfectly. So as a final test, I ran a renew --dry-run command… and it’s failed. It seems to be pointing to a directory that does not exist on the system?

So close though… thanks to everyone for the suggestions - hopefully we’re one step away from having it running (and hopefully I’m not the only person left running a 10.7.5 server so that this thread is useful to others as well).

MiniMe:~ robin$ sudo certbot renew --dry-run
Saving debug log to /opt/local/var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /opt/local/etc/letsencrypt/renewal/darro.ch.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for darro.ch
http-01 challenge for robin.darroch.id.au
http-01 challenge for webdav.darroch.id.au
http-01 challenge for www.darroch.id.au
http-01 challenge for www.grandhighwizard.net
http-01 challenge for www.robin.darroch.id.au
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (darro.ch) from /opt/local/etc/letsencrypt/renewal/darro.ch.conf produced an unexpected error: Failed authorization procedure. www.grandhighwizard.net (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.grandhighwizard.net/.well-known/acme-challenge/SIrtFK1qKT8BpYF_72ruMh6CTIbDfg8qCOdkiX6kc7Y: Timeout during connect (likely firewall problem), www.robin.darroch.id.au (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.robin.darroch.id.au/.well-known/acme-challenge/KrmdK9ioMK8X8zA1_wmoib6Q_krwB6MBXSt4LRZslqQ: Timeout during connect (likely firewall problem), darro.ch (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://darro.ch/.well-known/acme-challenge/yhM3ct7c2lhWAgBwwChJEyrH6QAL_MdBuCXjN10UzA4: Timeout during connect (likely firewall problem), www.darroch.id.au (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.darroch.id.au/.well-known/acme-challenge/R5BNZpd1-6Jw7sbdhoV-if-DtCykx0r6SZKbmFdohX0: Timeout during connect (likely firewall problem). Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /opt/local/etc/letsencrypt/live/darro.ch/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /opt/local/etc/letsencrypt/live/darro.ch/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.grandhighwizard.net
   Type:   connection
   Detail: Fetching
   http://www.grandhighwizard.net/.well-known/acme-challenge/SIrtFK1qKT8BpYF_72ruMh6CTIbDfg8qCOdkiX6kc7Y:
   Timeout during connect (likely firewall problem)

   Domain: www.robin.darroch.id.au
   Type:   connection
   Detail: Fetching
   http://www.robin.darroch.id.au/.well-known/acme-challenge/KrmdK9ioMK8X8zA1_wmoib6Q_krwB6MBXSt4LRZslqQ:
   Timeout during connect (likely firewall problem)

   Domain: darro.ch
   Type:   connection
   Detail: Fetching
   http://darro.ch/.well-known/acme-challenge/yhM3ct7c2lhWAgBwwChJEyrH6QAL_MdBuCXjN10UzA4:
   Timeout during connect (likely firewall problem)

   Domain: www.darroch.id.au
   Type:   connection
   Detail: Fetching
   http://www.darroch.id.au/.well-known/acme-challenge/R5BNZpd1-6Jw7sbdhoV-if-DtCykx0r6SZKbmFdohX0:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Now, I definitely am serving files from the webroot I had provided, but there is no “.well-known” directory in that webroot, which would explain the errors. How can I confirm the correct webroot for certbot, so that it will actually create the appropriate directory and files?

16

The Apache authenticator does not rely on your webroot, it temporarily modifies your Apache config to facilitate the challenge response.

Can you please try this as an experiment - just try dry-run a single domain at a time:

sudo certbot renew --cert-name www.darroch.id.au --dry-run
17

It’s still not terribly happy about it… but since one certificate covers all the domains, not sure if it’s making a difference.

MiniMe:~ robin$ sudo certbot renew --cert-name darro.ch --dry-run
Saving debug log to /opt/local/var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /opt/local/etc/letsencrypt/renewal/darro.ch.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for darro.ch
http-01 challenge for robin.darroch.id.au
http-01 challenge for webdav.darroch.id.au
http-01 challenge for www.darroch.id.au
http-01 challenge for www.grandhighwizard.net
http-01 challenge for www.robin.darroch.id.au
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (darro.ch) from /opt/local/etc/letsencrypt/renewal/darro.ch.conf produced an unexpected error: ('Connection aborted.', error("(54, 'ECONNRESET')",)). Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /opt/local/etc/letsencrypt/live/darro.ch/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
  /opt/local/etc/letsencrypt/live/darro.ch/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
18

What the. I think there is a networking issue with your server. The inexplicable partial CA-side timeouts plus this local ECONNRESET error pretty much confirms it.

Interestingly there’s an identical issue on the Certbot issue (for macOS) from a while back: https://github.com/certbot/certbot/issues/4471

19

Correction to the previous - ECONNRESET appears to have been transient. Persistent error is same as previous (failed attempts to verify domains presumably due to missing files/directories)

20

means that the CA could not open an HTTP connection to your server. This is before it requests any specific file from your server, so missing files/directories cannot explain it.

You can add --debug-challenges to your dry-run, and Certbot will pause before submitting the challenge to the server. If you open up your Apache config while Certbot is paused, you will see how Certbot has modified the config to serve the /.well-known/acme-challenge path from a different directory.

1 Like