Table of Contents

Enum SslMode

Namespace
YndigoBlue.Velocity.Enums
Assembly
YndigoBlue.Velocity.dll

Specifies the SSL/TLS encryption and certificate verification mode for database connections.

public enum SslMode

Fields

Disable = 0

The connection between your application and the database is completely unencrypted. All data — including usernames, passwords, and every query result — travels across the network as plain text. Anyone with access to the network between your application and the database server can read or tamper with it. Only appropriate for isolated local development environments where there is no network exposure whatsoever.

Prefer = 1

The application will attempt to establish an encrypted connection. If the database server supports encryption, it will be used. If the server does not support encryption, the application quietly falls back to an unencrypted connection and continues anyway. No check is performed on who the server actually is — the application simply accepts whatever the server presents.

This is the default because it works with any server configuration without requiring any setup, but the silent fallback to unencrypted means you cannot rely on this mode to guarantee your data is protected.

Require = 2

The connection must be encrypted. If the database server does not support encryption, the connection fails rather than falling back to plain text. The data in transit is protected.

However, no check is performed to confirm that the server you are connecting to is actually the server you intended to connect to. A malicious actor who intercepts your connection and presents any certificate at all would still satisfy this requirement. The traffic is encrypted, but the identity of the server is taken on trust.

VerifyCA = 3

The connection must be encrypted, and the server must prove its identity by presenting a certificate that was issued and signed by a Certificate Authority that you explicitly trust. Specify the path to your trusted CA certificate file using SslCaPath.

This prevents connecting to an impostor server, because an attacker would need a certificate signed by your trusted authority, which they should not be able to obtain.

However, this mode does not check whether the name on the certificate actually matches the address you are connecting to. If your trusted Certificate Authority has issued certificates to multiple servers, you could accidentally connect to the wrong one and this mode would not catch it.

Prefer VerifyFull over this mode in almost all cases. The only situation where VerifyCA is appropriate is when you are connecting by raw IP address rather than hostname and the IP address is not listed in the server certificate — in that case VerifyFull would reject the connection even though the certificate is valid. The correct long-term fix is to connect by hostname or have the IP address added as a Subject Alternative Name in the certificate; VerifyCA is a workaround for when neither is immediately possible.

VerifyFull = 4

The connection must be encrypted, the server must present a certificate signed by a Certificate Authority that you explicitly trust, and the name written in that certificate must exactly match the hostname or IP address you are actually connecting to. Specify the path to your trusted CA certificate file using SslCaPath. For mutual TLS — where the server also verifies the client's identity — additionally provide SslCertificatePath and SslKeyPath.

This is the highest level of assurance. It guarantees that the traffic is encrypted, that the server has been vouched for by a trusted authority, and that you are connected to the specific server you intended — not a different server that happens to have a valid certificate from the same authority. This is the recommended setting for any production environment.