1 Reply by beaveryoga

(2 replies, posted in wolfSSL)

embhorn wrote:

Hi beaveryoga,

Excellent, thanks for sharing this! Were there any issues or changes required?

Kind regards,
Eric @ wolfSSL Support

No changes were needed: the ./configure and make install step were distro compatible.

Go to forum: wolfSSL

2 Topic by beaveryoga

(2 replies, posted in wolfSSL)

Hello everyone,

I have created a Copr repository for el8, el9, fc36 builds.
#> dnf copr enable beaveryoga/wolfSSL
https://copr.fedorainfracloud.org/coprs … a/wolfSSL/

I am using the same configure flags from the Debian package:

./configure --enable-distro --enable-pkcs11 --disable-examples --disable-silent-rules

The feature set should be the same as the Debian package. I did not apply any distro
patches from Debian so it is vanilla 5.3.0.

Enjoy!

Go to forum: wolfSSL

3 Reply by beaveryoga

(3 replies, posted in wolfSSL)

wolfSSL has two functions with and without the 

_tlsext_

part.

void wolfSSL_CTX_set_servername_callback(WOLFSSL_CTX* ctx, CallbackSniRecv cb)
{
    WOLFSSL_ENTER("wolfSSL_CTX_set_servername_callback");
    if (ctx)
        ctx->sniRecvCb = cb;
}

int wolfSSL_CTX_set_tlsext_servername_callback(WOLFSSL_CTX* ctx,
                                               CallbackSniRecv cb)
{
    WOLFSSL_ENTER("wolfSSL_CTX_set_tlsext_servername_callback");
    if (ctx) {
        ctx->sniRecvCb = cb;
        return WOLFSSL_SUCCESS;
    }
    return WOLFSSL_FAILURE;
}

OpenSSL uses only one name with 

_tlsext_

.

So just to confirm that this is the official way to support SNI instead of peeking at raw ClientHello bytes?

Go to forum: wolfSSL

4 Topic by beaveryoga

(3 replies, posted in wolfSSL)

Where is wolfSSL_CTX_set_servername_callback documented with examples?

Google searches for SNI/virtual hosting support in a wolfSSL-based server directed us to peek at the ClientHello raw bytes
and use wolfSSL_SNI_GetFromBuffer() to detect the server_name extension.

But...wolfSSL has wolfSSL_CTX_set_servername_callback: this does not seem to be documented anywhere.

Does this mean that to support virtuall hosts we can:
1. Set  a default wolfSSL_CTX for the initial listen/accept connection
2. Use  servername callback to swap out the original wolfSSL_CTX with wolfSSL_set_SSL_CTX if we want to use different credentials (key/cert)

This is the standard method in OpenSSL virtual hosting and I wanted to confirm that wolfSSL supports this pattern.

I discovered this when reading the code for OpenSIPS which uses wolfSSL exactly in the way to support virtual hosting.

It is surprising that when wolfSSL and SNI/virtual hosting is raised this function is never mentioned.

Go to forum: wolfSSL