2

I am implementing a multi-master highly available service, which is deployed on two different machines. There is also third machine. It doesn't do anything other than cross-monitoring the cluster and being third voter for a quorum, so there are no public services.

Clients are directed to serving machines by DNS service. The public service name, say svc.example.org, will have two A records, both with short TTL, one has an IP of first server, and the other has an IP of second server. Cluster control will dynamically remove a record for the host if it is down and re-add it once it is up and ready to serve. My DNS service has an API for doing this. The application below is well able to handle the case where same client is using different server for next connection each time, also it is likely connections will be long-lived.

So, basically, to add TLS to this service both servers should have the certificate with this common service name, svc.example.org.

I want also to have a possibility to direct client to certain server, for testing purposes. For example, the cluster control could use the direct connection to certain server to check if it is working, to figure out, should its address to be added into common record. So, in addition to common name, each server should respond to its own distinct name, svc1.example.org and svc2.example.org, which are static.

Thus, my certificate should be also valid for svc1 and svc2.

This is the case for SAN certificate. 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. Here we have the same name, which should appear in two different certificates, both valid as same time. Having two different certificates is also perceived as a security benefit of using a different private key on each server.

I assume no respectful CA will sign two different certificates with same subject name. 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. But, I could easily create two certificates with different subject names, and having the common name in SAN:

(to be deployed on first machine)

  • subject name = svc1.example.org
  • SAN = svc.example.org, svc1.example.org

(to be deployed on second machine)

  • subject name = svc2.example.org
  • SAN = svc.example.org, svc2.example.org

This is legal from my point of view, because each machine has a cert for names which it really serve. But, could this work at all? Would CAs (for example, LetsEncrypt) sign me such certificates? Will clients (for example, OpenSSL client library) be happy with this? Or should I revert to having a single shared certificate with all three names as SAN?

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. In the end, some services I intend to run like this don't need more than domain-validation, so I am going to use LetsEncrypt for them; this is single and automatic CA which is very convenient to use. There is no second LetsEncrypt to ask second set of certificates from. And, what if I decide to have three masters? I have to find third CA?

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?

marked as duplicate by Steffen Ullrich, Xander, Steve, PwdRsch, crovers Dec 12 '16 at 15:24

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 6
  • 1
    In addition to what the Sec.SE duplicate says, this is not at all uncommon - for example, what if you want to have a SSL certificate for both web and mail servers on a given host? CAs regularly sign multiple certs for the same name, as long as an authorized party is requesting them. – gowenfawr Dec 8 '16 at 14:41
  • gowenfawr: I currently have same certificate for mail and web server for a given host name. That is same certificate, however. – Nikita Kipriyanov Dec 8 '16 at 18:58
  • Steffen Ullrich: I had searched exclusively for questions involving SAN, and maybe that's why I've missed those you mention. Both of them suggest getting certs for same domain name from different CAs; I find such solution ugly and unacceptable. These questions also completely lack the topic of using SAN (and to have only a single CA), which is the core of mine question, so no, I don't feel this is duplicate. – Nikita Kipriyanov Dec 8 '16 at 19:08
  • OpenSSL ca has had an option to issue multiple certs with the same subject since before 2005 when I started using it, but you have to read the documentation, and of course this is not a real CA users should trust. OpenSSL library (both client and server) is perfectly fine with such multiple certs, and so is every other client I have used. (Also a small point on English: you wanted 'respectable CA' meaning one considered honest and trustworthy by many people, not 'respectful CA' meaning one that behaves politely and obeys the orders of others.) – dave_thompson_085 Dec 9 '16 at 9:31
2

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.

  • Thank you. It turns out I just need my solution to be validated. So you gave me enough hints where to go, this is very helpful indeed. One thing: I was not talking about web service. That is custom TCP service with TLS layer. – Nikita Kipriyanov Dec 9 '16 at 6:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.