Edit: Interesting,
https://jdebp.uk has the correct cert configured, whereas https://jdebp.uk. serves the cert as mentioned above.
The Apache web server that the bulk host is using for that site has a fairly poor implementation of HTTPS. It's unsatisfactory in various ways, some very technical, but what you're seeing here is the weird way it handles SNI.
By default when you say you want jdebp.uk. and there is no such virtual host (there's only jdebp.uk with no trailing dot) Apache will pick a default virtual host and act as though you asked for that, sending over the certificate for that host and so on. In this case, at a bulk hosting site, it's some unrelated Antiques Shop outfit, likely because that begins with 'A' which is the first letter of the alphabet.
This actually caused a problem for Let's Encrypt because their tls-sni-01 challenge type assumed nobody would be crazy enough to answer queries for a random name with a certificate chosen by somebody else entirely. But that's exactly what Apache is doing here. The current tls-alpn-01 challenge was introduced to fix that - it asks for a reserved ALPN service instead of a spurious SNI server name.
You'll see the same for various other providers that crawl the IPv4 Internet looking for services. My last job (it seems prescient now to have no job, very convenient in current situation to have no reason to go outside anyway) had me trying to fit some of this data to other service discovery information.
For example, try the following:
openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk."
openssl s_client -connect jdebp.uk:443 -servername "jdebp.uk"
According to the Server header returned:
Server: Apache/2.4.41 (cPanel) OpenSSL/1.1.1d mod_bwlimited/1.4 Phusion_Passenger/5.3.7
> "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using UTF-8 encoding, without a trailing dot.
More information: https://news.ycombinator.com/item?id=22632959