Validating and examining server certificate 

When connecting securely, you should ensure you are really connected to the desired server. TLS/SSL provides it with a security certificate of the server. On the client side you should just verify that the server certificate of the current connection really comes from the server you want to connect to. There are following ways, how to do it using the Rebex SSH Pack:

• By default, the server certificate is validated against Windows certificate infrastructure.
• If you cannot rely on the built-in certificate verifier, you can write your own certificate validation.
• The certificate validation can be simply skipped by setting the SslAcceptAllCertificates property:
  • C#
  • VB.NET

  // create client instance
  // ...
  
  // skip certificate validation (don't do this in production environment!)
  client.Settings.SslAcceptAllCertificates = true;
  
  // connect securely (SslMode.Explicit or SslMode.Implicit)
  client.Connect(hostname, SslMode.Explicit);
  

  ' create client instance
  ' ...
  
  ' let skip certificate validation (don't do this in production environment!)
  client.Settings.SslAcceptAllCertificates = True
  
  ' connect securely (SslMode.Explicit or SslMode.Implicit)
  client.Connect(hostname, SslMode.Explicit)
  

Built-in certificate verifier 

When calling the Connect method and no custom validation is configured, the server certificate is validated using Windows CryptoAPI.

See what to do when a server certificate is not trusted.

Legacy Windows CE platforms don't natively support certificates signed using algorithms based on SHA-2 hashes. As a workaround for this major OS limitation, we introduced a built-in certificate validator in the 2016 R3 release.

Custom certificate validation 

If you cannot relay on the certificate can be trusted by the Windows certificate infrastructure, you can implement your own validation:

Register an event handler before calling the Connect method

// create client instance
// ...

// register custom validation event handler
client.ValidatingCertificate += client_ValidatingCertificate;

// connect securely (SslMode.Explicit or SslMode.Implicit)
client.Connect(hostname, SslMode.Explicit);

' create client instance
' ...

' register custom validation event handler
AddHandler client.ValidatingCertificate, AddressOf client_ValidatingCertificate

' connect securely (SslMode.Explicit or SslMode.Implicit)
client.Connect(hostname, SslMode.Explicit)

Implement the custom validation within the event handler

public void client_ValidatingCertificate(object sender, SslCertificateValidationEventArgs e)
{
    // first try to use the default validation (against the Windows certificate store)
    ValidationResult res = e.CertificateChain.Validate(e.ServerName, 0);
    if (res.Valid)
    {
        e.Accept();
        return;
    }

    // get server certificate of the current connection
    Certificate cert = e.CertificateChain[0];

    // check the certificate is already known
    if (trustedThumbprints.Contains(cert.Thumbprint))
    {
        e.Accept();
        return;
    }

    // the certificate is not know yet - show it to user
    Console.WriteLine("Do you trust to the following certificate?");
    Console.WriteLine(" Common name: {0}", cert.GetCommonName());
    Console.WriteLine(" Thumbprint:  {0}", cert.Thumbprint);
    Console.WriteLine(" Expires on:  {0:d}", cert.GetExpirationDate());

    // ask user for the answer
    // ...

    // accept or reject the certificate
    if (userAnswer)
    {
        e.Accept();
        // OPTIONALY store the current certificate as trusted
        trustedThumbprints.Add(cert.Thumbprint);
    }
    else
    {
        e.Reject();
    }
}

Public Sub client_ValidatingCertificate(sender As Object, e As SslCertificateValidationEventArgs)
    ' first try to use the default validation (against the Windows certificate store)
    Dim res = e.CertificateChain.Validate(e.ServerName, 0)
    If res.Valid Then
        e.Accept()
        Return
    End If

    ' get server certificate of the current connection
    Dim cert As Certificate = e.CertificateChain(0)

    ' check the certificate is already known
    If trustedThumbprints.Contains(cert.Thumbprint) Then
        e.Accept()
        Return
    End If

    ' the certificate is not know yet - show it to user
    Console.WriteLine("Do you trust to the following certificate?")
    Console.WriteLine(" Common name: {0}", cert.GetCommonName())
    Console.WriteLine(" Thumbprint:  {0}", cert.Thumbprint)
    Console.WriteLine(" Expires on:  {0:d}", cert.GetExpirationDate())

    ' ask user for the answer
    ' ...

    ' accept or reject the certificate
    If userAnswer Then
        e.Accept()
        ' OPTIONALY store the current certificate as trusted
        trustedThumbprints.Add(cert.Thumbprint)
    Else
        e.Reject()
    End If
End Sub

Overriding SSL server name 

Server certificate's common name should specify the server hostname - this ensures that the server presents a certificate that actually belongs to it. If the names are mismatched, you can still work around it.

Security settings and algorithms 

When connecting with Rebex SSH Pack via TLS/SSL, you can easily configure desired TLS versions, cipher suites, elliptic curves and other parameters.

TLS/SSL protocol versions

Use Settings.SslAllowedVersions property (on client object) to enable or disable specific versions of the TLS/SSL protocol. Supported versions:

• TLS 1.3 (not available on .NET Compact Framework)
• TLS 1.2
• TLS 1.1
• TLS 1.0
• SSL 3.0

Note: TLS 1.3 is still a very new protocol and some legacy servers have issues communicating with clients that support TLS 1.3 in addition to earlier versions. Therefore, to prevent interoperability issues, TLS 1.3 support is not enabled in Rebex SSH Pack by default. To enable it:

• C#: client.Settings.SslAllowedVersions |= TlsVersion.TLS13;
• VB.NET: client.Settings.SslAllowedVersions = client.Settings.SslAllowedVersions Or TlsVersion.TLS13

Note: SSL 3.0 is no longer considered secure and it's disabled by default. To enable it:

• C#: client.Settings.SslAllowedVersions |= TlsVersion.SSL30;
• VB.NET: client.Settings.SslAllowedVersions = client.Settings.SslAllowedVersions Or TlsVersion.SSL30

TLS 1.3 cipher suites

The following TLS 1.3 ciphers are supported:

• TLS_AES_128_GCM_SHA256 (AES/GCM with 128-bit key)
• TLS_AES_256_GCM_SHA384 (AES/GCM with 256-bit key)
• TLS_CHACHA20_POLY1305_SHA256 (ChaCha20-Poly1305 AEAD cipher)

Use Settings.SetSymmetricCipherSuites(...) method (on the client object) to specify a list of allowed TLS 1.3 symmetric cipher suites, and Settings.GetSymmetricCipherSuites() method to retrieve the current setting.

TLS 1.3 key exchange algorithms

The following TLS 1.3 key exchange algorithms are supported:

• secp256r1 (ECDH with NIST P-256 curve)
• secp384r1 (ECDH with NIST P-384 curve)
• secp521r1 (ECDH with NIST P-521 curve)
• X25519 (ECDH with Curve25519; needs a plugin on Windows 8.1 / Windows Server 2012 or earlier and on non-Windows platforms)

TLS 1.3 signature algorithms

The following TLS 1.3 signature algorithms are supported:

• ecdsa_secp256r1_sha256 (ECDSA with NIST P-256 curve and SHA-256)
• ecdsa_secp384r1_sha384 (ECDSA with NIST P-384 curve and SHA-384)
• ecdsa_secp521r1_sha512 (ECDSA with NIST P-521 curve and SHA-512)
• rsa_pss_rsae_sha256 (RSA with RSASSA-PSS scheme and SHA-256)
• rsa_pss_rsae_sha384 (RSA with RSASSA-PSS scheme and SHA-384)
• rsa_pss_rsae_sha512 (RSA with RSASSA-PSS scheme and SHA-512)
• ed25519 (EdDSA with edwards25519 curve and SHA-512)

In TLS 1.3, certificates signed by the following signature algorithms are supported:

• ECDSA with SHA-256, SHA-384 or SHA-512 (corresponds to TLS 1.3 ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384 and ecdsa_secp521r1_sha512 algorithms)
• ECDSA with SHA-1 (legacy certificates; corresponds to TLS 1.3 ecdsa_sha1 algorithm)
• RSASSA-PSS with SHA-256, SHA-384 or SHA-512 (corresponds to TLS 1.3 rsa_pss_rsae_sha256, rsa_pss_rsae_sha384 and rsa_pss_rsae_sha512 algorithms)
• RSASSA-PKCS1-v1_5 with SHA-256, SHA-384 or SHA-512 (corresponds to TLS 1.3 rsa_pkcs1_sha256, rsa_pkcs1_sha384 and rsa_pkcs1_sha512 algorithms)
• RSASSA-PKCS1-v1_5 with SHA-1 (legacy certificates; corresponds to TLS 1.3 rsa_pkcs1_sha1 algorithm)
• EdDSA with edwards25519 curve and SHA-512 (corresponds to TLS 1.3 ed25519; needs a custom certificate verifier)

TLS 1.2/1.1/1.0 cipher suites

TLS/SSL extensions

Rebex SSH Pack supports Server Name Identification (SNI) extension and Renegotiation Indication extension.

TLS/SSL elliptic curves

The Settings.SslAllowedCurves property (on client object) makes it possible to specify a set of enabled elliptic curves used by ECDHE ciphers above. Supported elliptic curves:

* These curves require a plugin on Xamarin, Mono, and legacy Windows platforms.

** These curves require a plugin on Xamarin, Mono, and Windows earlier than Windows 10 / Windows Server 2016.

*** These curves require a plugin on non-Windows platforms and on Windows earlier than Windows 10 / Windows Server 2016.

Certificate validation options

Use Settings.SslServerCertificateValidationOptions property to specify various options for the build-in certificate verifier. For example:

• IgnoreCnNotMatch (Ignore common name mismatch)
• SkipRevocationCheck (Skip revocation check)
• IgnoreCnNotMatch (Ignore invalid common name)
• IgnoreWrongUsage (Ignore wrong usage)
• IgnoreTimeNotNested (Ignore improperly nested validity periods)
• AllowUnknownCa (Allow unknown certification authority)