Consider providing an alternative way to configure SNI via configuration provider

[mmarinchenko]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Docs: SNI in configuration

Related issue: #15144

---

Most Unix shells do not support special characters such as dot (.), hyphen (-), and asterisk (*) in environment variable names:

# bash --version
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

# export DOMAIN_NAME=localhost
# echo $DOMAIN_NAME
localhost

# export DOMAIN.NAME.WITH.DOTS=my.domain.name
-bash: export: `DOMAIN.NAME.WITH.DOTS=my.domain.name': not a valid identifier

# export DOMAIN-NAME-WITH-HYPHENS=my-domain-name
-bash: export: `DOMAIN-NAME-WITH-HYPHENS=my-domain-name': not a valid identifier

# export DOMAIN_NAME_PATTERN_*=*.example.com
-bash: export: `DOMAIN_NAME_PATTERN_*=*.example.com': not a valid identifier

Current SNI configuration uses domain names as keys, so this prevents it from being configured using environment variables:

# export KESTREL__ENDPOINTS__HTTPS__URL="https://*"
# echo $KESTREL__ENDPOINTS__HTTPS__URL
https://*

# export KESTREL__ENDPOINTS__HTTPS__SNI__localhost__CERTIFICATE__SUBJECT="<subject; required>"
# echo $KESTREL__ENDPOINTS__HTTPS__SNI__localhost__CERTIFICATE__SUBJECT
<subject; required>

# export KESTREL__ENDPOINTS__HTTPS__SNI__*.example-domain.com__CERTIFICATE__SUBJECT="<subject; required>"
-bash: export: `KESTREL__ENDPOINTS__HTTPS__SNI__*.example-domain.com__CERTIFICATE__SUBJECT=<subject; required>': not a valid identifier

There is a workaround for this:

# env "KESTREL__ENDPOINTS__HTTPS__SNI__*.example-domain.com__CERTIFICATE__SUBJECT=<subject; required>" bash
# perl -e 'print $ENV{"KESTREL__ENDPOINTS__HTTPS__SNI__*.example-domain.com__CERTIFICATE__SUBJECT"}'
<subject; required>

But we still have (and will have) compatibility issues in various scenarios. For example, this doesn't work in docker compose:

# .env

SNI_DOMAIN="*.example-domain.com"

# docker-compose.yml

services:
  host:
    environment:
      - KESTREL__ENDPOINTS__HTTPS__SNI__${SNI_DOMAIN}__CERTIFICATE__SUBJECT="<subject; required>"

Describe the solution you'd like

The Endpoints section consists of custom endpoint names with the Url key inside:

{
  "Kestrel": {
    "Endpoints": {
      "HTTP": {
        "Url": "http://*:80"
      },
      "HTTPS": {
        "Url": "https://*:443"
      }
    }
  }
}

It would be nice to use a similar approach in the Sni section (here I use the Domain key):

{
  "Kestrel": {
    "Endpoints": {
      "HTTP": {
        "Url": "http://*:80"
      },
      "HTTPS": {
        "Url": "https://*:443",
        "Sni": {
          "LocalHost": {
            "Domain": "localhost",
            "Certificate": {
              "Subject": "<subject; required>",
              "Path": "<path to .pfx file>",
              "Password": "$CREDENTIAL_PLACEHOLDER$"
            }
          },
          "ExampleWithSubdomains": {
            "Domain": "*.example-domain.com",
            "Certificate": {
              "Subject": "<subject; required>",
              "Path": "<path to .pfx file>",
              "Password": "$CREDENTIAL_PLACEHOLDER$"
            }
          },
          "Fallback": {
            "Domain": "*"
          }
        },
        "Certificate": {
          "Path": "<path to .pfx file>",
          "Password": "$CREDENTIAL_PLACEHOLDER$"
        }
      }
    },
    "Certificates": {
      "Default": {
        "Path": "<path to .pfx file>",
        "Password": "$CREDENTIAL_PLACEHOLDER$"
      }
    }
  }
}

Additional context

Perhaps useful additions to the configuration-related decision checklist:

• generally, configuration keys should be treated as C_IDENTIFIER (with some exceptions, such as logging categories);
• configuration values should not be used as keys.

This approach will ensure maximum possible compatibility between different platforms.