Conversation
|
This would configure the SNI on a per tls (context) basis. Shouldn't this config be on a per server config? Without knowing the internals of SNI: would it hurt (i.e. be incompatible with some implementations) to always set SNI (if server is specified as a hostname), even if the server doesn't expect it? |
|
@fmauchle I put it in tls config because SNI is only relevant when server type is tls. If one tls context is used by many servers, and you would like to use different SNI for different servers, I agree that it would be more appropriate to put SNI under server settings. |
There already are a number of config statements in the server block that are only relevant if type is tls (or dtls). Thats no issue.
Yes that was my first thought, so we don't have to specify the server name twice (assuming SNI would be identical to the server name most of the time).
Agreed, leaving it optional might be on the safe side for now. But a simple flag to enable it would still be good, especially if used with dynamic discovery. |
Closes radsecproxy#88
|
moved the setting to server config |
Closes #88