First of all, thank you very much for Lets' Encrypt and for Certbot!
I am new to it, it is a great thing, makes the internet more secure and it is even free!
My Problem: I have two domains, a.x and b.x as virtual servers on an apache httpd. I registered a.x with letsencrypt and certbot. Works fine "secure". After that I registered b.x same way. Works fine. But: a user who knows b.x can easily find out the ip-Address of my Server. If he enters https://ip-Adress, e.g.with Firefox he gets: Potential Security Risk Ahead clicking on "View Certificate" he gets Common Name: a.x ans DNS Name: a.x.
The same is possible with nmap. How can I avoid a user of b.x to find out that I also run a.x? (I would not mind vice versa, if a user of a.x could find out that I also run b.x.)
I forgot to mention that I run a Dyndns-Server, so the ip changes every 24 hours.
Reorder virtual hosts in your httpd configuration, so that the virtual host with the certificate that you want to present by default comes first.
If you don't care about supporting ancient clients without SNI, you may even add a dummy virtual host with a self-signed certificate as the first one, so that clients which don't send SNI matching one of your real domains would see only that certificate and then 403 Forbidden.
Thank you for your advice, sigprof!
I should have mentioned that I run apache on Debian Linux.
With Debian and virtual hosts things are a bit complicated.
The virtual hosts are not listed one by one in apache2.conf.
Instead, they are in a directory /etc/apache2/sites-available.
There, I found a file default-ssl.conf.
After entering the commands (as root) "a2ensite default-ssl.conf"
and "systemctl reload apache2" - et voila! Heureka!
now entering https://ip-adress delivers an error message and no information about sites. The same with nmap.
It might not be a clean solution, but it seems to achieve what I wanted.
I want to add that I don't do any evil things at b.x. I just want to keep things separately. 
as both name A and B is public knowledge (due to ct log), and it's trivial to lookup IP from any of name, so I don't think you can do that (unless you hide tree in forest, by using some well-used hosting/CDN IP
orangepizza,
I hav no problem with both a and b being in a database. I want to avoid the association, as I desribed: A user who knows b.x can easily detect that I run a.x on the same Server. But not vice versa and I wonder why.
Since I use Dyndns, a reverse lookup of the IP will just reveal the name of my internet provider.
Dnslytics shows for my IP just: "no search hits found"
Annoyingly, "a2ensite default-ssl.conf" is not the solution, for both a.x and b.x coming up with an error then. Sorry for checking this not before I wrote the comment!
So I am stuck again....
FWIW Caddy (by default) and nginx (with a configuration knob) handle this properly: by sending TLS alerts for Client Hellos without SNI or with unknown domains in SNI.
I am only familiar with Apache, so I would like to stick to it. How can I solve the Problem with Apache on Debian?
There must be a way. Fancy I had registered the domains vice versa, b.x first, then a.x. Then, the default ssl-server would expose b.x, which would be OK for me.
How can I start all over again? Do I have to revoke my certificates somehow?
Or would it be enough to delete /etc/letsencrypt and the ssl-entries in /etc/apache2/sites-available and then go to certbot to register b.x and then a.x?
That's really more of an Apache setup question but the key trick is to make sure the default VirtualHost is using a self-signed cert. For Apache, the VirtualHost config file name that sorts first becomes the default. So, setup something like 000-NonSNI.conf. Even setup both port 80 and 443 and handle as you wish. Yes, I know port 80 (HTTP) wouldn't use SNI but this is mostly for HTTPS so ... And, it could still do something different for port 80 requests like redirect them or just issue 403 and send to different log or something.
Confirm the default VHost with
sudo apache2ctl -t -D DUMP_VHOSTS
That said, apart from your concern about a browser making IP requests there are numerous other tools people can use to learn which domains relate to which IP. You can't prevent people from learning these two domains use the same IP. The above just dictates what can be learned from probing the IP directly. Every domain name used in a certificate appears in public Certificate Transparency logs. That is one way for other tools (or bots) to learn names to probe.
"For Apache, the VirtualHost config file name that sorts first becomes the default."
OK, but for an additional virtual server I would need an existing domain, would't I? I just have two domains, a.x and b.x.
"You can't prevent people from learning these two domains use the same IP."
That is not the issue. That would require that one knows both a.x and b.x. But how could one that only knows a.x find out that b.x is on the same server if he doesn't know b.x? I do not know a tool that achieves that, do you?
there are bots to try literal every domain appear on ct log and try visit them: and there are services like censys that allows search for their result.
No, it does not need to be a name found in the public DNS. You could use any name you wish. And, people sometimes use names that resolve only on their local network.
Using a self-signed cert for this new default VHost allows you to set the info seen by the client during the exchange.
That is just how Apache works. Not really anything to do with Let's Encrypt.
If you want to better understand what is happening you should learn the openssl command.
Examples
openssl s_client -connect a.x:443 -servername a.x
openssl s_client -connect a.x:443 -noservername
openssl s_client -connect IP:443 -servername a.x
openssl s_client -connect IP:443 -noservername
The -servername option allows you to control the name sent for SNI. Apache uses that name for name-based VirtualHost selection.
"..and there are services like censys that allows search for their result"
I tried censys for a.x and it showed no information about b.x.
Did you try it for your IP?
PS: And, don't miss my post just prior to your latest. We cross-posted.
"Did you try it for your IP?"
Yes, I did. Censys only revealed a.x, as I expected. I would not mind if it revealed b.x and not a.x, but I don't know how.
Both domains are reachable and encrypted.
I renamed b.x.conf to 000-b.x.conf, so that it would come before a.x in alphabet in sites-available. That didn't do the trick.
No, I didn't miss your post. I will try that, too.
Are you saying requests to the IP address returned the cert for a.x even though b.x was the default VirtualHost? Because that sounds wrong.
Are you only using Name-based VirtualHost definitions? Or have you involved your IP address in their configs creating IP-based ones? Because that is tricky to get right.
Are you sure you reloaded (or even restarted) Apache. Confirm the default with
sudo apache2ctl -t -D DUMP_VHOSTS
It would be a lot easier if you shared specific info like your domain names, Apache versions, output of the DUMP_VHOSTS, your VirtualHost definitions and so on. Any of it would help. Almost all of the help here comes from unpaid volunteers offering our time and (considerable) experience for free. It is time-consuming to work with just generalized comments.
Just checking but clarifying "same way" in your above quote. Have you combined both a.x and b.x domains in the same certificate?
Because then a.x would show in the Common Name based on Certbot's default method of adding a domain name to a previously configured cert.
If you use a tool like this: SSL Checker
What does it show for the SANs names in General Info section? Are these two domains combined?