Mettre à niveau la connexion HTTP vers SSL / TLS

J'ai actuellement un serveur qui redirige automatiquement toutes les requêtes HTTP vers le site HTTPS équivalent. Le problème est qu'il semble que certains navigateurs n'acceptent pas le certificat SSL (StartSSL.com) ou ne prennent pas en charge SNI, ils reçoivent donc un avertissement de certificat et l'utilisateur ne continuera pas à surfer sur le site Web.

Existe-t-il un mécanisme qui tente de faire en sorte que le navigateur utilise HTTPS au lieu de HTTP simple et lorsque cela ne fonctionne pas (par exemple, le certificat n'est pas accepté ou SNI non pris en charge), il continue à utiliser HTTP.

Actuellement, j'utilise Apache 2.4 avec plusieurs hôtes virtuels qui redirigent tous la connexion HTTP avec Redirect / https://domain.example/.

Un navigateur ne devrait jamais rétrograder seul vers http si https ne fonctionne pas, car tout ce qu'un attaquant devrait faire est de rendre https indisponible (par exemple bloquer le port 443). Donc, la seule façon de le faire est de demander au navigateur du serveur de le faire, par exemple en envoyant une redirection http. Bien sûr, cela doit être envoyé via une connexion sécurisée (sinon un homme du milieu pourrait le truquer) mais malheureusement, c'est exactement votre problème que la connexion sécurisée échoue.

En résumé: non, ce n'est pas possible et c'est mieux ainsi.

BTW, tous les navigateurs modernes prennent en charge SNI, mais pas toutes les applications (par exemple les applications Java, etc.). Si vous avez plusieurs domaines sur le serveur Web, mais qu'un seul est requis par ces applications, vous pouvez définir le certificat pour ce domaine comme valeur par défaut. Sinon, vous devrez obtenir un certificat (plus cher) qui contient tous les domaines nécessaires en tant que noms alternatifs soumis.

Modifiez avec une autre idée: ce que vous pourriez essayer de faire est de télécharger une image de votre côté en tant que https et de vérifier le succès avec un gestionnaire d'erreurs sur la balise img. Peut-être que cela ne déclenche pas un avertissement visible par l'utilisateur mais échoue à la place. Et s'il réussit, vous savez que l'accès https est possible et redirigez l'utilisateur.

En dehors de cela, vous devez vous demander pourquoi vous souhaitez proposer https, si vous acceptez également l'accès avec http. Soit il y a des données qui doivent être protégées, soit elles ne le sont pas. Tant que vous proposez une solution de rechange à http, il est facile pour un attaquant d'appliquer http au lieu de https.

Tout d'abord, il devrait être possible de spécifier un certificat à utiliser pour tous les clients ne prenant pas en charge SNI. Cela signifie que pour tous les domaines hébergés sur cette adresse IP, vous pouvez avoir au moins l'un d'entre eux travaillant pour des clients sans SNI.

Ce que vous pourriez alors faire lors de la redirection de http vers https est une redirection en deux étapes. La première redirection de http vers https utilise le nom de domaine, qui, selon vous, fonctionnerait avec ou sans prise en charge SNI. L'URL d'origine complète devrait être incluse, de sorte que depuis ce site https, vous pouvez rediriger vers le bon après.

Le nom de domaine, qui fonctionne avec ou sans SNI, peut se comporter différemment selon que SNI est pris en charge par le client. De cette façon, vous sauriez que le client prend en charge SNI avant de le rediriger vers un domaine, ce qui nécessite SNI.

Comment configurer exactement cela sur Apache va être un peu à deviner de mon côté (car je n'ai jamais configuré Apache avec plus d'un certificat). Je suppose que la façon de le faire serait de créer des hôtes virtuels basés sur le nom pour tous les domaines, y compris le domaine intermédiaire.

Créez ensuite un hôte virtuel par défaut pour les clients sans SNI, qui utilise le même certificat que celui qui utilise le nom. Ces deux hôtes virtuels avec un certificat identique, enverront une redirection différente aux clients selon qu'ils prennent en charge SNI.

Enfin, j'activerais IPv6 sur le serveur. Avec IPv6, vous obtenez suffisamment d'adresses IP que vous pouvez attribuer une à chaque hôte virtuel. Le même ensemble d'hôtes virtuels peut être basé sur IPv4 et IP sur IPv6, vous n'avez donc pas à dupliquer de configuration de cette façon.

Le résultat final serait une configuration qui fonctionne tant que le client prend en charge SNI ou IPv6. Seuls les clients qui ne prennent en charge ni l'un ni l'autre auront alors un problème, mais vous pourrez toujours les détecter et serveur une redirection différente ou un message d'erreur.

Quant aux clients qui n'aiment pas l'autorité de certification, ma seule suggestion est de les reconnaître par leur user-agent et de les gérer comme vous le jugez approprié. Assurez-vous d'avoir un lien vers le site https, sur lequel ils peuvent cliquer au cas où vous incluriez par erreur trop de clients.

Juste une supposition folle: se pourrait-il que vous n'ayez pas de directive SSLCertificateChainFile dans votre configuration apache qui inclut le fichier sub.class1.server.ca.pem dont vous avez besoin pour StartSSL?