Currently, there is no public interface to supply TLSConfig to the srv *Server argument of dialTLS. There is only one caller of dialTLS: DialTLSExt which constructs a Server without TLSConfig just prior to calling dialTLS.
Therefore InsecureSkipVerify will always be true in the TLSConfig used by the client. It's an understandable default since ServerName must be part of the config if InsecureSkipVerify is false, according to: https://pkg.go.dev/crypto/tls#Client. Just there isn't a way to get to the other branch of that if. All the customization from supplying a TLSConfig such as using a different cert bundle than the system level certs are also not accessible.
Perhaps another DialTLS variant could be added to supply the TLSConfig? I expect the existing interfaces probably shouldn't change as there are likely many uses of them.
Currently, there is no public interface to supply
TLSConfigto thesrv *Serverargument ofdialTLS. There is only one caller ofdialTLS:DialTLSExtwhich constructs aServerwithoutTLSConfigjust prior to callingdialTLS.So in
dialTLSsrv.TLSConfigis alwaysnilin the following: https://github.com/fiorix/go-diameter/blob/f6f13778dcc4d7d18197f76eab5252de712f3ba6/diam/client.go#L135-L139Therefore
InsecureSkipVerifywill always be true in the TLSConfig used by the client. It's an understandable default sinceServerNamemust be part of the config ifInsecureSkipVerifyis false, according to: https://pkg.go.dev/crypto/tls#Client. Just there isn't a way to get to the other branch of that if. All the customization from supplying a TLSConfig such as using a different cert bundle than the system level certs are also not accessible.Perhaps another
DialTLSvariant could be added to supply theTLSConfig? I expect the existing interfaces probably shouldn't change as there are likely many uses of them.