[
https://issues.apache.org/jira/browse/MESOS-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15149355#comment-15149355
]
Joseph Wu commented on MESOS-4665:
--
The behavior here is correct, AFAICS. Resolving the hostname from the
connection is standard practice when verifying SSL certs. (Would the cert
provide much security if the peer specified its own hostname?)
Your modification of {{/etc/hosts}} is one of the recommended solutions. (The
other solution is modifying the DNS entry. Or regenerating the cert with a
resolvable hostname.)
> Reverse DNS for cert validation ?
> -
>
> Key: MESOS-4665
> URL: https://issues.apache.org/jira/browse/MESOS-4665
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.26.0
>Reporter: pawan
>
> I have three mesos master nodes configured to use SSL and with cert
> validation enabled. All the machines are failing cert-validation and hence
> the peering with the following error:
>
> I0212 14:02:22.019564 20544 network.hpp:463] ZooKeeper group PIDs: {
> log-replica(1)@192.168.1.16:5050, log-replica(1)@192.168.1.27:5050,
> log-replica(1)@192.168.1.30:5050 }
> I0212 14:02:22.037328 20545 libevent_ssl_socket.cpp:973] Failed accept,
> verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
> match peer hostname name: 192.168.1.16
> I0212 14:02:22.041191 20545 libevent_ssl_socket.cpp:973] Failed accept,
> verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
> match peer hostname name: 192.168.1.27
> I0212 14:02:22.061522 20545 libevent_ssl_socket.cpp:973] Failed accept,
> verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
> match peer hostname name: 192.168.1.16
> I0212 14:02:22.065572 20545 libevent_ssl_socket.cpp:373] Failed connect,
> verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
> match peer hostname name: 192.168.1.16
> I0212 14:02:22.065839 20545 process.cpp:1281] Failed to link, connect:
> Presented Certificate Name: mesos01.p.qa.a.com does not match peer hostname
> name: 192.168.1.16
> E0212 14:02:22.065994 20545 process.cpp:1911] Failed to shutdown socket with
> fd 27: Transport endpoint is not connected
> I0212 14:02:22.068665 20545 libevent_ssl_socket.cpp:373] Failed connect,
> verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
> match peer hostname name: 192.168.1.27
> I0212 14:02:22.068761 20545 process.cpp:1281] Failed to link, connect:
> Presented Certificate Name: mesos02.p.qa.a.com does not match peer hostname
> name: 192.168.1.27
> E0212 14:02:22.068830 20545 process.cpp:1911] Failed to shutdown socket with
> fd 28: Transport endpoint is not connected
> --
> From my understanding and looking at the source, during cert validation,
> mesos uses getnameinfo call to get the hostname of the connecting peer using
> the IP address on the socket connection. And this call would return the IP as
> a string which is resulting in failures as our cert has a CN of only the peer
> hostname. But, everything worked when I added host-ip mappings of all peers
> to /etc/hosts on each host.
> Does mesos inherently expect reverse DNS (PTR records) to be provisioned ? If
> so, this is very challenging and unrealistic expectation. Even worse if you
> are deploying mesos in a firewalled/NAT-ed environment.
> Is my understanding right ? Am I missing anything here ? How would you
> recommend me to proceed ?
> Also, I use --hostname to set hostname of all mesos nodes and see the right
> [ip, hostname] info in zookeeper node. Looks like mesos is not using it
> during cert validation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
