TLS et HTTPS

bext gère TLS de manière native : aucun nginx, aucune tâche cron certbot ou proxy inverse n'est requis. Configurez la section [tls] dans bext.config.toml et bext s'occupe de l'approvisionnement des certificats, du renouvellement, de l'agrafage OCSP et de la redirection HTTPS.

Modes TLS#

Le champ mode contrôle la manière dont bext obtient les certificats :

Mode	Comportement
`"auto"`	Fourniture de certificats ACME (Let's Encrypt par défaut)
`"self-signed"`	Générer un certificat auto-signé au démarrage
`"off"`	Pas de TLS ; servir uniquement du HTTP simple (par défaut)

Lorsque les chemins cert et key sont fournis, bext utilise le mode manuel quel que soit le paramètre mode.

Auto-TLS via ACME (Let's Encrypt)#

La configuration de production recommandée. bext demande et renouvelle automatiquement les certificats à l'aide du protocole ACME.

toml

[tls]
mode = "auto"
acme_email = "ops@example.com"

Au premier démarrage, bext :

Génère une clé de compte ACME et s'enregistre auprès de l'autorité de certification
Termine le défi HTTP-01 en servant le jeton de validation sur le port 80
Obtient le certificat et commence à servir HTTPS
Planifie le renouvellement automatique avant l'expiration du certificat

Les certificats sont stockés dans le répertoire de données bext et persistent lors des redémarrages. Le renouvellement s'effectue en arrière-plan sans aucun temps d'arrêt : le nouveau certificat est échangé à chaud dans l'accepteur TLS sans interruption de connexion.

Autorité de certification#

Par défaut, bext utilise Let's Encrypt. Vous pouvez passer à ZeroSSL ou à toute autorité de certification compatible ACME :

toml

[tls]
mode = "auto"
acme_email = "ops@example.com"
acme_ca = "zerossl"

# Or use a custom ACME directory URL:
# acme_ca = "https://acme.internal.corp/directory"

Calendrier de renouvellement#

Le paramètre renew_before_days contrôle combien de jours avant l'expiration bext déclenche un renouvellement. La valeur par défaut est de 30 jours, ce qui donne un tampon confortable pour les certificats de 90 jours de Let's Encrypt.

toml

[tls]
mode = "auto"
acme_email = "ops@example.com"
renew_before_days = 14   # Renew 2 weeks before expiry

Certificats personnalisés#

Si vous obtenez des certificats via votre propre PKI, une autorité de certification d'entreprise ou un fournisseur tel que Cloudflare Origin CA, fournissez directement les chemins d'accès aux fichiers PEM :

toml

[tls]
cert = "/etc/bext/tls/example.com.pem"
key = "/etc/bext/tls/example.com-key.pem"

Lorsque les deux chemins sont définis, bext charge le certificat au démarrage et ignore complètement ACME. Il gère toujours l'agrafage OCSP et les redirections HTTPS. Si les fichiers changent sur le disque (par exemple, un processus de renouvellement externe écrit de nouveaux fichiers), envoyez SIGHUP à bext pour déclencher un rechargement de configuration et un échange à chaud de certificat.

Pour les configurations multi-domaines, le certificat doit couvrir tous les domaines que vous servez (via des entrées SAN ou un caractère générique). En mode multi-applications, les domaines de chaque application doivent être couverts par le certificat fourni.

Certificats auto-signés (développement)#

Pour le développement et les tests locaux, bext peut générer un certificat auto-signé au démarrage :

toml

[tls]
mode = "self-signed"

Cela crée un certificat éphémère pour localhost et 127.0.0.1. Les navigateurs afficheront un avertissement de sécurité, mais la connexion est cryptée. Le certificat est régénéré à chaque redémarrage et n'est jamais conservé sur le disque.

Ce mode est utile pour tester les fonctionnalités HTTPS uniquement (cookies sécurisés, comportement HSTS, HTTP/2) pendant le développement sans configurer une autorité de certification locale.

Agrafage OCSP#

L'agrafage OCSP (Online Certificate Status Protocol) est activé par défaut lors de l'utilisation des modes auto ou TLS manuel. bext récupère la réponse OCSP de l'autorité de certification et l'agrafe à la négociation TLS, afin que les clients n'aient pas besoin de faire une demande OCSP distincte.

toml

[tls]
mode = "auto"
acme_email = "ops@example.com"
ocsp_stapling = true    # Default: true

Les réponses OCSP sont mises en cache et actualisées avant leur expiration. Si le répondeur OCSP est temporairement inaccessible, bext continue de servir avec la dernière réponse agrafée valide.

Pour désactiver l'agrafage (non recommandé) :

toml

[tls]
ocsp_stapling = false

Routage SNI#

En mode multi-applications, bext utilise l'indication de nom de serveur (SNI) pour déterminer quelle application doit gérer une connexion avant la fin de la négociation TLS. Cela permet de servir plusieurs domaines avec différents certificats à partir d'une seule adresse IP et d'un seul port.

Lorsque Auto-TLS est activé en mode multi-applications, bext fournit un certificat distinct pour la liste de domaines de chaque application. SNI sélectionne le certificat correct lors de la négociation TLS en fonction du nom d'hôte demandé par le client.

Redirection HTTPS#

Lorsque TLS est actif (n'importe quel mode sauf "off" ), bext redirige automatiquement les requêtes HTTP vers HTTPS avec une réponse 301 Moved Permanently. La redirection préserve le chemin complet de la requête et la chaîne de requête.

Pour que la redirection fonctionne, bext écoute sur les deux ports :

Port 443 (ou votre port d'écoute configuré) pour HTTPS
Port 80 pour HTTP, servant uniquement les défis ACME et les redirections HTTPS

Si vous utilisez un équilibreur de charge qui met fin à TLS, définissez mode = "off" et laissez l'équilibreur de charge gérer HTTPS. bext fera confiance à l'en-tête X-Forwarded-Proto pour déterminer le protocole d'origine pour la logique de redirection.

Exemple de production complète#

Une configuration TLS complète pour la production :

toml

[server]
listen = "0.0.0.0:443"

[tls]
mode = "auto"
acme_email = "ops@example.com"
acme_ca = "letsencrypt"
renew_before_days = 30
ocsp_stapling = true

Cela vous offre une gestion automatique des certificats, l'agrafage OCSP, la redirection HTTP vers HTTPS et HTTP/2 (qui est activé par défaut lorsque TLS est actif) - le tout sans aucune dépendance externe.

Conseil

Si vous fournissez des certificats via le SDK ( POST /__bext/sdk/certs/provision ) plutôt que le fichier de configuration, le résolveur SNI récupère automatiquement les nouveaux fichiers PEM — aucun SIGHUP n'est nécessaire. Les modifications manuelles du chemin de certificat dans bext.config.toml nécessitent un SIGHUP pour échanger à chaud le certificat.

En rapport#

HTTP/3 et QUIC — ajoute un écouteur UDP/QUIC au-dessus de la pile TLS configurée ici
Modes de déploiement — Considérations TLS multi-applications et en mode Edge
Sécurité — Paramètres WAF, HSTS et CSP superposés à TLS
Configuration : points de terminaison et informations d'identification — stockage sécurisé des informations d'identification ACME et des chemins de certification
Nginx : Présentation – mode mascarade et comment bext hérite de la configuration TLS nginx

Links#

Chiffrons — l'autorité de certification ACME par défaut
RFC 8555 — Protocole ACME — la spécification de l'environnement de gestion automatique des certificats
RFC 6960 — OCSP — Spécification du protocole d'état du certificat en ligne