I realise this has been covered in #311 (closed) but I'm providing a pull request, and there is a potential security issue/footgun with the current behaviour.
In my experience, at least two major exchanges (ICE and CME) do not use client certificate authentication for their FIX trade capture endpoints, and therefore quickfixgo cannot be used with them currently. Instead, the server provides a TLS certificate and login is via username/password field in the login message.
There is a very insecure workaround right now - setting SocketInsecureSkipVerify=Y has the side effect of allowing a TLS connection even without client certificates. However, it also does not verify the received certificates which obviously a presents a large security risk (especially given that both ICE and CME provide valid, signed certificates for their respective endpoint addresses). The security issue I see is that developers who need this functionality might just be setting SocketInsecureSkipVerify, rather than going through the friction of forking/pull requests etc and thereby making themselves vulnerable to MITM/DNS takeovers which would allow exchange credential theft.
With that in mind, I have added a "SocketUseSSL" parameter which will make quickfixgo establish a TLS connection even if client certificates are not present whilst allowing server certificate verification. Current behaviour also means that SocketTimeout & SocketMinimumTLSVersion will be ignored in this mode, in line with the existing behaviour when SocketInsecureSkipVerify is used. I'm happy to refactor things more but given that this is crypto code I'd rather get some feedback/thoughts first.