XMPP Service Operators - 2021-09-30

My 2 month old cert from LE errors out because of intermediate R3 expiration on Android 11 in Fairemail (IMAP)... as expected? Will regen... ✏

But does regen help? The intermediate cert stays expired, no? I have a similar problem with DAVx5

Ok, regen helped, fyi.

On regen it might not be as an intermediate, right?

crt.sh still says R3...I dunno, and don't care now, daaamit :(

Ahx the intermediate expired? Not the root we were talking about... https://letsencrypt.org/2020/12/21/extending-android-compatibility.html That chart seems so simple there..

But somehow there is more to it I don't get'

R3 went from DST X3 to their ISRG Root X1 as crosssigned

https://blog.windfluechter.net/2021/09/29/letsencrypt-ca-chain-issues-with-ejabberd/ - check if there are old unused ssl certs with old chain and update your certstores (Debian: update-ca-certificates)

ij: do note that Conversations, at least, did not complain about the ejabberd server with the same cert.

Well, it seems that it really depends how the chain is handled. Apache had no issues as well (SSLlabs), but then again in Apache you configure one cert per vhost while in Ejabberd it reads all certs in directory and pick the one needed for the vhost. Maybe Android does similar things… or Conversations has its own check of the chain…

ij: do post that guide on Fedi ;)

done on Mastodon

R3 was outdated.. I think that should be also considers by the acme client. Or did letsencrypt it not supply some month in advance? A manual renew was enough.

ij: Seems to be the case. creep.im: > x509: certificate has expired or is not yet valid: current time 2021-09-30T09:53:57+02:00 is after 2021-09-29T19:21:40Z deshalbfrei.org fixed it already.

Maybe someone[tm] should create an issue for ejabberd? ;)

but I’m not really 100% sure if this is an ejabberd bug or not…

Martin: I've pinged creep.im admin

Licaon_Kter: X3 expired and was just removed from the chain of all newly issued certs (previously chain was R3, ISRG Root X1 and DST Root CA X3... the latter was removed)

But that causes issues with all newly issued certificates apparently that aren't cross signed by X3 as well.

Might be useful to some server operators out there who accept donations: https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/

Hm. Having a solid donation source on the order of ~15€/mo would allow me to move yax.im to proper hardware that's not cursed.

Ge0rG: I've been thinking about doing a cooperatively run XMPP server if I could find a few people who wanted to split the cost of hosting it. Maybe you'd be interested in splitting the cost with a few other servers that are all hosted on the same machine(s)?

Sam: I'm not sure yet if I want to share responsibility as well

I was kind of thinking individuals could chip in to get an account on some generic server domain, but other servers could chip in to have their own entire server (with their own rules and registration and what not) hosted too

(or individuals who wanted to bring their own domain or what not)

Anyways, this is all just something I've been toying around with in my head; no real serious plans yet. Might be useful as far as not having to pay for expensive hardware though.

someone from creep.im here ?

zp1.net: read above, they said they'll take a look ✏

Funny thing is, I think this room's host still maintains connection to creep.im that was established prior to expiry

yes the s2s connection is working but i get every 12 hours a warning

zp1.net: you mean you're not enforcing valid certs?

mjk, sure but it looks like the s2s connection is not interrupted when a cert expires

Ah, yeah

because the s2s connection as build with a valid certificate

if I now reboot the server the connection will not be rebuild

Nice that there are periodic warnings

but what I do not understand is , why, it is so easy to make certbot renew the certificate with a crontab ... simply add "* 0-23/1 * * * certbot renew" to crontab and your done

this will check every hour if the certificates still valid and renew them if they are not

zp1.net: it's not the domain cert that expired, it's the intermediate one. Cron won't help

well, the certs are still valid, but the chain is not… or to put it different: the wrong chain is being picked when checking the certs… maybe from some certstore and not from fullchain.pem

I wonder how much more breakage will be observed when DST Root will expire in a few hours, heheh. "Valid through" on roots shouldn't matter, but, yknow...

Anything that might go wrong, will

If the servers are up to date, it shouldn't be a problem for s2s, and they said old android would be covered..

> do note that Conversations, at least, did not complain about the ejabberd server with the same cert. Rethinking this...I did not try to reconnect though, maybe I would have seen it for ejabberd too.

`certbot --reuse-key` if you ever want to use dane. 😉

meow

?

I just realized that was like keying up on 121.5 and meowing ;-;

there's a --preferred-chain argument for certbot, which will allow to select ISRG root explicitly, without relying on software to properly choose between two chains

i've enforced it during periodic re-sign for now, seems to be working as it's supposed to

why certbot isn't using the new chain?

oof...

it uses two by default

which lefts an option for software to select between the two, which is handy in case of old Androids, say, 2.3.6, which do not have ISRG root in their CA storage

ru_maniac: oh yeah you're right just noticed there's two entries

my point is that one can force ISRG root to be selected explicitly, which will force certbot to drop DST one -- originally, it was intended to go the other way around, but still, useful

i've ultimately elected to switch to ISRG root only, cause my service is being used only by members of my immediate family, and no one has a phone or computer with an OS old enough for this to cause problems

I would like to, as well but certbot on Arch seems to ignore --preferred-chain="ISRG Root X1"

Maranda: maybe it's just taking the wrong ISRG Root X1 cert? ;)

Their naming scheme is... unfortunate

Ge0rG: that's not how it is supposed to work I think, I found a related bug as well on github

That's quite annoying none the less.

>> I would like to, as well but certbot on Arch seems to ignore --preferred-chain="ISRG Root X1" I had to update my instance of certbot to the latest one

I was using 1.3.0 before, available thru debian repos, and had to switch to snap shipment in order to make it work

1.19.1 works just fine

arch has 1.19.0-1

hm, where exactly in the command are you putting that argument?

I put it right before --force-renew, just like that /usr/local/bin/certbot certonly --force-renew --preferred-chain "ISRG Root X1" --dns-cloudflare [...]

sudo certbot certonly --manual --cert-name <name> --preferred-challenges=dns --preferred-chain="ISRG Root X1" --server https://acme-v02.api.letsencrypt.org/directory --agree-tos --manual-public-ip-logging-ok -d ...

this is very strange btw, is there any reason in particular to point directly towards ACME server?

Have wild card certificates had some issues without more than once. ✏

ru_maniac: or I'm just dumb... and forget to copy the newly issued certificates in the right place.

this is why i'm not using certbot's functionality to renew everything by itself)

it's way easier to just run it via crontab, with some deploy-hooks

(so it's not ignoring the argument) ✏

🤢

it happens, glad you've figured it out

After briefly mentioning it here earlier and having a minor outage (that would have probably not happened if I were using a proper server on proper hardware) I decided to actually start gathering interest in a possibly co-operatively run server. I anyone is interested in helping start a new server for our personal use, join xmpp:unnamedchatcoop@mellium.chat?join