Unexpected Let's Encrypt certificates issued for my domain

Help
1

I have detected that the certificate transparency registry contains entries for a domain name that I control which I do not recognize:

slot-online.bash.academy, slot-pulsa.bash.academy, slot-gacor.bash.academy, mozilla.bash.academy, slot88.bash.academy, begalhaxor.bash.academy, slot.bash.academy, blog.bash.academy, www.gide.bash.academy, httpplay.bash.academy

Note: I used to use certbot for this domain but don't anymore. The domain is currently exclusively used through Cloudflare and hosted on GitHub Pages.

I'd like to understand how Let's Encrypt has been able to issue these certificates and put a stop to it.

My domain is:
bash.academy

I ran this command:
certbot certificates

It produced this output:

Found the following certs:
  Certificate Name: countly.lyndir.com
    Serial Number: 429794d4faa56f728414a33e7158d82ca5e
    Key Type: RSA
    Domains: countly.lyndir.com countly.masterpassword.app countly.spectre.app
    Expiry Date: 2022-06-04 04:04:13+00:00 (VALID: 63 days)
    Certificate Path: /usr/local/etc/letsencrypt/live/countly.lyndir.com/fullchain.pem
    Private Key Path: /usr/local/etc/letsencrypt/live/countly.lyndir.com/privkey.pem
  Certificate Name: lhunath.com
    Serial Number: 4e7a28d7bf8f8fc090a176417f0a3b58b2c
    Key Type: RSA
    Domains: lhunath.com *.lhunath.com
    Expiry Date: 2022-06-04 04:04:44+00:00 (VALID: 63 days)
    Certificate Path: /usr/local/etc/letsencrypt/live/lhunath.com/fullchain.pem
    Private Key Path: /usr/local/etc/letsencrypt/live/lhunath.com/privkey.pem
  Certificate Name: lyndir.com
    Serial Number: 4a1e805ac02ad66dda23bc30c2fae419d27
    Key Type: RSA
    Domains: lyndir.com *.lyndir.com
    Expiry Date: 2022-06-04 04:05:15+00:00 (VALID: 63 days)
    Certificate Path: /usr/local/etc/letsencrypt/live/lyndir.com/fullchain.pem
    Private Key Path: /usr/local/etc/letsencrypt/live/lyndir.com/privkey.pem
  Certificate Name: masterpassword.app
    Serial Number: 45d55804b9dccb95cd98b112bd394d20498
    Key Type: RSA
    Domains: masterpassword.app *.masterpassword.app *.masterpassword.lyndir.com *.masterpasswordapp.com *.volto.app masterpassword.lyndir.com masterpasswordapp.com volto.app
    Expiry Date: 2022-06-04 04:06:30+00:00 (VALID: 63 days)
    Certificate Path: /usr/local/etc/letsencrypt/live/masterpassword.app/fullchain.pem
    Private Key Path: /usr/local/etc/letsencrypt/live/masterpassword.app/privkey.pem
  Certificate Name: matrix.lyndir.com
    Serial Number: 35f195c00e247753d1f8150e682b2217500
    Key Type: RSA
    Domains: matrix.lyndir.com lyndir.com
    Expiry Date: 2022-06-04 04:06:53+00:00 (VALID: 63 days)
    Certificate Path: /usr/local/etc/letsencrypt/live/matrix.lyndir.com/fullchain.pem
    Private Key Path: /usr/local/etc/letsencrypt/live/matrix.lyndir.com/privkey.pem
  Certificate Name: spectre.app
    Serial Number: 37e7a095a934a449d0a88d8f2125957ad59
    Key Type: RSA
    Domains: spectre.app *.specter.app *.spectre.app *.spectre.sh specter.app spectre.sh
    Expiry Date: 2022-06-04 04:07:51+00:00 (VALID: 63 days)
    Certificate Path: /usr/local/etc/letsencrypt/live/spectre.app/fullchain.pem
    Private Key Path: /usr/local/etc/letsencrypt/live/spectre.app/privkey.pem

My web server is (include version):
Apache/2.4.53

The operating system my web server runs on is (include version):
FreeBSD satura.lyndir.com 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #0: Tue Aug 24 07:33:27 UTC 2021 root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

I can login to a root shell on my machine (yes or no, or I don't know):
yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 1.22.0

1 Like
2

Probably done by Cloudflare. While they don't specifically mention Let's Encrypt, it's probably likely they're using LE for this:

See also:

and

My advice?

Ask Cloudflare, ask if they did this and if they did, complain about the lack of communication about this.

6 Likes
3

Thanks. I will reach out to Cloudflare Support as well, however for now I will add that Cloudflare's dashboard reports that it has created no client certificates, no origin server certificates, and a single edge certificate under the name:

*.bash.academy, bash.academy

It would seem unlikely to me that Cloudflare has automatically requested certificates under the common names listed above on my behalf, since I have no need for certificates for these domain names.

The common names I have listed also seem highly unlikely to be related to the "Backup Certificates" feature or related functionality. They are clearly targeted common names unrelated to any prior activity on the domain.

I'd also like to know how Let's Encrypt has verified the authenticity of the request for these certificates and allowed them to be issued in the first place.

2 Likes
4

There are only three ways that can be done:

  • HTTP-01 authentication
  • DNS-01 authentication
  • TLS-ALPN-01 authentication

In short, they must have been able to validate domain control.
But I don't know if they can provide which of those authentication methods was used for a specific cert.

3 Likes
5

Adding on to that, just looking at one domain slot-online.bash.academy I see the DNS CNAME points to:

slot-online.bash.academy        canonical name = lhunath.github.io.
Name:   lhunath.github.io
Address: 185.199.109.153
Name:   lhunath.github.io
Address: 185.199.110.153
(more omitted for brevity)

You might want to check your github

3 Likes
6

This is a problem with Github Pages. Because it seems like *.bash.academy resolves to Github Pages, Github allows anyone to create pages without any additional validation.

I have a test page hosted here to demonstrate this:

http://mcpherrinm.bash.academy/

That's hosted from this repository:

I believe Github does HTTP-01 validation, which will succeed because the domain is pointed at Github, and Github successfully completes the challenge to request certificates.

Unfortunately this is a common tactic used by spammers hosting things on Github pages.

5 Likes
7

GitHub should know better, but who the hell thought pointing a DNS wildcard at them was a good idea? O_o

2 Likes
8

It's not obvious that pointing a wildcard at github is a bad idea, and is easy to accidentally do. I've even done it myself when migrating from a web server that wasn't shared to Github Pages, and forgot about another wildcard DNS entry that was pre-existing (and safe when on a non-shared host!)

2 Likes
9

Yeah, I guess so. Nobody expects GitHub to behave this dangerously.

But then, I've never pointed a wildcard anywhere.

2 Likes
10

github show this in a couple places in their docs. But, you know, who reads those :slight_smile:

Screenshot 2022-04-01 160406
Screenshot 2022-04-01 1604062151×303 68 KB

5 Likes
11

And there's also this:

it looks just like what OP needs.

5 Likes
12

Thanks guys! Invaluable feedback and research. I have verified my domain name with GitHub, enabled HSTS and will likely reconsider the wildcard DNS entry. This has been very educational.

It would be nice, though, if Let's Encrypt had a mechanism for the owner of a domain name to get more say over requests made to Let's Encrypt from arbitrary parties (of which I include GitHub, Cloudflare, and others), on its behalf. Certificate Transparency is great, but there are currently very limited avenues for recourse, audit, action, inhibition or recovery. And although this public forum has been fantastically helpful, having to engage with these types of issues in a public area isn't always ideal. It may be my failing, but I have not found a more private way of engaging Let's Encrypt directly.

2 Likes
13

If you wish to exercise more control over validation, we recommend adding CAA records.

3 Likes
14

Does Let's Encrypt already support RFC 8657?

3 Likes
15

Not yet, but we do support regular CAA records.

3 Likes
16

RFC 8657 would be required to be helpful in this case I believe. If someone wants LE certs themselves and LE is being used for the extra, unwanted certs, plain old CAA won't help.

Unless you suggest to add a CAA record just before you get a cert yourselve and remove it again afterwards. But that is cumbersome..

3 Likes
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.