On 2017-10-26, at 14:59, Enoch W. <i...@hotmail.com> wrote: > Thanks exvito for your detailed response. > Re 2 & 3: You're right on the nail :-) See my previous email to Jason. > Re 4: I can't use the high level Transport mechanism as I am using Twisted > (most of the time) through another library layer (pymodbus). > Re 5: My server is still using Python's bloated ThreadingTCPServer model. > Re 6: Right!
You are welcome. > Bottom line, I suggested a change of argument name, from > "ssl.optionsForClientTLS(hostName, ..." to > "ssl.optionsForClientTLS(commonName, ..." That would be misleading: Keep in mind that the name validation will be performed against the server certificate's SANs (subject alternative name) entries, if they exist. More importantly, in the context of your suggestion: as far as I can tell, when SANs are present in the server certificate, not only will the name verification be performed against those, but the certificate's subject commonName will be ignored. IIRC, this is in line with an existing RFC recommendation (maybe 6125?). Thus, hostName is a pretty good name and commonName wouldn't be as good. :) Cheers, -- exvito
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
