Protéger SSL des sites illimités sous un seul vHost sans redémarrage du serveur
Je crée une plate-forme similaire au concept Wix pour l'hébergement de sites Web. Je souhaite m'assurer que tous les sites (sauf si des problèmes spécifiques le permettent, site par site) seront protégés par https.
Les bases du système sont théoriquement un nombre illimité de domaines pouvant être mappés sur un équilibreur de charge qui se connectera à un certain nombre de serveurs virtuels exécutant tous la même application PHP sous la configuration par défaut d'Apache vHost avec tous les ports. Le trafic 443 étant dirigé vers l'application PHP.
Comme il pourrait y avoir un nombre illimité de domaines utilisés pour accéder à l'application, et comme de nouveaux domaines seront ajoutés chaque jour, j'essaie de déterminer le type de certificat approprié pour atteindre cet objectif.
Idéalement, je recherche une solution ou un type de certificat répondant aux critères suivants ...
- Aucune restriction au niveau du domaine (c'est-à-dire: vous ne voulez pas avoir à régénérer le certificat chaque fois qu'un nouveau site est ajouté à la base de données
- Vous n'avez pas besoin de connaître les noms de domaine qui peuvent s'y connecter car ceux-ci sont stockés dans une base de données et n'apparaissent sur le serveur nulle part
- Idéalement, une forme de processus automatisé si possible, car les serveurs virtuels seront détruits et réapprovisionnés fréquemment avec de nouvelles adresses IP et de nouveaux noms de serveur.
Je sais comment faire cela avec des certificats uniques par vhost pour un hébergement de site plus classique dans Apache via des services automatisés tels que LetsEncrypt, mais ce qui précède me bloque et je n’ai rien trouvé en ligne à ce sujet.
Il existe trois façons de connecter des certificats SSL avec des noms de domaine:
- Achetez un certificat pour le domaine. Exécutez un serveur sur une adresse IP unique pour ce domaine. (SSL classique)
- Achetez un seul certificat couvrant plusieurs domaines. Exécutez un serveur sur une adresse IP unique pour tous ces domaines. Réémettez le certificat lorsque vous ajoutez des domaines. C'est ce qu'on appelle le nom de sujet (SAN) ou le certificat de communication unifiée (UCC).
- Achetez un certificat distinct pour chaque hôte. Tout héberger sur une adresse IP. Spécifiez le certificat dans la configuration de l'hôte virtuel. Ceci est connu sous le nom d'indication de nom de serveur (SNI) et prend désormais en charge 98% du navigateur. Seuls certains anciens navigateurs Android et IE ne le prennent pas en charge.
Votre exigence d'ajouter de nouveaux noms d'hôtes sans réémettre de certificats signifie que vous devrez utiliser SNI.
Cependant, votre deuxième exigence, à savoir que le serveur ne soit pas conscient du nom de domaine auquel il se connecte, est incompatible avec SNI. SNI négocie le certificat correct à utiliser en fonction du nom d'hôte. C'est pourquoi les certificats SSL sont généralement configurés dans l'hôte virtuel Apache. Apache négocie la connexion HTTPS et doit connaître le nom d'hôte de ce processus.
Apache a des fonctionnalités pour ajouter des hôtes virtuels avec le redémarrage du serveur. Apache supporte un rechargement de configuration sans redémarrage. Vous ajouterez généralement les fichiers de configuration de l'hôte virtuel avec le certificat SSL. Ensuite, vous exécuteriez une commande pour qu'Apache recharge la configuration afin de pouvoir servir le nouvel hôte sans redémarrage. J'utilise Ubuntu. Sur Ubuntu, la commande est la suivante:
Sudo service Apache2 reload