Renewal with removal of subdomain

I did all that but still see this after typing ./certbot-auto --no-self-upgrade --no-bootstrap --version (I added --no-bootstrap to prevent Debian updating):

Creating virtual environment...
Installing Python packages...
/opt/eff.org/certbot/venv/bin/python: No module named pip.main; 'pip' is a package and cannot be directly executed
Traceback (most recent call last):
File "/tmp/tmp.FUKYeMeRCj/pipstrap.py", line 177, in
sys.exit(main())
File "/tmp/tmp.FUKYeMeRCj/pipstrap.py", line 149, in main
pip_version = StrictVersion(check_output([python, '-m', 'pip', '--version'])
File "/usr/lib/python2.7/subprocess.py", line 544, in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['/opt/eff.org/certbot/venv/bin/python', '-m', 'pip', '--version']' returned non-zero exit status 1

As I said, I suspect I'm in dependency hell. :slight_smile:

(BTW, I get the same result without --no-bootstrap but looking over the certbot script itself that's expected.)

3 Likes

Huh. I really did not expect that. I have downloaded Wheezy installation media and will try get it working later.

Although this is not a solution, you might be better off switching to a dependency-free client like lego until you can get to a non-EOL OS.

2 Likes

Thanks for letting me know about lego - we'll see if that helps us work around the problem.

2 Likes

In order to redirect HTTP(S), you need to run an HTTP(S) server (24/7).
[which is NOT the case at jabber.org]

The upside is that since there is no HTTP server, the ACME client can easily run in --standalone mode.
That said, certbot and certbot-auto may not be the best fit for this particular situation.

Have you tried the acme.sh client?
(and as already mentioned) Can you install certbot via snapd ?

1 Like

Please go to jabber.org, Rudy, and tell me there's no HTTP server there. :wink: Unless my browser understands XMPP? :thinking: It redirects HTTP to www.jabber.org, keep that it mind.

please learn to spell D N S - L O L

Name:    jabber.org
Address:  208.68.163.218

Name:    jabber2.github.io
Addresses:  185.199.110.153
          185.199.111.153
          185.199.108.153
          185.199.109.153
Aliases:  www.jabber.org

So...
A: They are nowhere near each other - why put both names on one cert?
B. Go read A
C. Give me time to look into the HTTP listener... in the meantime, go read A (again).

2 Likes

Perhaps this? :grin:

>>> https://jabber.org

> --------------------------------------------
> 301 Moved Permanently
> --------------------------------------------

|**Status:**|301 Moved Permanently|
| --- | --- |
|**Code:**|301|
|**Date:**|Wed, 14 Oct 2020 01:01:41 GMT|
|**Server:**|Apache|
|**Location:**|https://www.jabber.org/|
|**Content-Length:**|231|
|**Connection:**|close|
|**Content-Type:**|text/html; charset=iso-8859-1|

>>> https://www.jabber.org/

> --------------------------------------------
> 200 OK
> --------------------------------------------

|**Status:**|200 OK|
| --- | --- |
|**Code:**|200|
|**Connection:**|close|
|**Content-Length:**|1612|
|**Content-Type:**|text/html; charset=utf-8|
|**Server:**|GitHub.com|
|**Last-Modified:**|Fri, 25 Sep 2020 21:04:52 GMT|
|**ETag:**|"5f6e5b74-64c"|
|**Access-Control-Allow-Origin:**|*|
|**Expires:**|Wed, 14 Oct 2020 01:11:42 GMT|
|**Cache-Control:**|max-age=600|
|**X-Proxy-Cache:**|MISS|
|**X-GitHub-Request-Id:**|F45A:F96D:20DE012:22DE781:5F864DF6|
|**Accept-Ranges:**|bytes|
|**Date:**|Wed, 14 Oct 2020 01:01:42 GMT|
|**Via:**|1.1 varnish|
|**Age:**|0|
|**X-Served-By:**|cache-hhn4059-HHN|
|**X-Cache:**|MISS|
|**X-Cache-Hits:**|0|
|**X-Timer:**|S1602637302.460774,VS0,VE91|
|**Vary:**|Accept-Encoding|
|**X-Fastly-Request-ID:**|0e8baafc663db91ffc86407764be062ab02c95a3|
2 Likes

OK, so something is listening to HTTP from that external IP.
But that is not proof that it is the same server he operates.
[I play those kinds of NAT tricks all day (and night) long]

The IP is from "XMPP Standards Foundation".
It may be free for XMPP only.

He would have to run
netstat -pant | grep -i listen
and show something on 80 for me to think it is there.

But I may have overread the subtleties involved.

Nonetheless, the problem has nothing to do with HTTP and the www servers are miles away from this one.

2 Likes

Not sure. I just know that when I make a request to https://jabber.org I get a 301 redirect to https://www.jabber.org resulting in a 200 with content:

1 Like

I know how redirection works.
And I am (previously) familiar with jabber (via LEO use).

The problem is now cert renewal and the initial client has been Broken Beyond Repair.
Two Three potential clients remain:

  • acme.sh
  • certbot via snapd
  • lego
2 Likes

Sadly, _az already shot this one down when I mentioned it.

2 Likes

I know you know redirects, brother. :slightly_smiling_face:

I just stated my results. No offense intended, ever.

2 Likes

Ok then the BIG question is: How soon before the site is moved?
If less than 90 days, any "one time" cert will do.
If longer, then automation is preferred.

2 Likes

None ever taken mi Amigo.

And I missed the _az smackdown! gotta rewind my TEVO.

2 Likes

As noted, we're in the middle of the migration (which we were supposed to finish months ago but volunteer effort blah blah blah). At least getting a one-time cert would light a fire under us to finish the migration in the next 90 days, eh? :wink:

3 Likes

LOL
Tell them this is a ONE TIME ONLY cert and things must be moved before it expires
OR...
The sky will fall ! ! !

As for getting a one time cert, there is the DNS method.
Augmented HTTPS method - where you redirect the challenge requests to another server and get the cert there.
Then manually FAX it over to the first server (and then break the redirection the challenge requests).
And I'm sure there are more ways to skin that cat (one time).
[they hate being skinned twice!]

2 Likes

Just to follow up on this @stpeter , I can reproduce this failure on Debian 7

It looks like the change that causes the Debian 7 pip error here was introduced in >= 0.32.0. If you download letsencrypt-auto at the 0.31.0 release, it does work.

You could also download the 0.36.0 letsencrypt-auto file as you had before, but before you run it, patch it with:

sed -i "s/python, '-m', 'pip'/'pip'/g" letsencrypt-auto

(certbot-auto is the same as letsencrypt-auto. If you were using the latter already, you might find it more convenient to keep using it)

4 Likes

Another jabber.org admin suggested trying dehydrated, which is a nice little script. Unfortunately validation still fails. I can see the file being created in /etc/dehydrated/.well-known/acme-challenge and that directory is readable via HTTP, as you can see by visiting https://jabber.org/.well-known/acme-challenge/foo.txt - but for some reason dehydrated returns with a status of invalid:

ERROR: Challenge is invalid! (returned: invalid) (result: ["type"] "http-01"
["status"] "invalid"
["error","type"] "urn:ietf:params:acme:error:unauthorized"
["error","detail"] "Invalid response from http://jabber.org/.well-known/acme-challenge/-1fKUEHJXLtusJivOFT0ilIg-0T0AP55TUUd9ilQnVU [208.68.163.218]: "\u003c!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\"\u003e\n\u003chtml\u003e\u003chead\u003e\n\u003ctitle\u003e404 Not Found\u003c/title\u003e\n\u003c/head\u003e\u003cbody\u003e\n\u003ch1\u003eNot Found\u003c/h1\u003e\n\u003cp""

Still debugging here...

3 Likes

You're linking to the HTTPS version of jabber.com. If you change https:// to http://, you'll see the 404 file not found: http://jabber.org/.well-known/acme-challenge/foo.txt

3 Likes

Hmm, yeah, Apache config issue. :slight_smile: Will fix.

3 Likes