This is the case for SAN certificate.
To be clear, let me summarize that your case for the SAN certificate is that you want your load/HA-balanced web servers to be able to respond to (hostname).example.org as well as (service).example.org. (hostname) in your example is "svc1" or "svc2". (service) in your example is "svc". You do not want individual an individual host (svc1) to respond to a request addressed to a different host's individual name (svc2).
You are not anticipating that the cert SAN should include all variants of .example.org. (This is a valid configuration, but your question implies that you do not consider it one. More on this in a moment.)
But, machine svc1 should never look correct if queried as svc2 (by a
mistake, misconfiguration, etc.) and vice versa. So, it is preferable
for first machine to have certificate which is valid only for svc1 and
svc, and for second machine to have certificate which is valid only
for svc2 and svc.
If your only reason to ensure svc1 never responds to "svc2.example.org" and svc1 never responds as "svc2.example.org", then that does not imply that you cannot have a cert with "svc1", "svc2", and "svc" all as SAN entries. It is perfectly reasonable to have this handled at the HTTP layer and not the TLS layer. In fact, it is preferable to handle this at the HTTP layer, because that can be handled gracefully as a redirect or as a smart-looking error page. If you enforce this at the TLS layer, then what you will get is a normal HTTP page which is only reachable by clicking through the ominous looking browser warnings which say "OH MY GOD! THIS COULD BE AN IMPOSTOR SITE!"
Here we have the same name, which should appear in two different
certificates, both valid as same time.
That is reasonable. There is nothing prohibiting this, either in "best practices" or in actual practice. There is nothing wrong with a single CA issuing multiple certificates for the same name, and there is nothing wrong and nothing preventing multiple CAs from issuing certificates for the same name (as per this potential dupe).
Having two different certificates is also perceived as a security
benefit of using a different private key on each server.
This is mildly true. Security purists will insist that sharing a key between multiple servers increases the potential for key compromise. This is by no means a universal opinion, however, and in the case of a small number of machines which are configured to serve the same application interchangeably, either for load balancing or HA purposes, sharing a key is a perfectly reasonable and acceptable solution. We presume that the administrator practices decent operational security when sharing the key between machines - just as we assume that they practice decent operational security when copying a single key to a single server.
A single cert may, in fact, be preferable in terms of security. If your users want to use pinning, then a single cert regardless of the backend is ideal.
There is another architecture you have not considered - if you are doing this for load balancing or HA, then you could install a single cert on your load balancer, and individual certs on the individual servers. Have the load balancer terminate the TLS connection from the customer, and open a separate back-end TLS session. You only need your Subject name on the certificate, and you only need the server name on the backend server certificate. The question of intentionally directing traffic to individual backend servers, for monitoring purposes for example, may need to be handled differently - using a "X-Mr-Balancer-Please: backend-server-name" header at the HTTP layer instead of using a different DNS name and Host: header - but there are several ways to exfoliate the feline.
In short, your description of the negativity of sharing keys as a perception is spot on. The actual security cost/benefit ratio is dependent upon the scale and operational practices, not upon any inherent superiority/inferiority of using a single or multiple certs.
I assume no respectful CA will sign two different certificates with
same subject name.
I disagree with this assumption. In my personal experience, a CA will ask if they should revoke previous certs, but that is a matter of reminding the customer of sound policy in the default case, not a matter of enforcing behavior. In every instance I've seen, the CA has accepted the reason presented for multiple certs (which may be "no, we really need multiples" or "no, we need time to migrate before we can revoke the old one.")
Typical OpenSSL routines I used to know (EasyRSA and so on) will even
not allow this to happen, refusing to sign other certificate while
first one isn't revoked.
I will grant you that self-service or automated CAs are unlikely to support this by default. That's because, as I just mentioned, the customer often needs to be reminded of sound policy in the default case. And routines, unlike customer service reps, often take a hard line because they can't parse discussion and reasoning.
(Yes, I'm being kind to some customer service reps here. But you can still argue with a customer service rep more easily than you can a computer!)
But, I could easily create two certificates with different subject
names, and having the common name in SAN
Yes, you can.
But, could this work at all? Would CAs (for example, LetsEncrypt) sign
me such certificates?
Any CA which has customer service reps should allow you to do this. In the case of automated systems like LetsEncrypt, they may not (discussed above).
Again, I question your basic assumption, that sharing a certificate between multiple machines with a SAN superset of all possible names is inadvisable. If that assumption goes away, so does the question of convincing automated and non-automated CAs to issue multiple certificates for the same Subject.
I strongly prefer to use a single CA. Using a multiple CAs is of
course a known option, but it feels like an ugly mess for me.
There are some use cases where multiple CAs make sense. Your use case is not one of them, and you are correct, multiple CAs would not be a scalable solution.
As above, it should be possible for you to get multiple certs with the same Subject but different SAN sets from a single CA. You may need a CA with humans rather than an automated CA like LetsEncrypt.
As above, your use case may be served just as well by having a single cert with a SAN set that encompasses all your machines.
Also, it is about where and what to ask further. If this idea (of
having same name in SAN of different valid certs) is tecnically
possible (could work), what governs the topic, some policies of given
CAs?
If you're dealing with a CA with human service reps and sales reps, then you can simply ask them. If you're asking a technical resource, start with the bottom line, lay your problem out clearly, then reiterate the bottom line.
(If you're asking a service rep, go ahead and ask, then ask for a technical rep if their answer doesn't reassure you that it's solid. If you're asking a sales rep...... ask to speak to a technical rep.)
If I may suggest - you've determined the technical solution that you think fits your problem, and are asking us to address that technical solution, rather than your problem. That's one of the reasons you're facing 'dup' votes.
I have tried to address your technical question here, but also to push back up to what I understand your problem to be, because I think you would be better served to ask for advice about your problem than the solution you arrived at.
In any case, I hope this is helpful to you.
