<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 10:52 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> As i think more, maintaining list of CNs as part of ssl.auth-allow isn't<br>
> going to be easy from Manila side, unless Manila assumes that the first CN<br>
> in the list is the server, hence it should never touch that. What if the<br>
> admin pre-set the list of CNs, then Manila won't have a way to know which<br>
> one is the server CN and which are the client CNs. Even if we assume the<br>
> first CN as server CN, Manila (being python) works with the xml formatted<br>
> output of volume get, and I hope the CNs listed in the XML output are in the<br>
> same order as the allow list, otherwise we are in for more trouble!<br>
<br>
</span>Isn't Manila already involved in the creation of every other CN but the<br>
server's, on the volumes it cares about? Then it *does* know every client<br>
CN. The server CN(s) can be a Manila configuration parameter, or else it<br>
can just assume that any CN it doesn't recognize as one of its own must be<br>
a server's and should be preserved. Either way, that seems like a small<br>
fraction of the complexity that alternatives would impose on others.<br></blockquote><div><br></div><div>Cert, Keys and CN management is out of band of Manila. The manila community<br>didn't wanted to get into the lifecycle management as its not in the scope of Manila<br>project of openstack. Thus cert and trust setup is deployer's responsibility<br></div><div>and needs to be done out of band of Manila.<br><br>thanx,<br>deepak<br> <br></div></div><br></div></div>