dns discovery: set initial-advertise-peer-urls as https url #8445
Comments
|
How are the SRV records configured? |
|
|
try |
|
You alert me! Thanks! My cert is from LetsEncrypt |
|
the certificates seem to be matching example.com instead of the *.example.com |
|
This is cert info from certbot. Cert of LetsEncrypt cannot match wildcard domain.
|
|
I believe this is a bug. Discovery bootstrapping will use discovery-srv (example.com) for the ServerName to avoid a mitm cert attack: if strings.Contains(clusterStr, "https://") && cfg.PeerTLSInfo.CAFile == "" {
cfg.PeerTLSInfo.ServerName = cfg.DNSCluster
}but the machine hosts have subdomain.example.com, so they won't match. It should probably be |
|
Thanks a lot! So will you fix it ? |
|
I have attempted, but Go is not my language and solving this problem needs some considers about the whole project. So I am not able to give a fix. |
|
Could you help me about this commit? |
|
I just test and get What happens |
|
/cc @gyuho can you take a look? |
|
@zyf0330 You probably need regenerate certs with wildcard, since we
|
|
Do you mean, I need set ServerName of cert as *.example.com when server's domain is node01.example.com? If you do, I just say that Let's Encrypt doesn't support wildcard domains. And I don't think it is a good idea too. |
Can you explain why? You are already passing |
|
Actually, the hard problem is Let's Encrypt doesn't support wildcard domains. About what I said above, Maybe I think of something wrong. |
|
@gyuho well... actually it seems that server name does not support wildcard matching. the fix we have is not exactly what @zyf0330 wants. @heyitsanthony @lclarkmichalek do you still remember how do we expect this checking to work? i am sure at some point, someone tested it... |
|
I think exact match |
|
@zyf0330 it needs an exact match. regex and wildcare are not supported. so you have to use wildcard in your cert too. |
|
what is the reason it must be an exact match? For security?
On Wed, Oct 11, 2017, 12:55 Xiang Li ***@***.***> wrote:
@zyf0330 <https://github.com/zyf0330> it needs an exact match. regex and
wildcare are not supported. so you have to use wildcard in your cert too.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8445 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ALZ5gU7VDElxYr7vQAGbFLD3sJHSy3Hyks5srEpdgaJpZM4PBB9->
.
--
追随
|
xiang90
changed the title
|
I just want to note, since I went down the rabbit hole of trying to get a working TLS config set up with DNS discovery, that perhaps the doc'n could be clearer about the requirements. I ended up getting everything working by adding two entries to the Subject Alt Name on my certificate: a DNS name for the hostname, and a DNS name for the etcd discovery address. A wildcard isn't actually required, just potentially more convenient. |
|
@bdhess Do you set one of DNS name as root domain name? Like this, your etcd address is etcd1.example.com, and you set these two DNS name for cert, they are example.com and etcd1.example.com |
|
Yup, I'm setting |
|
I agree your way is effect, but I think supporting wildcard domain of SRV Discovery is necessary. |
|
@gyuho @xiang90 @heyitsanthony actually I believe the change in #8651 would break the configuration I suggested. And it's not clear why you should permit wildcard matches. Basically, the mental model I have is that a particular etcd node is addressable in multiple contexts: either (1.) under the identity of an individual node, in the context of a direct connection, or (2.) under the identity of the cluster, in the context of a discovered connection. Wildcards are one way to achieve the goal of having a single certificate that's valid for two different identities. But that's definitely not the only way, nor is it preferred. Since the wildcard |
|
@bdhess I agreed your way is effect, but it doesn't mean supporting wildcard domain is bad. |
|
Custom wildcard matching is bad from a security perspective, because it is inconsistent with standard X.509 idioms. Assume an etcd deployment with an SRV record at In a small shop, the etcd cluster administrator and the PKI administrator may be the same person, so the point is moot. But in a larger organization, maintaining effective security controls on etcd requires that the PKI administrator understand the custom etcd security model. This doesn't scale. |
|
While enumerating the issues with x509 validation is an entertaining passtime, the fact remains that the expected behaviour of TLS validation is to validate wildcard certificates correctly. If you find wildcard certs to be an issue, then you can work around this by not issuing any wildcard certificates. To take your example of app.example.com a little more concretely, what I usually see is: Now, if I hand you a certificate for etcd TLS setup is hard enough as it is, mostly because it breaks a lot of expectations people have (from HTTPS validation usually). The security gain from disallowing wildcard certificates is not worth the breaking of expectations, and the subsequent insecure clusters when people realise that running unauthenticated is a whole lot easier. |
|
I'm not saying that using actual wildcard certificates should be disallowed. I'm saying that the matching rules that are built into etcd shouldn't add wildcarding of their own. I'm specifically talking about changes like #8651. |
|
@bdhess Previously it tries to do a exact match without the subdomain. how would that even get verified correctly? maybe i misunderstood something early in this issue. i will re-go over the thread later. probably i missed something important. |
|
@xiang90 using subject alt names Here's an example cert for an etcd node name |
|
@bdhess @zyf0330 @stephanh @lclarkmichalek I am inclined to revert #8651. So if you have 1.example.com and want to use SRV discovery under example.com domain, then you need to have as With #8651, you need to have #8651 might save one SAN entry if you can afford wildcard in SAN. But it does not really bring any value if you want to put exact subdomain in to the SAN. But @zyf0330 said he cannot really have wildcard cert, so i am not sure what we are fixing here but bring in an incompatibility change. opinions? |
|
@xiang90 I mean I cannot have a wildcard cert which domain name is |
Correct me if I am wrong, but no such thing exists. hostname ONLY support exact match. you either put *.example.com there to match ONLY *.example or example.com to match example.com. If you think TLS can use regex to do verification, please show me the RFC and probably a go example. |
|
I know. |
|
OK. Now I know why you are confused. etcd does not try to connect to The reason for the check is to ensure the DNS SRV discovery is not hijacked to return you domains that has nothing to do with We are going to revert the patch, and improve the documentation on this. If you cannot put the root domain in SAN, the only option for you is to disable the check. Maybe you can submit a PR to add a flag for that. I am not sure about it at the moment though. |
|
I don't understand above explanation.
When etcd get domain like |
|
It has nothing to do with etcd, but how TLS works in general.I would suggest you to learn how it works at this point. |
|
I just see some code and learn something. When use DNS Discovery mode,
Finally, if etcd cannot do this, then just revert that patch. Adding a flag to ignore check is not necessary, at least for me. |
Using SRV discovery with TLS, the SRV record must be in the DNS SAN or clustering will fail. This is a new requirement and may cause mysterious failures when upgrading from 3.1 to 3.2. I was only able to fix this in our configuration after reading through etcd-io#8445; and now I understand the problem it's clear the docs have a hole here.
In etcd bug 8445, they explain that certs need a domain name as well as a hostname in the DNS SAN when using SRV records for cluster discovery. This would be more elegantly fixed by doing that, of course. Should be easy with cfssl, but unknown if FreeIPA will allow it. etcd-io/etcd#8445
I use nginx to proxy etcd server and do ssl termination, it use http2. Etcd uses DNS Discovery. And after I startup, cluster cannot work normally.
This my etcd startup cmd
log
As you see, it shows
added member f5e2bce5ae996f7 [http://thor01.example.com:4760] to cluster 771871d99223fdd1. I think it should behttps.This is nginx config
The text was updated successfully, but these errors were encountered: