Possible de servir le certificat SSL/TLS du serveur interne utilisant Apache comme proxy inverse?

Question

Je dispose d'un serveur Windows accessible via une adresse IP publique avec des hôtes virtuels Apache configurés pour transmettre le proxy à divers serveurs internes avec des applications et des services Web (Apache agissant en tant que proxy inverse). Sur l'un des serveurs internes, je veux configurer HTTPS en utilisant letsencrypt.

J'ai réussi à obtenir un certificat de travail et une configuration de serveur sur le serveur interne, mais le problème est que mon Reverse Proxy (Apache) ne souhaite pas canaliser ce trafic HTTPS. Editer: Je sais qu'il serait plus facile de configurer le proxy inverse avec les certificats, mais Let's Encrypt n'a pas encore de bonnes options automatisées pour Windows et changer manuellement les certificats tous les 60 jours environ serait vraiment fastidieux.

La configuration de l'hôte virtuel dans Apache 2.4 (Windows) ressemble à ceci:

<VirtualHost *:443> 
    ServerName somesubdomain.mydomain.com 
    DocumentRoot "E:/Apache2/htdocs" 
    DirectoryIndex index.html 

    ProxyRequests Off 
    <Proxy *> 
     Order deny,allow 
     Allow from all 
    </Proxy> 

    ProxyPreserveHost On 

    ProxyPass/https://10.3.1.83/ 
    ProxyPassReverse/ https://10.3.1.83/ 
</VirtualHost> 

Sur la 10.3.1.83 (Ubuntu/Nginx) en utilisant le certbot de letsencrypt, j'ai produit des certificats valides et Nginx pour servir configuré HTTPS plus les certificats.

Lorsque j'accède au serveur Ubuntu/Nginx depuis l'intérieur du réseau local, tout fonctionne comme une excuse. En utilisant Chrome DevTools, je peux vérifier que les serveurs ont le bon certificat LetsEncrypt.

Accès au sous-domaine correspondant de l'extérieur (Internet), elle retourne une erreur de serveur interne Page et dans les journaux Apache me dit ce qui suit:

AH00961: HTTPS: failed to enable ssl support for 10.3.1.83:443 (10.3.1.83) 

Edit: J'ai finalement trouvé quelques réponses: On dirait que la SNI proxing n'est pas implémenté dans Apache, seulement "SNI virtual hosting". On pourrait cependant utiliser HAProxy ou d'autres projets.

Apache HTTPS reverse proxy with SNI without key on the proxy https://serverfault.com/questions/614806/apache-mod-proxy-with-https-without-key-material-using-sni https://serverfault.com/questions/625362/can-a-reverse-proxy-use-sni-with-ssl-pass-through/625364

Answer 1

Je pense que vous devez chiffrer le trafic du proxy inverse au client par la mise en place du chiffrement sur le proxy. Si quoi que ce soit, votre serveur Web interne et votre proxy peuvent également partager une communication SSL, en configurant SSL sur le serveur interne NO (mais édité) .l.

Mais vous ne pouvez pas avoir un seul certificat pour tous (ou cela signifierait que vous utilisez la même clé privée/certificats publics sur plusieurs serveurs ...).

Pourquoi est-ce le cas? Parce que si le trafic est chiffré entre le client et le serveur principal, le proxy ne serait pas capable de lire l'en-tête "Host" et d'autres en-têtes utiles de requêtes HTTP, et serait donc incapable de relayer ou même de comprendre les requêtes. Par conséquent, sauf si vous dupliquez des certificats, ma réponse est ... NON. :-)

Ce n'est pas si grave que vos certificats soient concentrés sur votre proxy ... Du point de vue sécurité c'est un peu plus risqué (concentration de risque) mais d'un point de vue administratif c'est plus facile (concentration des efforts) .

EDIT: la réponse est NON si vous voulez atteindre un large public y compris les navigateurs obsolètes ou les bibliothèques de développement que j'ai supposé (c'est OUI dans d'autres cas, voir la conversation ci-dessous).