Tip of the day: The Security article gives hands-on tips on how to deal with drone attacks, flooding, spammers, (D)DoS and more.

Sni block

From UnrealIRCd documentation wiki
Jump to navigation Jump to search

The sni block allows you to use multiple SSL/TLS certificates on the same server.

Purpose

(For a more technical explanation, see SNI on Wikipedia)

On multi-server networks you may have a irc1.example.com, irc2.example.com and irc3.example.com. Users can connect to these servers via SSL/TLS but the name which they use to connect must match the certificate the server presents back to the user.

In other words: if you connect to irc1.example.com and the server gives a certificate for irc.example.com then it will trigger a certificate warning.

Since many networks allow you to connect both by individual servername (eg: irc2.example.com) and by round robin name (eg: irc.example.com) this poses the question: which name do you use in the certificate?

Previously there were three possible solutions:

  • You load a wildcard certificate for *.example.com on all your irc servers. Now your users can use both irc.example.com and irc1.example.com.
  • You load a multi-domain certificate which contains both irc1.example.com and irc.example.com on your irc1 server. Now users can connect both through irc.example.com and irc1.example.com.
  • You load the irc.example.com certificate/key on all your irc servers, and simply tell users to always connect by /server irc.example.com and never by /server irc1.example.com

Now there is another solution available, which is called SNI. You can load two (or more) certificates on the same server:

  • A certificate for 'irc.example.com'
  • A certificate for 'irc1.example.com' (on irc1), a certificate for 'irc2.example.com' (on irc2), and so on...

The server will then decide which certificate to present to the client. This requires SNI support on the IRC client. Newer mIRC versions and other clients are SNI-capable.

Note that SNI isn't 'better' than wildcard or multi-domain certificates, it simply adds another option for you to use, if you wish.

Configuration

First, you need a "default" certificate/key that will be used for clients that do not support SNI. Think of which certificate is used most often and take that as a default. You configure this via the set::tls block.

In our example we will make irc.example.com the default SSL certificate to use:

set {
    tls {
        certificate "tls/irc_example_com.cert.pem";
        key "tls/irc_example_com.cert.pem";
    };
};

Now, you can add SNI blocks for the "other" host. In our example irc1.example.com:

sni irc1.example.com {
    tls-options {
        certificate "tls/irc1_example_com.cert.pem";
        key "tls/irc1_example_com.cert.pem";
    };
};

There's no need to add an SNI block for irc.example.com as we already loaded it as the default certificate.