Hmm, curious behavior. I'm not getting that in any of the browsers I can run. Maybe some safari-specific interpretation?

I don't trust letsencrypt and I don't want to give them or anyone else a list of which subdomains I use.

There may be some type of caching problem. When I visit https://marginalia.nu directly, I'm served with this cert, which does not include the apex domain: https://crt.sh/?id=6046506678

When I visit https://search.marginalia.nu I'm served with this different cert, which does include both wildcard and apex: https://crt.sh/?id=6125359537

It's simple, your cert points to *.domain.tld, domain.tld doesn't have a subdomain, <anything>.domain.tld does. You should expand it to include both domain.tld and *.domain.tld.

It seems like a bad cert is being served at the redirect; the LE cert at https://search.marginalia.nu DOES have both the wildcard and apex domain

See https://news.ycombinator.com/item?id=30301015

> .domain.tld

Oof, I'm not sure if I would do that. Since "" stands for all sub domains.

I can at least reproduce it in Chrome, for what it's worth. Perhaps you have the redirect to www cached?

On an Apple or another OS?

I can reproduce it even just with curl on Linux.

The certificate is only for "*.marginalia.nu", which simply doesn't cover "marginalia.nu". It should give the same error on any platform and browser, unless their SSL implementation is broken.

Some browsers try to be smart and insert www automatically though.

I would recommend getting certificate which includes root domain and wildcard subdomains to cover all bases.

The cert I am seeing [1] does include both the wildcard subdomain AND the apex domain

[1] https://crt.sh/?id=6125359537

That's not the certificate I get served though (this one is from 5 february, the one served is from 25 january) do you actually get this certificate on https://marginalia.nu?

I misunderstood what URL we were talking about. What I am seeing:

https://marginalia.nu = https://crt.sh/?id=6046506678 (includes wildcard but NOT apex)

https://search.marginalia.nu = https://crt.sh/?id=6125359537 (includes both wildcard and apex)

Ah, I see what's happening. search.marginalia.nu goes through cloudflare which does its creepy MITM thing and re-encrypts on its end; the others do not.

Why does marginalia.nu use Cloudflare? Have you been hit by DDOSs? I can't think how a search engine would benefit from Cloudflare caching things.

Yeah, It's 100% about bot mitigation. I got hit pretty bad by some botnet a while back, saw 10-15 searches/second. Can't have nice things on the Internet I guess.

Don't really understand their motive either. Maybe they thought I was cloud hosted or used some expensive API to do searches and were attempting to rack up big bills or something.

:-|

I wish I had a good solution to this. Cloudflare to mitigate DDOS attacks has somewhat of a “baby with the bathwater” vibe (considering how much of a pain it is if you can't pass the CAPTCHA, or if you're on Tor), but I can't think of an alternative.

:-| indeed.

I've considered having a naked endpoint with a rate limiter that, when it hits some ceiling (dunno, sustained load of 2 RPS or so), offers the alternatives of going through an unlimited cloudflared domain, or waiting until the bots give up. But that might be annoying too.

You could try to push forward the frontier of accessible CAPTCHAs. You just need some tasks that basically all humans can do, but barely and bots can, that don't rely on vision, hearing, emotional response or cultural knowledge. Should be easy, right?